it-swarm.com.de

Benötige ich ein CSRF-Token, wenn ich Bearer JWT verwende?

Kontext : Angular Site wird auf S3 hinter CloudFront gehostet, getrennt vom Express-Server, der als API verwendet wird, und fast allen Anfragen sind XMLHttpRequests. Alle Anfragen werden ohne Cookies gesendet (standardmäßig withCredentials = false). Ich verwende das JWT Bearer-Token zur Authentifizierung, indem ich es aus Cookies in angular und in Authorization platziere Header (Diese Technik ist so ähnlich wie in CSRF Wiki Seite ) beschrieben.

Auf der Express-Site erlaube ich keinen Cookie-Header in Access-Control-Allow-Headers.

Cookies haben secure: true flag und sind NICHT httpOnly, da ich manuell im Winkel darauf zugreifen muss.

Außerdem habe ich in diesem Medium-Artikel gelesen, dass JSON-Web-Tokens (JWT)/Bearer-Tokens

ist ohne Zweifel eine der besten Methoden zur Verhinderung von CSRF

Frage 1 : Werde ich zusätzliche Sicherheit hinzufügen, wenn ich jeder Anforderung einen X-XSRF-Token-Header hinzufüge und den Mechanismus beispielsweise durch Überprüfen auf zustandslos mache der gleiche Wert in JWT-Nutzdaten? (Ich habe darüber in diesem Thread gelesen )

Frage 2 : Brauche ich tatsächlich zusätzliche Sicherheitsmaßnahmen gegen CSRF, wenn ich alles nehme, was ich beschrieben habe?

55
Igor Pomogai

Dies ist relevant, beantwortet aber nicht unbedingt 100% Ihrer Frage:

https://security.stackexchange.com/a/166798/149676

Kurz gesagt, solange die Authentifizierung nicht automatisch erfolgt (normalerweise vom Browser bereitgestellt), müssen Sie sich keine Gedanken über den CSRF-Schutz machen. Wenn Ihre Anwendung die Anmeldeinformationen über einen Authorization -Header anfügt, kann der Browser die Anforderungen nicht automatisch authentifizieren, und CSRF ist nicht möglich. Daher würde ich das Zitat aus Ihrem Artikel leicht umformulieren: Es ist nicht so, dass Bearer Tokens die beste Verteidigung gegen CSRF-Angriffe sind, sondern einfach, dass CSRF ein Angriffsvektor ist, der speziell Anforderungen angreift, bei denen der Browser automatisch Authentifizierung bereitstellt (normalerweise Cookies) und grundlegende Authentifizierung), und daher spielt CSRF keine Rolle, wenn der Browser Sie nicht authentifizieren kann.

Sie sollten wahrscheinlich sicherstellen und auf der Serverseite sicherstellen, dass Ihre Anwendung nicht stillschweigend auf die Cookie-Validierung zurückgreift, wenn das Bearer-Token fehlt. Ich konnte sehen, dass so etwas versehentlich in eine Anwendung quietschte, und da die Cookies gesendet werden, ob Sie dies möchten oder nicht, könnte dies zu einer versehentlichen CSRF-Sicherheitslücke auf einer Seite führen, gegen die "angeblich" immun sein sollte CSRF.

Daher denke ich, dass Ihre beiden Fragen eins und zwei auf die gleiche Weise beantwortet werden können. Wenn Sie die Authentifizierung nur über Bearer-Token und nicht über Cookies verwenden, besteht keine Gefahr einer CSRF-Sicherheitsanfälligkeit, und aus Sicherheitsgründen sind keine zusätzlichen Schritte erforderlich.

47
Conor Mancone

Im Allgemeinen tritt CSRF auf, wenn ein Browser automatisch Header hinzufügt (d. H. Sitzungs-ID in einem Cookie) und die Sitzung dann authentifiziert. Inhaber-Token oder andere auf HTTP-Headern basierende Token, die manuell hinzugefügt werden müssen, verhindern, dass Sie CSRF ausführen.

Natürlich, aber eine Art Off-Topic, wenn Sie eine XSS-Sicherheitslücke haben, könnte ein Angreifer immer noch auf diese Token zugreifen, aber dann wird es kein CSRF-Fehler.

23
ndrix

Frühere Antworten sind absolut solide. Ich werde hier hineinspringen, um mehr Kontext und eine kleine Einschränkung zu bieten. Es gibt viele Möglichkeiten, JWT zu verwenden. Sitzungsmanagement ist einer von ihnen. Obwohl es weist einige Nachteile auf beim Umgang mit Zeitüberschreitungen und erweiterten Anforderungen wie der erneuten Authentifizierung.

Außerdem habe ich gesehen, wie JWT in Cookies platziert wurde. Wie andere bereits gesagt haben, kommt der CSRF-Schutz nicht von der Verwendung eines JWT selbst. Es kommt von der Übermittlung als Authorization - Header unter Verwendung des Bearer [JWT] planen.

Frage 1: Füge ich zusätzliche Sicherheit hinzu, wenn ich jeder Anforderung einen X-XSRF-Token-Header hinzufüge und beispielsweise den Mechanismus zustandslos mache, indem ich in JWT-Nutzdaten auf denselben Wert überprüfe? (Ich habe darüber in diesem Thread gelesen)

Wenn Sie es über XHR als Autorisierungsheader senden, führt kein zusätzlicher X-XSRF-Token-Header zu keiner "zusätzlichen" Sicherheit .

Frage 2: Brauche ich zusätzliche Sicherheitsmaßnahmen gegen CSRF, wenn ich alles nehme, was ich beschrieben habe?

Nein , Ihr aktuelles Setup ist in Ordnung.

Vor einiger Zeit habe ich ein Handbuch für Webauthentifizierungstechniken und deren Sicherheitseigenschaften zusammengestellt (es hat auch ein JWT-Teil ). Hier ist der letzter Spickzettel , der alle Methoden in kompakter Form beschreibt.

9
Daniel Szpisjak

Ich halte es für wichtig, etwas in Bezug auf Einzelseitenanwendungen (oder Anfragen von jedem Frontend im Allgemeinen) hervorzuheben, das den CSRF-Schutz möglicherweise unbrauchbar macht. Anfangs dachte ich, dass es hier vielleicht etwas vom Thema abweicht, aber ich überlege es mir noch einmal (siehe meine Anmerkung unten).

Mein Punkt: Vielleicht haben Sie einen Frontend-Anwendungscode, der beim Laden der App von einer URL automatisch eine Anfrage an eine API sendet (eines der häufigsten Beispiele ist die Überprüfung einer E-Mail-Adresse). In diesem Fall ist es völlig irrelevant, ob Sie CSRF haben oder nicht. Sobald in Ihrer Frontend-App etwas passiert, ohne dass eine bestimmte Benutzeraktion erforderlich ist, ist der CRSF-Schutz irrelevant, da ein Angreifer eine "legitime" Möglichkeit hat, eine Aktion auszuführen, indem Sie einfach Ihre Frontend-App öffnen.

Einige Beispiele für Aktionen, die möglicherweise automatisch auf der Frontend-Seite ausgeführt werden

  • Authentifizierung (Generieren von Zugriffstoken usw.)
  • E-Mail validieren
  • Folgen Sie einem E-Mail-Link, um einige Inhalte automatisch zu bewerten
  • (un) Abonnieren von E-Mails/Newslettern
  • herunterladen einer Datei (wenn die Frontend-App einige Dinge vorverarbeitet, bevor die Download-Anfrage an den Server weitergeleitet wird)
  • Beitritt zu einem Projekt, einer Gruppe
  • Überprüfen eines Referrer-Codes

Einige dieser Anwendungsfälle (wie das Validieren einer E-Mail) erfordern möglicherweise keine Authentifizierung und sind relativ harmlos, andere (wie das Beitreten zu einer Gruppe) sind nur dann sinnvoll, wenn Sie authentifiziert sind. Dies bedeutet, dass Sie eine Möglichkeit haben, eine authentifizierte Anfrage automatisch auszuführen eine API. Es ist vielleicht weniger gefährlich, wenn der Benutzer ein direktes Feedback zu dem hat, was passiert ist (vorausgesetzt, Ihr Frontend gibt Ihren Benutzern Ihr Feedback) und wenn sie diese Vorgänge rückgängig machen können, aber es bleibt ein Angriffsvektor.

Wir denken oft an "CSRF" als eine Möglichkeit, sich vor Anfragen zu schützen, die direkt an eine Server-App oder eine API gesendet werden. Korrigieren Sie mich, wenn ich falsch liege, aber die Definition scheint jeden Angriff zu umfassen, bei dem die böswillige Person das Ergebnis des Geschehens nicht sehen kann, einschließlich der Verwendung des Frontend-App-Codes.

0