Es gibt eine gute Erklärung für OWASP: OWASP CSRF Prevention Cheat Sheet

Kurz gesagt, es gibt zwei Möglichkeiten:

1. Fügen Sie jeder Benutzersitzung ein zufälliges Token hinzu. Nur wenn dieses Token vorhanden und korrekt ist, werden die Änderungen übernommen, andernfalls sollte die Anforderung abgelehnt werden. Es ist wichtig, dass das Token nur mit einer POST-Anforderung gesendet wird, da GET-Anforderungen das Token an verschiedene Stellen (Browserverlauf, Protokolldateien usw.) übertragen können.

   Es ist auch möglich, ein Token zu generieren pro Anfrage, aber dies führt zu Usability-Problemen. Zum Beispiel würde die Zurück-Taste nicht mehr richtig funktionieren. Aber natürlich würde die Sicherheit erhöht.

   Stellen Sie außerdem sicher (um die Sicherheit noch weiter zu verbessern), dass das Token nur über TLS gesendet wird, damit sich kein Mann in den mittleren Problemen befindet.

2. Die andere Option ist die Verwendung einer Herausforderung - Antwort (z. B. CAPTCHAs oder einmalige Token).

ol>

Die OWASP-Seite listet auch einige Maßnahmen auf, die nicht funktionieren. Dies sind

• Verwenden von (geheimen) Cookies
• Verwenden von GET-Anfragen
• Mehrschritttransaktionen
• URL Rewriting

Der beste Weg, um den CSRF-Schutz ordnungsgemäß zu erstellen:

Nicht.

In den meisten gängigen Frameworks ist dieser Schutz bereits integriert (ASP.NET) , Struts, Ruby (glaube ich) oder es gibt bereits Bibliotheken, die bereits überprüft wurden. (z. B. CSRFGuard von OWASP).

Abhängig von Ihrem Kontext besteht eine weitere Option darin, die erneute Authentifizierung des Benutzers zu erzwingen, jedoch nur für bestimmte, vertrauliche Vorgänge.

Laut Ihren Kommentaren ist Ihre Lösung nicht schlecht, wenn Sie dies selbst implementieren müssen, aber ich würde es vereinfachen.
Sie können eine kryptozufällige Nonce generieren (lang genug) ), speichern Sie das im Sitzungsspeicher und ändern Sie es alle X Minuten (Sie speichern die Ablaufzeit auch in der Sitzung). In jedem Formular fügen Sie die Nonce in ein ausgeblendetes Formularfeld ein und vergleichen diesen Wert, wenn das Formular veröffentlicht wird.
Wenn das Formular-Token übereinstimmt, sind Sie klar. Wenn nicht, können Sie z. das vorherige Token auch, um die Randfälle zu behandeln.

Obwohl ich sagen muss, dass ich zu viele fehlgeschlagene Versuche gesehen habe, dies selbst zu implementieren, um diesen Pfad wirklich zu empfehlen. Sie sind immer noch besser dran, ein minimales Paket zu finden, das dies für Sie erledigt.

Zusätzlich zur Antwort von @Andreas Arnold gibt es eine Alternative. Ich habe das Encrypted Token Pattern von OWasp implementiert.

Abgesehen von der Verhinderung von CSRF-Angriffen hat es den zusätzlichen Vorteil, dass die Objektsicherheit implementiert wird.

Dies können nur diejenigen tun, die berechtigt sind, Objekte zu ändern. Andere haben nicht den richtigen / gültigen Chiffretext oder Schlüssel. Normalerweise verschlüssele ich sessionId , timestamp , userId und / oder recordId .

timestamp verhindert replayAttacks. sessionid isoliert Änderungen nur an dieser Sitzung userId isoliert Änderungen nur an diesem Benutzer. Wenn Sie recordId einschließen Auf Kosten der zusätzlichen Verarbeitung erhalten Sie mehr Sicherheit.

Ich glaube nicht, dass es viel Falsches gibt (obwohl ich mich vielleicht irre;), einen Zeitstempel in das zu hashende Token aufzunehmen und diesen Zeitstempel als verstecktes Formularfeld einzuschließen - möglicherweise hexadezimal als grundlegende Verschleierung codiert -, können Sie Überprüfen Sie dann bei der Einreichung, ob sie abgestanden sind.

Ich neige dazu zu denken, dass der tokenbasierte CSRF-Schutz ziemlich leicht aufgehoben werden kann: Ein Angreifer muss nur wissen, wie er eine CSRF-geschützte Seite anfordert. Normalerweise haben diese Seiten das Token als verstecktes Feld. Der Angreifer greift dann nach dem Token von der Seite (ziemlich trivial) und verwendet ihn, um einen CSRF-Angriff zu erstellen.