Aus den bereits diskutierten Gründen ist es nicht erforderlich, pro Anforderung ein neues Token zu generieren. Es bringt fast keinen Sicherheitsvorteil und kostet Sie in Bezug auf die Benutzerfreundlichkeit: Wenn nur ein Token gleichzeitig gültig ist, kann der Benutzer nicht normal in der Webanwendung navigieren. Wenn sie beispielsweise auf die Schaltfläche "Zurück" klicken und das Formular mit neuen Werten senden, schlägt die Übermittlung fehl und sie werden wahrscheinlich mit einer feindlichen Fehlermeldung begrüßt. Wenn sie versuchen, eine Ressource auf einer zweiten Registerkarte zu öffnen, wird die Sitzung zufällig auf einer oder beiden Registerkarten unterbrochen. In der Regel lohnt es sich nicht, die Benutzerfreundlichkeit Ihrer Anwendung zu beeinträchtigen, um diese sinnlose Anforderung zu erfüllen.

Es gibt jedoch einen Ort, an dem es sich lohnt, ein neues CSRF-Token auszustellen: bei einer Hauptänderung im Inneren eine Sitzung. Das ist vor allem beim Login. Dies soll einen Sitzungsfixierungsangriff verhindern, der zu einer CSRF-Angriffsmöglichkeit führt.

Beispiel: Der Angreifer greift auf die Site zu und generiert eine neue Sitzung. Sie nehmen die Sitzungs-ID und fügen sie in den Browser eines Opfers ein (z. B. durch Schreiben eines Cookies aus einer anfälligen Nachbardomäne oder mithilfe einer anderen Sicherheitsanfälligkeit wie jsessionid-URLs) und fügen das CSRF-Token in ein Formular im Browser des Opfers ein. Sie warten darauf, dass sich das Opfer mit diesem Formular anmeldet, und verwenden dann einen anderen Formularbeitrag, um das Opfer zu veranlassen, eine Aktion mit dem noch aktiven CSRF-Token auszuführen.

Um dies zu verhindern, machen Sie das CSRF-Token und ungültig Stellen Sie an den Stellen (wie beim Anmelden), an denen Sie bereits dasselbe mit der Sitzungs-ID tun, eine neue aus, um Angriffe zur Sitzungsfixierung zu verhindern.

Übersicht. Standardmäßig wird empfohlen, ein eindeutiges CSRF-Token zu verwenden, das für jede Anforderung eindeutig ist. Warum? Weil ein Token pro Anforderung gegenüber bestimmten Arten von Implementierungsfehlern etwas widerstandsfähiger ist als ein Token pro Sitzung. Dies macht Token pro Anfrage wohl zur besten Wahl für die Entwicklung neuer Webanwendungen. Außerdem wird Sie kein Sicherheitsprüfer mit der Verwendung eines CSRF-Tokens pro Anforderung belästigen.

Wenn Sie ein Webanwendungsentwickler sind, ist dies alles, was Sie wissen müssen, und Sie können hier aufhören zu lesen. Wenn Sie jedoch ein Sicherheitsexperte sind, der sich über die detaillierten Gründe für diesen Rat wundert oder sich fragt, wie hoch das Risiko ist, wenn Sie ein Token pro Sitzung verwenden, lesen Sie weiter ....

Ein bisschen tiefer gehen. Die Wahrheit ist, dass ein einzelnes CSRF-Token pro Sitzung in Ordnung ist, wenn Sie keine anderen Schwachstellen auf Ihrer Website haben. Es gibt keinen Grund, warum Sie unbedingt ein neues CSRF-Token pro Anfrage generieren müssen.

Dies wird durch die Tatsache belegt, dass Sie auch seriöse Sicherheitsexperten finden, die dies für sinnvoll halten Um sich gegen CSRF zu verteidigen, verwenden Sie die doppelte Übermittlung von Cookies. Mit anderen Worten, Sie verwenden clientseitiges Javascript, das einen Hash des Sitzungscookies berechnet und diesen zu jeder POST-Anforderung hinzufügt und den Hash als CSRF-Token behandelt. Sie können sehen, dass dies im Wesentlichen im laufenden Betrieb ein CSRF-Token generiert, das für die gesamte Sitzung gleich ist.

Natürlich kenne ich das Argument, warum manche Leute empfehlen könnten, für jede Anfrage ein neues CSRF-Token zu generieren. Sie denken, wenn Sie auch eine XSS-Sicherheitsanfälligkeit auf Ihrer Website haben, ist es bei Verwendung eines einzelnen CSRF-Tokens pro Sitzung einfach, XSS zum Wiederherstellen des CSRF-Tokens zu verwenden. Wenn Sie jedoch pro Anforderung ein neues CSRF-Token generieren, ist dies der Fall wird mehr Arbeit erfordern, um das CSRF-Token wiederherzustellen. Persönlich finde ich das kein schrecklich überzeugendes Argument. Wenn Ihre Site eine XSS-Sicherheitsanfälligkeit aufweist, können CSRF-Token auch dann wiederhergestellt werden, wenn Sie für jede Anforderung ein neues CSRF-Token generieren. Es sind nur ein paar zusätzliche Zeilen schädlichen Javascript erforderlich. In beiden Fällen ist es schwierig, die Sicherheit zu gewährleisten, wenn Sie eine XSS-Sicherheitsanfälligkeit auf Ihrer Website haben und einem ernsthaften, sachkundigen Angreifer ausgesetzt sind, unabhängig davon, wie Sie Ihre CSRF-Token generieren.

Insgesamt kann dies nicht schaden um für jede Anfrage ein neues CSRF-Token zu generieren. Und vielleicht ist es besser, es so zu machen, nur um Sicherheitsprüfer von Ihrem Rücken zu bekommen. Wenn Sie jedoch bereits eine Legacy-Anwendung haben, die ein einzelnes CSRF-Token für die gesamte Sitzung verwendet, würde das Ausgeben des Geldes für die Konvertierung zur Generierung eines neuen CSRF-Tokens für jede Anforderung wahrscheinlich nicht ganz oben auf meiner Prioritätenliste stehen: Ich wette, ich könnte einige andere Verwendungszwecke für dieses Geld und die Entwicklerenergie finden, die die Sicherheit noch weiter verbessern würden.

XSS kann zum Lesen eines CSRF-Tokens verwendet werden, auch wenn es sich um ein einzelnes Submit-Token handelt. Dies ist ein Kinderspiel. Es ist wahrscheinlich, dass diese Empfehlung für ein einzelnes Übermittlungstoken von jemandem stammt, der CSRF nicht versteht.

Der einzige Grund für die Verwendung eines "einzelnen Übermittlungstokens" besteht darin, dass Sie verhindern möchten, dass der Benutzer versehentlich auf "Senden" klickt zweimal. Eine gute Verwendung besteht darin, zu verhindern, dass der Benutzer zweimal auf "Kasse" klickt und den Kunden versehentlich zweimal belastet.

Ein CAPTCHA oder die Abfrage des aktuellen Kennworts des Benutzers kann als Anti-CSRF-Maßnahme verwendet werden, die dies nicht kann von XSS umgangen werden.

Ich empfehle, das CSRF Prevention Cheat Sheet zu lesen.

Wenn das Token während der gesamten Sitzung gleich ist, kann ein Angreifer möglicherweise ein Token von einer Seite verlieren und es für eine andere Aktion verwenden.

Sie können beispielsweise ein Token verwenden Wenn Sie eine Seite laden möchten, extrahieren Sie das Token mithilfe einer XSS-Sicherheitsanfälligkeit. Von dort aus können Sie dieses Token verwenden, um ein Kennwortänderungsformular zu senden.

Die Verwendung eines Tokens pro Anforderung anstelle eines sitzungsweiten Tokens erschwert dies, verhindert jedoch nicht CSRF. Ein Angreifer kann einfach ein XSS nutzen, um das Token von der Seite zu lesen und es dann abzufeuern. Wenn das Token jedoch global ist und nicht auf diese einzelne Seite beschränkt ist, kann ein Angreifer auf jede Seite zielen, um das Token zu stehlen. Die Verwendung separater Token für jede Anforderung erschwert dies erheblich.

Neben den anderen Antworten ist es möglicherweise ratsam, das Token auch zu aktualisieren, wenn Ihr Server für den BREACH-Angriff anfällig ist.

Dies erfordert die folgenden drei Bedingungen:

• Wird von einem Server bereitgestellt, der die Komprimierung auf HTTP-Ebene verwendet.
• Reflektiert Benutzereingaben in HTTP-Antwortkörpern
• Reflektiert ein Geheimnis (z als CSRF-Token ) in HTTP-Antwortkörpern

/ blockquote>

Um BREACH zu verringern, müssten Sie das CSRF-Token in der GET-Anforderung aktualisieren, die ein Formular lädt um alle vorherigen Token ungültig zu machen. Auf diese Weise erhält ein MITM (Man-In-The-Middle), der zusätzliche Anforderungen zum Erkennen des Tokens auf der Seite erstellt, jedes Mal ein anderes Token. Dies bedeutet, dass der echte Benutzer das Formular in einer MITM-Situation nicht senden kann.

Natürlich benötigen Sie die beiden anderen Bedingungen, um auch zu gelten. Es wäre wahrscheinlich einfacher, ein CSRF-Token pro Sitzung zu verwalten und die Komprimierung auf HTTP-Ebene für alle Seiten zu deaktivieren, die Formulare bereitstellen.

Es ist keine sehr bekannte Tatsache, aber ein normaler String-Vergleich ist anfällig für Timing-Angriffe ( wie dieser. Kurz gesagt, normale String-Vergleichsoperationen ( == code) > oder === ) vergleicht zwei Zeichenfolgen zeichenweise von links nach rechts und gibt false zurück, sobald sie auf ein Zeichen gestoßen sind, das an einer bestimmten Position in beiden Zeichenfolgen nicht gleich ist. Dies ergibt ein Winzchen Unterschied im Timing, der sich als erkennbar erwiesen hat.

Durch die Verwendung eines Timing-Angriffs, um jedes mögliche Zeichen für jede Position auszuprobieren, ist es möglich, den tatsächlichen Token zu ermitteln. Durch das Erstellen eines neuen Tokens bei jeder Übermittlung einer Anforderung mit einem Token kann dieser Angriff verhindert werden.

Dies funktioniert natürlich nur, wenn Sie das Token auch neu erstellen, wenn ein ungültig ist Es wurde ein Token gesendet, was möglicherweise unerwünscht ist. Daher sollten Sie dies besser beheben, indem Sie eine zeitunempfindliche Zeichenfolgenvergleichsfunktion wie diese verwenden.

Ein Grund für die Änderung des CSRF-Tokens pro Anforderung besteht darin, das Komprimierungsleck des Tokens zu verringern. Damit meine ich, dass wenn der Angreifer Eve Daten auf eine Seite einfügen kann, die das Token enthält, an das die Seite komprimiert gesendet wird, Eve das erste Zeichen der Zeichenfolge erraten kann, die einen kleineren Datensatz für die Seite erhält, und weiß, dass sie richtig geraten hat weiter zum nächsten Zeichen.

Dies ähnelt einem Timing-Angriff.

Im Moment gibt es keinen Grund (den ich kenne), das Token zu ändern, wenn es nur in den HTTP-Headern gesendet wird.

Eine andere Methode besteht darin, das Token zu ändern, sobald eine fehlgeschlagene Anforderung entdeckt wird. Dies kann jedoch zu Problemen führen, wenn der Benutzer kein Formular senden kann.

Wenn dasselbe Token für die gesamte Sitzung verwendet wird, besteht die Wahrscheinlichkeit, dass ein Angreifer das Token mit XSS entführen und die Sitzung des Opfers verwenden kann, um böswillige Aktivitäten wie das Ändern des Kennworts auszuführen .

Sie können Passwörter durchsuchen, indem sie einen Iframe in die von Ihnen verwendete Site einfügen.

Es ist daher besser, ein Token pro Anforderung zu verwenden, um zu verhindern, dass der Angreifer gewinnt Zugriff auf dieses Token.