Mein Freund und ich haben ein paar Bier.
Aus Wikipedia:
Erfordert ein Geheimnis, benutzerspezifisch Token in allen Formulareinreichungen und Nebeneffekt-URLs verhindern CSRF; das Angreifer-Site kann nicht das Recht setzen Token in seinen Einreichungen
Der Atacker kann Browser-Cookies indirekt nutzen, aber er kann sie nicht direkt verwenden!
Deshalb kann er die Cookies nicht mit document.write()
Schauen wir uns an, wie der Logout-Link generiert wird. Ist es sicherer Weg? Kann diese GET-Anfrage gefälscht werden?
%Vor%sid ist eine Sitzungs-ID, die für jede Sitzung generiert wird
Auf der Serverseite wird folgende Überprüfung durchgeführt:
%Vor%Absolut nicht ! Verwenden Sie niemals Sitzungs-IDs für den CSRF-Schutz.
Was ist warum? Nun, die Antwort ist einfach. Dies öffnet die Tür für Angriffe Session-Hijacking . Stellen Sie sich vor, jemand kopiert und fügt den Link aus irgendeinem Grund in eine E-Mail oder ins Web ein. Jetzt hat die Person am anderen Ende der E-Mail die Sitzungs-ID dieser Sitzung. Sicher, wenn sie auf den Link klicken, wird sie die Sitzung nicht aktivieren, aber jemand, der weiß, was sie tut, kann sie trotzdem benutzen.
Und benutze auch kein geheimes Cookie. Cookies werden bei jeder Anfrage übertragen. Die bloße Existenz eines Cookies bestätigt nicht, dass der Benutzer die Anfrage stellen wollte.
Wie geht es stattdessen? Folgen Sie den OWASP Empfehlungen . Verwenden Sie ein eindeutiges, zufälliges Token, das bei jeder Anforderung ausgegeben wird und der Sitzung zugeordnet ist. Stellen Sie dann sicher, dass das Token bei der Übertragung gültig ist und dann das Token ungültig macht ! Es sollte nur ein Einmal-Token sein. Habe es per Formular eingereicht und nicht direkt an einen Link angehängt ...
Dieses Sicherheitssystem ist immun gegen CSRF . Der Grund dafür ist, dass der Browser bei einem CSRF-Angriff den Cookie verfolgt, sodass der Angreifer den Cookie-Wert nicht wissen muss, wenn er die Anfrage erstellt . Wenn dieses vorgeschlagene Sicherheitssystem anfällig für CSRF wäre, würde ein Exploit wie der folgende Proof of Concept einen Browser abmelden:
<img src=http://victim_site/index.php?action=logout&sid= />
Offensichtlich braucht sid in diesem Fall einen Wert, und ein Angreifer kann diesen Wert nicht ohne Verwendung von XSS erhalten, was dies zu einem strittigen Punkt macht. Mit xss kann ein Angreifer ein CSRF-Token lesen, um Anfragen zu fälschen. Dies wurde im MySpace-Wurm Sammy verwendet.
Die Verwendung des Cookies eine gültige, jedoch schwächere Form des CSRF-Schutzes. Ein Problem ist, dass es Ссылка völlig unterminiert. Im Idealfall sollte ein CSRF-Token und eine Sitzungs-ID ein kryptografisches Nonce sein. Es ist jedoch sicherer, separate Werte zu haben.
Bearbeiten : Diese Antwort ist zumindest teilweise falsch. Die Verwendung der Sitzungs-ID als CSRF-Token könnte zu Session-Hijacking führen, wenn z. B. Links kopiert und eingefügt werden. Siehe ircmaxells Antwort und Kommentare.
Ja, da die Sitzungs-ID sowohl zufällig als auch mit dem Benutzer verknüpft ist, wäre dies eine akzeptable Form des CSRF-Schutzes.
Das heißt, es wäre noch sicherer , eine andere Zufallszahl zu verwenden, mit der Ausnahme, dass bösartiges JavaScript den Session-Cookie (und die Session-ID) erfassen kann ... Aber wenn ich müsste Wählen Sie zwischen "Kein CSRF-Token" und "Sitzungs-ID als CSRF-Token". Ich würde die Sitzung immer als CSRF-Token auswählen.
Das einzige mögliche Problem bei der Verwendung von Sitzungs-IDs als CSRF-Token ist: Wenn jemand ein CSRF-Token stehlen könnte, wäre er auch in der Lage, die zugehörige Sitzung zu übernehmen ... Aber ich kann mir kein vernünftiges Szenario vorstellen ein Problem sein.
Nun, aus der Diskussion über Marc B's Antwort, unten: die Verwendung eines nonce würde anderen Vorteile (wie das Vermeiden von doppelten Formulareinreichungen) ... Aber es ist nicht sicherer gegen CSRF-Angriffe als die Sitzungs-ID (mit dem einen Vorbehalt, den ich im ersten, zweiten Absatz erwähne).
Siehe auch: CSRF-Validierungs-Token: Sitzungs-ID sicher?
Und was soll jemanden daran hindern, den HTML-Code, den Sie ihm schicken, sowie den Cookie, den Sie ihm auch gesendet haben, zu bearbeiten? Beide sind unter der Kontrolle des Benutzers.
Mit Firebug kann ich den Inhalt jeder Seite sowie jedes Cookie trivial ändern.
Wenn Sie nun Ihre Version so geändert haben, dass der SERVER diese ID speichert, wäre es schwerer zu hacken ...
%Vor%Da die Sitzungsdaten auf dem Server gespeichert sind, ist dies für den Angreifer weitaus sicherer als zu glauben, dass der Angreifer nicht daran denkt, den Cookie zu ändern.
Sie schulden Ihrem Freund ein Bier.