CSRF Schutz durch Speichern Nonce in Session variable Form und

Question

Zum Schutz vor CSRF sollten Sie eine Nonce in einem versteckten Bereich in Form gebracht und in einem Cookie oder in den Session-Variablen. Was aber, wenn der Benutzer öffnet mehrere Seiten in verschiedenen Tabs? In diesem Fall würde jeder Reiter ein Formular mit einem einzigartigen nonce, aber es würde nur eine Nonce in den Session-Variablen oder Cookies gespeichert werden. Oder wenn Sie versuchen, alle Nonces im Cookie / Session-Variable zu speichern, wie würden Sie erkennen, die man zu welcher Form gehört?

Answer 1

Sie können speichern die gleiche Nonce in jeder der Formen. Der einfachste Weg, es zu tun, ist die Nonce an der Session-ID zu binden, so dass diese Formen nur Arbeit in dieser Sitzung.

Sie wollen es schwer zu Snarf Session-IDs für Angreifer machen und ihre eigenen Nonces erstellen. Also, ein Weg, um darüber zu gehen ist HMAC-SHA256 zu verwenden (oder ähnliches) zu hash die Session-ID, mit einem Schlüssel, dass Sie das Gerät nicht an die Öffentlichkeit.

(Natürlich, wenn der Angreifer kann erhalten die eigentliche Session-ID selbst, können sie bereits Session Hijacking tun. Also das ist nicht das, was ich rede, sondern die Fähigkeit, für einen Angreifer ein Skript Handwerk (das läuft auf die Opfer Computer), die irgendwie die Session-ID und verwenden, die mit vorgefüllten dynamisch eine URL mit dem nonce erzeugen greifen kann.)

---

ETA: Ob der obige Ansatz ist allein reicht hängt davon ab, wie lange Sie Ihre typischen Sitzungen zum letzten erwarten. Wenn die Benutzer in der Regel verwenden langlebige Sitzungen Spanning länger als ein paar Stunden, müssen Sie verwenden, um etwas raffinierter.

Ein Ansatz ist es, eine neue Nonce für jedes Formular zu erstellen, die den Zeitstempel enthält, sowie hash(timestamp . sessionid) (wo hash eine Variante von HMAC ist, wie oben beschrieben, Fälschung zu verhindern, und . ist String-Verkettung). Sie überprüfen, dann die Nonce von:

1. den Zeitstempel überprüft, um sicherzustellen, dass die Nonce frisch genug ist (dies ist zu Ihrer Politik, aber ein paar Stunden sind typisch)
2. dann die Berechnung des Hash auf der Basis der Zeitstempel und Sitzungs-ID und den Vergleich gegen die Nonce, um sicherzustellen, dass die Nonce authentisch ist

Wenn die Nonce Prüfung fehlschlägt, werden Sie ein neues Formular angezeigt werden sollen, vorausgefüllt mit dem Vorbringen der Benutzer (so dass, wenn sie einen ganzen Tag nehmen ihren Beitrag zu schreiben, werden sie nicht all ihre harte Arbeit verlieren) sowie eine frische nonce. Dann kann der Benutzer erneut auf Anhieb erfolgreich.

Answer 2

Was Sie beschreiben, ist kein nonce mehr (nonce = Nummer verwendet einmal ), es ist nur eine Session-Kennung. Der ganze Sinn eines Nonce ist, dass es nur für eine einzige Form Vorlage ist daher bietet größere Sicherheit gegen Hijacking als nur eine Session-ID, aber auf Kosten der nicht in der Lage mehr Registerkarten auf der Seite parallel zu haben, arbeiten.

Nonces sind viel des Guten für viele Zwecke. Wenn Sie sie verwenden, sollten Sie nur dann gesetzt und verlangen, daß sie auf Formen, die kritische Änderungen am System vornehmen, und erziehen Benutzer, dass sie nicht mehr als eine solche Form parallel verwenden erwarten können. Seiten, die keine nonce gesetzt sollte darauf achten, nicht alle zuvor gespeicherten nonce aus der Sitzung zu löschen, so dass die Nutzer immer noch nicht nonced Seiten parallel zu einer nonced Form verwenden können.

Answer 3

tun Einige Leute für jede Form ein Token erzeugen, und das ist ein sehr sicherer Ansatz. Allerdings kann diese App brechen und Benutzer verärgern. Um alle XSRF gegen Ihre Website zu verhindern müssen Sie nur einmalig 1 Token Variable pro Sitzung und dann wird der Angreifer nicht in der Lage sein, jede Anfrage zu schmieden, wenn er diese 1-Token finden. Das kleine Problem bei diesem Ansatz ist, dass die Angreifer dieses Token so lange rohe Gewalt könnten als das Opfer einer Website, die Angreifer Kontrollen besucht. Allerdings, wenn das Token ziemlich groß wie 32 Bytes ist oder so, dann würde es viele Jahre brutale Gewalt nehmen, und die HTTP-Sitzung sollte lange ablaufen, bevor dann.

Answer 4

Lange Zeit zurück wurde dieser Beitrag geschrieben. Ich habe einen csrf Blocker implementiert, dass ich fast sicher bin gut schützt. Es funktioniert mit mehreren geöffneten Fenstern, aber ich bin die Beurteilung noch die Art von Schutz bietet. Es verwendet einen DB-Ansatz, dh auf einen Tisch statt Sitzung zu speichern. HINWEIS: Ich benutze MD5 in diesem Fall als einfachen anti-sqli Mechanismus

Pseudo-Code:

FORM:

token = randomstring #to be used in form hidden input
db->insert into csrf (token, user_id) values (md5(token),md5(cookie(user_id))

- wird das Token dann in der DB gehalten, bis es von der Aktion Skript zugegriffen wird, unter:

ACTION SCRIPT:

if md5(post(token)) belongs to md5(cookie(user_id)) 
    #discard the token
    db -> delete from csrf where token=md5(post(token)) and user_id=md5(cookie(user_id)) 
    do the rest of the stuff