wake-up-neo.com

CSRF-Schutz mit JSON-Web-Tokens

Ich habe gelesen, dass bei der Verwendung von JWT kein Schutz vor CRSF-Angriffen erforderlich ist, zum Beispiel: " Da Sie sich nicht auf Cookies verlassen, müssen Sie sich nicht vor siteübergreifenden Anfragen schützen ".

Was ich jedoch nicht verstehe: Wenn ich das Token in localStorage speichere (wie mir empfohlen wurde in einem Tutorial derselben Website ), was hindert einen Angreifer daran, eine böswillige Anfrage zu fälschen, indem er statt meiner Cookies mein localStorage liest ? 

Da es auf der Serverseite generiert wurde, weiß ich nicht, wie ich ein Token für eine Clientanforderung verwenden kann, ohne dass es irgendwo auf dem Client gespeichert ist.

30
JulienD

Genau genommen kann alles, was im lokalen/Sitzungsspeicher (der als HTML5-Speicher bezeichnet wird) gespeichert ist, bei einem Cross-Site-Scripting-Angriff (XSS) gestohlen werden. Siehe diesen Artikel .

Es sind jedoch viele bewegliche Teile zu berücksichtigen.

Erstens gibt es subtile Unterschiede in der Art und Weise, wie HTML5-Speicher und Cookies den JavaScript-Zugriff betreffen.

HTML5-Speicher ist:

  • aufgeteilt zwischen http und https. Auf ein im HTML5-Speicher http://example.com gespeichertes Element kann nicht von JavaScript zugegriffen werden, das auf https://example.com ausgeführt wird.
  • zwischen Subdomains aufgeteilt. Auf ein im HTML5-Speicher http://example.com gespeichertes Element kann nicht mit JavaScript zugegriffen werden, das unter http://sub.example.com ausgeführt wird (Sie können jedoch einige Tricks ausführen, um dies zu umgehen).

Kekse sind lockerer:

  • Ein Cookie mit einer Domain example.com wird sowohl http://example.com als auch https://example.com gesendet, es sei denn , es hat das Attribut secure, in diesem Fall wird es nur an https gesendet.
  • Ein Cookie, das nicht mit einer expliziten Domain gesendet wurde, wird nur an die Domain zurückgesendet, von der es gesendet wurde. Wenn die Domäne explizit als example.com definiert ist, wird sie sowohl an example.com als auch an sub.example.com gesendet. (Dies ist der verwirrendste Teil der Cookie- "Spezifikation", siehe diesen Artikel ).
  • Ein Cookie kann von JavaScript gelesen werden, wenn es auf einer Seite mit einer übereinstimmenden Domain ausgeführt wird (und das Cookie-Flag secure beachtet) , es sei denn Das Cookie hat das Attribut httpOnly. In diesem Fall kann JavaScript es nicht lesen.

Zweitens sendet der Browser, da Cookies mit einer Domain markiert sind, bei einer Anfrage an einen Server All-and-Only-Cookies mit einer passenden Domain , unabhängig von der Domain der Seite das hat die Anfrage ausgelöst .

Der letzte Teil ist, wie ein CSRF-Angriff ausgeführt wird (die gleiche Origin-Richtlinie hilft nur so viel). Die OWASP-Seite zu CSRF ist eine gute Ressource, um zu lernen, wie solche Angriffe funktionieren.

Der Grund für das Speichern eines Authentifizierungstokens im lokalen Speicher und das manuelle Hinzufügen zu jeder Anforderung zum Schutz vor CSRF ist das Schlüsselwort: manual. Da der Browser dieses Authentifizierungstoken nicht automatisch sendet, kann er mein Authentifizierungstoken nicht senden, wenn ich evil.com besuche und es ihm gelingt, POST http://example.com/delete-my-account zu senden, sodass die Anforderung ignoriert wird.

In Anbetracht des oben Gesagten wird die Verwendung eines Cookies oder von HTML5-Speicher zu einer Reihe von Kompromissen:

Das Speichern des Authentifizierungs-Tokens im HTML5-Speicher bedeutet:

  • (-) Gefahr des Diebstahls bei einem XSS-Angriff.
  • (+) Bietet CSRF-Schutz.
  • (-) Muss jede Anforderung, die an den Server gesendet wird, manuell ändern, um Sie auf SPA-Webanwendungen (z. B. AngularJs) zu beschränken.

Wenn Sie das Authn-Token dagegen in einem Cookie mit den Bezeichnungen httpOnly und secure speichern, gilt Folgendes:

  • (+) Das Authentifizierungs-Token kann von XSS nicht gestohlen werden.
  • (-) Sie müssen selbst CSRF-Schutz bereitstellen. Die Implementierung des CSRF-Schutzes ist in einigen Frameworks einfacher als in anderen.

Welche Option besser ist, hängt von Ihren Bedürfnissen ab.

  • Schützt Ihr Authn-Token alles, was mit Geld zu tun hat? Wahrscheinlich möchten Sie die Cookie-Option httpOnlysecure.
  • Lohnt sich der Aufwand für die Implementierung des CSRF-Schutzes nicht für die Vermögenswerte, die er schützt? Dann ist der HTML5-Speicher möglicherweise der richtige Ort.
95
kuporific

Bei Verwendung der tokenbasierten Authentifizierung müssen Sie das Token manuell mit der Anforderung verknüpfen. Im Gegensatz zu Cookies werden Tokens nicht automatisch vom Browser gesetzt und sind daher nicht anfällig für csrf-Angriffe.

Während dieser Ansatz vor csrf-Angriffen geschützt ist, ist er anfällig für xss-Angriffe.

Ein minimaler Aufwand wäre die Verwendung von session storage anstelle von local storage, da session storage-Daten gelöscht werden, nachdem der Benutzer die Registerkarte/den Browser geschlossen hat.

1