it-swarm.com.de

Wo soll JWT im Browser gespeichert werden? Wie schützt man sich vor CSRF?

Ich kenne die Cookie-basierte Authentifizierung. Das SSL- und HttpOnly-Flag kann angewendet werden, um die Cookie-basierte Authentifizierung vor MITM und XSS zu schützen. Es sind jedoch weitere Sondermaßnahmen erforderlich, um sie vor CSRF zu schützen. Sie sind nur ein bisschen kompliziert. ( Referenz )

Vor kurzem habe ich festgestellt, dass JSON Web Token (JWT) als Lösung für die Authentifizierung recht heiß ist. Ich kenne mich mit dem Kodieren, Dekodieren und Überprüfen von JWT aus. Ich verstehe jedoch nicht, warum einige Websites/Tutorials angeben, dass kein CSRF-Schutz erforderlich ist, wenn JWT verwendet wird. Ich habe viel gelesen und versuche, die folgenden Probleme zusammenzufassen. Ich möchte nur, dass jemand das Gesamtbild von JWT vermitteln und die Konzepte klarstellen kann, die ich über JWT missverstanden habe.

  1. Wenn das JWT in einem Cookie gespeichert ist, entspricht es meiner Meinung nach der Cookie-basierten Authentifizierung, mit der Ausnahme, dass der Server keine Sitzungen zur Überprüfung des Cookies/Tokens benötigt. Es besteht immer noch ein Risiko für CSRF, wenn keine spezielle Maßnahme implementiert wird. Ist JWT nicht in einem Cookie gespeichert?

  2. Wenn das JWT in localStorage/sessionStorage gespeichert ist, muss kein Cookie vor CRSF geschützt werden. Die Frage ist, wie das JWT an den Server gesendet wird. Ich fand hier schlägt vor, jQuery zu verwenden, um den JWT per HTTP-Header von Ajax-Anforderungen zu senden. Nur die Ajax-Anforderungen können also die Authentifizierung durchführen?

  3. Außerdem fand ich eine weitere Blog Sendung, um "Authorization Header" und "Bearer" zu verwenden, um die JWT zu senden. Ich verstehe die Methode, über die der Blog spricht, nicht. Könnte jemand bitte mehr über "Authorization Header" und "Bearer" erklären? Macht dies die JWT per HTTP-Header von ALLEN Anfragen übertragen? Wenn ja, wie wäre es mit CSRF?

128
Timespace7

JWT-Token sind beliebt, da sie in neuen Autorisierungs- und Authentifizierungsprotokollen wie OAuth 2. und OpenID Connect als Standard-Tokenformat verwendet werden.

Wenn das Token in einem Cookie gespeichert wird, sendet der Browser es automatisch zusammen mit jeder Anforderung an dieselbe Domäne. Dies ist weiterhin anfällig für CSRF-Angriffe.

Die Trägerauthentifizierung ist eines der in HTTP definierten Authentifizierungsschemata . Dies bedeutet im Grunde, dass YOU das Token (JWT) in den Autorisierungs-HTTP-Header einer Anforderung einfügt. Der Browser NOT erledigt dies automatisch für Sie, sodass er nicht zum Schutz Ihrer Website geeignet ist. Da der Browser den Header Ihrer Anfrage nicht automatisch hinzufügt, ist er nicht anfällig für einen CSRF-Angriff, der davon abhängt, dass Ihre Authentifizierungsinformationen automatisch an die ursprüngliche Domain gesendet werden.

Das Trägerschema wird häufig zum Schutz von Web-APIs (REST-Services) verwendet, die über AJAX Anrufe oder von mobilen Clients aus verwendet werden.

59
MvdD

Wir müssen das JWT auf dem Client-Computer speichern. Wenn wir es in einem LocalStorage/SessionStorage speichern, kann es leicht von einem XSS-Angriff ergriffen werden. Wenn wir es in Cookies speichern, kann ein Hacker es (ohne es zu lesen) in einem CSRF-Angriff verwenden und sich als Benutzer ausgeben, unsere API kontaktieren und Anforderungen senden, um Aktionen auszuführen oder Informationen im Namen eines Benutzers abzurufen.

Es gibt jedoch mehrere Möglichkeiten, um das JWT in Cookies so zu sichern, dass es nicht leicht gestohlen werden kann (es gibt jedoch noch einige fortgeschrittene Techniken, um sie zu stehlen). Wenn Sie sich jedoch auf LocalStorage/SessionStorage verlassen möchten, können Sie mit einem einfachen XSS-Angriff darauf zugreifen.

Um das CSRF-Problem zu lösen, verwende ich in meiner Anwendung Double-Submit-Cookies.

Double Submit Cookies-Methode

  1. Speichern Sie JWT in einem HttpOnly-Cookie und verwenden Sie es im sicheren Modus für die Übertragung über HTTPS.

  2. Die meisten CSRF-Angriffe haben in ihren Anfragen einen anderen Origin- oder Referrer-Header als Ihr ursprünglicher Host. Prüfen Sie also, ob einer von ihnen in der Kopfzeile enthalten ist, ob er von Ihrer Domain stammt oder nicht! Wenn nicht, lehnen Sie sie ab. Wenn sowohl Origin als auch Referrer in der Anfrage nicht verfügbar sind, ist dies kein Problem. Sie können sich auf das Ergebnis der X-XSRF-TOKEN-Header-Validierung verlassen, das ich im nächsten Schritt erläutere.

  3. Während der Browser Ihre Cookies automatisch für die Domain der Anfrage bereitstellt, gibt es eine nützliche Einschränkung: Der JavaScript-Code, der auf einer Website ausgeführt wird, kann die Cookies anderer Websites nicht lesen. Wir können dies nutzen, um unsere CSRF-Lösung zu erstellen. Um CSRF-Angriffe zu verhindern, müssen wir ein zusätzliches von Javascript lesbares Cookie namens XSRF-TOKEN erstellen. Dieses Cookie muss erstellt werden, wenn der Benutzer angemeldet ist, und sollte eine zufällige, nicht erratbare Zeichenfolge enthalten. Wir speichern diese Nummer auch im JWT selbst als privaten Anspruch. Jedes Mal, wenn die JavaScript-Anwendung eine Anfrage stellen möchte, muss sie dieses Token lesen und in einem benutzerdefinierten HTTP-Header senden. Da diese Vorgänge (Lesen des Cookies, Setzen des Headers) nur in derselben Domäne der JavaScript-Anwendung ausgeführt werden können, können wir wissen, dass dies von einem echten Benutzer ausgeführt wird, der unsere JavaScript-Anwendung verwendet.

Angular JS macht Ihnen das Leben leicht

Glücklicherweise verwende ich Angular JS in unserer Plattform und Angular paketiert den CSRF - Token - Ansatz, um die Implementierung zu vereinfachen. Für jede Anforderung, die unser = Angular Anwendung macht vom Server aus, der Angular $http Dienst erledigt diese Dinge automatisch:

  • Suchen Sie in der aktuellen Domain nach einem Cookie namens XSRF-TOKEN.
  • Wenn dieses Cookie gefunden wird, liest es den Wert und fügt ihn der Anforderung als X-XSRF-TOKEN-Header hinzu.

Somit wird die clientseitige Implementierung automatisch für Sie erledigt! Wir müssen lediglich ein Cookie mit dem Namen XSRF-TOKEN auf der aktuellen Domain auf der Serverseite setzen. Wenn unsere API einen Aufruf vom Client erhält, muss sie den Header X-XSRF-TOKEN überprüfen und mit dem Header vergleichen XSRF-TOKEN im JWT. Wenn sie übereinstimmen, ist der Benutzer real. Andernfalls handelt es sich um eine gefälschte Anfrage, die Sie ignorieren können. Diese Methode ist von der Methode "Double Submit Cookie" inspiriert.

Vorsicht

In Wirklichkeit sind Sie immer noch anfällig für XSS. Der Angreifer kann Ihnen das JWT-Token nicht für die spätere Verwendung stehlen, aber er kann mithilfe von XSS weiterhin Anforderungen für Ihre Benutzer stellen.

Unabhängig davon, ob Sie Ihre JWT in localStorage oder Ihr XSRF-Token in einem Nicht-HttpOnly-Cookie speichern, können beide problemlos von XSS abgerufen werden. Sogar Ihre JWT in einem HttpOnly-Cookie kann von einem fortgeschrittenen XSS-Angriff wie XST-Methode . erfasst werden.

Daher müssen Sie neben der Methode "Double Submit Cookies" immer die Best Practices für XSS befolgen, einschließlich des Auslassens von Inhalten. Dies bedeutet, dass ausführbarer Code entfernt wird, der den Browser dazu veranlasst, etwas zu tun, das Sie nicht möchten. In der Regel bedeutet dies das Entfernen von // <![CDATA[ -Tags und HTML-Attributen, durch die JavaScript ausgewertet wird.

Lesen Sie hier mehr:

121
Iman Sedighi