it-swarm.com.de

CSRF-Token in GET-Anforderung

Gemäß dem OWASP-Testleitfaden sollte ein CSRF-Token nicht in einer GET-Anforderung enthalten sein, da das Token selbst möglicherweise an verschiedenen Stellen wie Protokollen oder aufgrund des Risikos des Schulter-Surfens protokolliert wird.

Ich habe mich gefragt, ob Sie die Verwendung des CSRF-Tokens nur einmal zulassen (nach einer Anfrage ist es also ungültig). Wäre dies immer noch unsicher? In Anbetracht dessen, dass das Token zum Zeitpunkt der Protokollierung bereits ungültig und unbrauchbar ist, falls der Angreifer CSRF ausführen möchte.

18
Lucas Kauffman

Wenn Sie die Token auf sichere zufällige Weise generieren, kann ein Angreifer den nächsten Token nicht aus den vorherigen ableiten. Es sollte also kein realistisches Risiko bestehen.

Ein weiterer wichtiger Punkt ist die Verwendung von SSL. Proxys/Reverse-Proxys zwischen dem Benutzer und dem Server können nicht einmal die GET-Parameter sehen, um sie zu protokollieren. Die einzigen Stellen, an denen das Token protokolliert wird, befinden sich an den beiden Enden der SSL-Verbindung.

Die Anmeldung am Ende des Benutzers (z. B. Verlauf) erfolgt nach dem Klicken auf den Link. Die Anmeldung auf der Serverseite birgt kein Risiko (wenn Sie dem Ort, an dem der SSL-Verkehr entschlüsselt wird, nicht vertrauen, treten größere Probleme auf).

13
Adi

GET-Anforderungen sollten idempotent sein. Dies bedeutet, dass Sie das einmal verwendete Token nicht ungültig machen können, da wiederholte Anforderungen nicht dieselbe Antwort geben.

GET-Anforderungen sollten auch niemals Statusänderungen am System vornehmen, daher sollte kein CSRF-Schutz erforderlich sein. Selbst das Abmelden sollte keine GET-Anforderung für die Methode sein, die das Abmelden tatsächlich ausführt (obwohl Sie möglicherweise einen GET-Link haben, der zu einer anderen Seite navigiert, bevor eine POST -Anforderung die Aktion ausführt).

Um das idempotente Problem zu beheben, können Sie mit einer wiederholten GET-Anforderung und demselben CSRF-Token die zwischengespeicherte Antwort der ersten Anforderung anzeigen, ohne eine Statusänderung vorzunehmen. Sie verstoßen jedoch immer noch gegen den Standard, wenn Sie Statusänderungen vornehmen, siehe rfc7231 :

Anforderungsmethoden gelten als "sicher", wenn ihre Semantik definiert ist
im Wesentlichen schreibgeschützt

Von den durch diese Spezifikation definierten Anforderungsmethoden sind GET, HEAD,
OPTIONEN und TRACE-Methoden sind als sicher definiert.

Als Randnotiz würde ich auch argumentieren, dass ressourcenintensive Prozesse auch POSTs (mit CSRF-Schutz) anstelle von GETs sein sollten, andernfalls könnte ein Angreifer ein System unter Verwendung eines CSRF-Vektors ausführen.

Wenn Sie CSRF für eine Methode benötigen, implementieren Sie dies daher nicht als GET.

8
SilverlightFox

In Anbetracht dessen, dass das Token zum Zeitpunkt der Protokollierung bereits ungültig und unbrauchbar ist, falls der Angreifer CSRF ausführen möchte.

Es gibt einen Eckfall, wenn der Benutzer die Adresse erhält, das Token jedoch nicht tatsächlich verwendet (aufgrund vorübergehender Netzwerkfehler usw.). Es ist unwahrscheinlich, dass dies wichtig genug ist, um sich Sorgen um ein CSRF-Token zu machen, aber es kann ein Problem für andere empfindlichere Token sein.

Einweg-CSRF-Token neigen jedoch dazu, Usability-Probleme zu verursachen, wie z. B. das Unterbrechen der Navigation und das Durchsuchen mehrerer Registerkarten. Ganz zu schweigen davon, dass sie sehr hässlich sind. :-) Da GET-Anfragen idempotent sein sollten und daher keinen CSRF-Schutz benötigen, ist Token-in-URL normalerweise ein Designgeruch. Aber ich bezweifle, dass Sie hier viel ausnutzen können.

5
bobince

Es ist wahrscheinlich sicher genug, aber es beseitigt das Problem des Surfens und Protokollierens der Schulter nicht vollständig. Ein Angreifer kann das Netzwerk vorübergehend als DoS verwenden, damit er ein Schulter-Surf-Token verwenden kann, bevor der Benutzer die Möglichkeit dazu erhält. Eine Anforderung wird möglicherweise in Protokollen angezeigt, jedoch nicht ungültig, wenn die Website (oder Datenbank oder das Netzwerk) währenddessen nicht verfügbar ist eine versuchte Seitenladung. Darüber hinaus kann ich mir keine Schwachstellen vorstellen, die nicht auch auftreten, wenn Sie das Token in POST-Daten einfügen.

Ich bin mir nicht sicher, ob es praktisch ist, alle Token nach der Verwendung ungültig zu machen. Ich öffne häufig mehrere Seiten in einer neuen Hintergrundregisterkarte, z. B. in älteren SMF-Foren. Klicken Sie mit der mittleren Maustaste auf die Schaltfläche "Löschen" für private Nachrichten, damit die Seite nicht neu geladen werden muss, bevor ich eine andere löschen kann. Sie können ein eindeutiges Token für alle Links generieren, die auf einer Seite angezeigt werden. Dann erreichen Sie jedoch einen Komplexitätsgrad, bei dem Sie genauso gut HMACs anstelle eines einfachen Tokens verwenden können.

3
Luc