So verhindern Sie die Form von Formular Replay/Man-in-the-Middle-Angriff in PHP, CSRF, XSRF

Question

Ich habe ein Webformular und verwende PHP. Mir ist bewusst, dass Formen manipuliert werden können (ich glaube, es heißt Replay Attack oder ein Mann-in-the-Middle-Angriff). Ich möchte also ein Authentizitäts -Token als verstecktes Feld verwenden.

Die Bedrohungsmöglichkeiten, die mir bekannt sind, sind:

• Angreifer entführen die Form des legitimen Benutzers (ich glaube, der Mann-in-the-Middle-Angriff ist
• Der legitime Nutzer ist selbst der Angreifer: Er erhält das Formular, liest das Token, sendet jedoch gefährliche Daten (ich glaube, das ist der Wiederholungsangriff).

Bevor ich zu den Fragen komme, korrigieren Sie mich bitte, wenn etwas, was ich bisher gesagt habe, falsch ist, denn vielleicht ist mein Verständnis fehlerhaft.

Nun zu den Fragen:

• Was ist die beste Praxis, um dieses Token so zu erzeugen, dass die Form ohne es abgelehnt wird (zum Beispiel Salzen?).
• Was tun die Leute, um sicherzustellen, dass das Token nicht wiederholt wird?

Neue kleine Fragen basierend auf Kommentaren:

• Entführt die Sitzung genauso wie ein Mann-in-the-Middle-Angriff?

Answer 1

Sie haben CSRF im Titel erwähnt, es aber nicht wirklich in Ihrer Frage behandelt.

Sie können detailliert darüber lesen online, aber CSRF ist im Grunde ein Angriff, bei dem ein legitimer Benutzer unwissentlich einer Website unterzogen wird. Wenn dies beispielsweise vor solchen Angriffen nicht schützt würde, könnte ich ein Formular herstellen, das dazu führt, dass Ihre SO -Profilinformationen geändert werden, wenn Sie auf diese schlechte Form von mir klicken, und erwartet, dass etwas anderes passiert ("Gewinnen Sie eine Million Dollar! Klick hier!!"). Dieses Formular würde mit Ihren Browser -Cookies Sie authentieren, um Sie so zu authorieren, und es erscheint, dass Sie legitim die Updates für Ihr Profil eingereicht haben.

Um sich dagegen zu schützen, möchten Sie wirklich ein paar Dinge tun:

• Stellen Sie sicher, dass das Erhalten keine Aktualisierungen verursacht (z. B. veröffentlichen Sie beispielsweise kein neues Status -Update für das Profil eines Benutzers mit Abfrageparamien für einen GET).
• Stellen Sie sicher, dass alle Beiträge von einem versteckten Feld begleitet werden, in dem Sie bestätigen können, dass das Formular von Ihrem Service und nicht von jemand anderem generiert wurde und dass es für den beabsichtigten Benutzer war. Dieses versteckte Feld muss also jedes Mal vom Server generiert werden, wenn es das HTML für das Formular absendet, und sollte für diesen Benutzer für diese Sitzung eindeutig sein.

Eine Alternative zu diesem zweiten Element besteht darin, zu überprüfen, ob der Empfehler immer Ihre Website oder eine Website ist, von der Sie den Beitrag erwarten. Ich ermutige dies nicht für Nicht-HTTPS-Websites, da einige Browser/Networking-Hardware-Referrer streifen, und es ist nicht immer zuverlässig, dass ein Empfehler existiert.

Answer 2

Die Methode zur Erzeugung des Tokens ist nicht sehr wichtig. Das Wichtigste ist, dass das Token nur einmal verwendet wird. Halten Sie eine Liste von Token, die für den Benutzer in der Sitzung des Benutzers generiert werden. Wenn der Benutzer ein Formular einreicht und das eingereichte Token nicht in der Sitzung ist, können Sie das Formular ablehnen.

Der Schutz vor Man-in-the-Middle ist etwas schwierig. Eine gemeinsame Technik, die ich gesehen habe, ist die Aufnahme aller versteckten Formfelder in die Hash -Funktion, um das Token zu erzeugen und dann das Token zu regenerieren, basierend auf bekannten versteckten Feldern. Dies würde jedoch nur vor versteckter Feldmanipulation schützen, was möglicherweise nicht das ultimative Ziel des Mannes in der Mitte ist.

Wenn der Benutzer erfolgreich ein Formular mit dem Token einreicht, löschen Sie das Token aus der Sitzung, so dass jede Wiederholung dieser Einreichung wird versagen. Es ist jedoch lediglich, dass der Benutzer das Formular erneut anfordert, um ein weiteres Token zu generieren. Dieses neue Token kann dann bei nachfolgenden automatisierten Angriffen verwendet werden. Mit anderen Worten, Form-Token sind gegen CSRF nützlich, aber nicht sehr effektiv gegen automatisierte Wiederholungen und Man-in-the-Middle-Angriffe.

Ebenso möchten Sie Ihre Anwendung so anpassen, dass sie nicht die Nutzung des Benutzers in Formularen verwenden. Wenn ihre Einreichung ein Problem vorliegt, müssen Sie das Formular mit ausgefüllten Daten an den Benutzer zurückgeben. Wenn der Benutzer ihre Button zurückschlägt, um den Fehler zu korrigieren Zeichen.

Um ehrlich zu sein, müssen Sie sich bis zu dem Zeitpunkt, an dem Sie sich über Anforderungsreplays und Man-in-the-Middle-Angriffe sorgen müssen, die Verbindung Ihres Benutzers bereits beeinträchtigt, und es gibt wahrscheinlich nicht viel, was Sie tun können, um Schäden zu mildern. Allein SSL ist ein angemessenes Schutzniveau gegen MITM und Wiederholung, und wenn Sie sich darüber Sorgen machen, werden Sie unter SSL laufen ...

Answer 3

Um dieses Token zu generieren, hier ist eine Strategie, die ich verwende, die gut funktioniert.

• Stellen Sie einen Cookie auf einen zufälligen Wert (generiert auf dem Server mit den üblichen Tricks) und setzen Sie es so, dass sie entsprechend Ihren Anforderungen ablaufen.
• Betten Sie beim Servieren einer Seite mit einem Formular ein verstecktes Feld ein, dessen Wert dem Wert dieses Keks entspricht.
• Überprüfen Sie bei der Behandlung des Post

Answer 4

CSRF-Magic ist eine großartige Klasse für CSRF-Token. Sie steckt sie automatisch in Ihre Seite

http://csrf.htmlpurifier.org/

"CSRF-Magic verwendet PHP-Funktionen für die Ausgabepufferung, um Formulare und Skripte in Ihrem Dokument dynamisch neu zu schreiben. Es wird auch Postanforderungen abfangen und ihr Token überprüfen (verschiedene Algorithmen werden verwendet; einige generieren Nonces, einige generieren benutzerspezifische Token). Für eine herkömmliche Website mit Formularen können Sie CSRF-Magic in Ihre Anwendung fallen lassen und sie vergessen! "