Es hört sich so an, als ob Ihr Einwand, die Sitzung offen zu lassen, solange der Browser geöffnet ist, das Problem automatisierter Angriffe ist. Leider schreckt das Aktualisieren des Tokens bei jedem Seitenaufruf nur die meisten Amateurangreifer ab.
Erstens nehme ich an, dass wir über Angriffe sprechen, die speziell auf Ihre Website abzielen. (Wenn wir über die Bots sprechen, die einfach herumlaufen und verschiedene Formulare einreichen, würde dies sie nicht nur nicht aufhalten, sondern es gibt weitaus bessere und einfachere Möglichkeiten, dies zu tun.) Wenn das der Fall ist, und ich ziele auf meine Website, hier ist, was mein Bot tun würde:
- Formularseite laden.
- Token auf Formularseite lesen.
- Senden Sie eine automatisierte Anfrage mit diesem Token.
- Gehen Sie zu Schritt 1.
(Oder, wenn ich Ihr System ausreichend untersucht habe, würde ich erkennen, dass ich ein Token für immer behalten könnte, wenn ich den Header „this is AJAX“ in jede Anfrage einfüge. Oder ich würde erkennen, dass das Token meine Sitzungs-ID ist, und meine eigene PHPSESSID senden Cookie.)
Diese Methode, das Token bei jedem Seitenaufruf zu ändern, würde absolut nichts dazu beitragen, jemanden aufzuhalten, der tatsächlich wollte dich so heftig anzugreifen. Da das Token keine Auswirkung auf die Automatisierung hat, konzentrieren Sie sich daher auf seine Auswirkungen auf CSRF.
Aus der Sicht des Blockierens von CSRF scheint das Erstellen eines Tokens und dessen Beibehaltung, bis der Benutzer den Browser schließt, alle Ziele zu erreichen. Einfache CSRF-Angriffe werden abgewehrt und der Benutzer kann mehrere Registerkarten öffnen.
TL;DR:Das einmalige Aktualisieren des Tokens bei jeder Anfrage erhöht die Sicherheit nicht. Entscheiden Sie sich für Benutzerfreundlichkeit und erstellen Sie ein Token pro Sitzung.
Jedoch! Wenn Sie sich große Sorgen über doppelte Formularübermittlungen machen, versehentlich oder aus anderen Gründen, kann dieses Problem dennoch leicht gelöst werden. Die Antwort ist einfach:Verwenden Sie zwei Token für zwei verschiedene Jobs.
Das erste Token bleibt gleich, bis die Browsersitzung endet. Dieses Token existiert, um CSRF-Angriffe zu verhindern. Jede Übermittlung von diesem Benutzer mit diesem Token wird akzeptiert.
Das zweite Token wird für jedes geladene Formular eindeutig generiert und in einer Liste in den Sitzungsdaten des Benutzers von offenen Formulartoken gespeichert. Dieses Token ist einzigartig und wird ungültig, sobald es verwendet wird. Einreichungen von diesem Benutzer mit diesem Token werden nur einmal akzeptiert.
Wenn ich auf diese Weise eine Registerkarte für Formular A und eine Registerkarte für Formular B öffne, hat jeder mein persönliches Anti-CSRF-Token (CSRF erledigt) und mein einmaliges Formulartoken (Erneutseinreichung des Formulars erledigt). Beide Probleme werden ohne negative Auswirkungen auf die Benutzererfahrung gelöst.
Natürlich können Sie entscheiden, dass die Implementierung für eine so einfache Funktion zu viel ist. Ich denke jedenfalls. Unabhängig davon gibt es eine solide Lösung, wenn Sie es wollen.
