Frage:
Sollte ich AntiForgeryToken in allen Formen verwenden, auch bei Anmeldung und Registrierung?
Artiom Chilaru
2011-02-12 03:08:46 UTC
view on stackexchange narkive permalink

Ich betreibe eine ziemlich große Site mit Tausenden von Besuchen pro Tag und einer ziemlich großen Nutzerbasis. Seit ich mit der Migration zu MVC 3 begonnen habe, habe ich das AntiForgeryToken in eine Reihe von Formularen gestellt, die geschützte Daten usw. ändern.

Einige andere Formulare, wie die Anmeldung und Registrierung, verwenden jetzt ebenfalls das AntiForgeryToken, aber Ich werde aus mehreren Gründen in erster Linie zweifelhaft, ob sie dort benötigt werden ...

Für das Anmeldeformular muss das Poster die richtigen Anmeldeinformationen kennen. Ich kann mir nicht wirklich vorstellen, wie ein CSRF-Angriff hier von Nutzen sein könnte, insbesondere wenn ich überprüfe, ob die Anforderung vom selben Host stammt (Überprüfung des Referer-Headers).

Das AntiForgeryToken-Token generiert jedes Mal andere Werte Die Seite wird geladen. Wenn ich zwei Registerkarten mit der Anmeldeseite geöffnet habe und dann versuche, sie zu veröffentlichen, wird die erste erfolgreich geladen. Die zweite schlägt mit einer AntiForgeryTokenException fehl (laden Sie zuerst beide Seiten und versuchen Sie dann, sie zu veröffentlichen). Bei sichereren Seiten - dies ist offensichtlich ein notwendiges Übel bei den Anmeldeseiten - scheint dies ein Overkill zu sein und nur um Ärger zu bitten.

Es gibt möglicherweise andere Gründe, warum man das Token in einem verwenden sollte oder nicht Formen. Bin ich zu Recht davon ausgegangen, dass die Verwendung des Tokens in jedem Post-Formular übertrieben ist, und wenn ja - welche Formulare würden davon profitieren und welche würden definitiv nicht davon profitieren?

PS Diese Frage wird auch bei StackOverflow gestellt, aber ich bin nicht ganz überzeugt. Ich dachte, ich würde hier nach mehr Sicherheit fragen

fragen
Wurde diese Frage aktualisiert? Bezüglich des Problems, dass mehrere Anmeldeseiten gleichzeitig gesendet werden? Meine aktuelle Lösung besteht darin, das Fälschungsschutz-Token von der Anmeldeseite zu entfernen.
Ich denke nicht, dass das mehr ein Problem sein sollte. Ich habe das Anti-Fälschungs-Token auf unserer Anmeldeseite und es ist kein Problem mehr.
Ich habe auch sichergestellt, dass in meiner web.config ein machineKey angegeben ist, wodurch einige der Probleme, die ich ursprünglich hatte, ausgeschlossen wurden
Zwei antworten:
#1
+73
D.W.
2011-02-12 08:32:14 UTC
view on stackexchange narkive permalink

Ja, es ist wichtig, fälschungssichere Token für Anmeldeseiten einzuschließen.

Warum? Wegen des Potenzials für "Login CSRF" -Angriffe. Bei einem CSRF-Anmeldeangriff meldet der Angreifer das Opfer mit dem Konto des Angreifers am Zielort an. Stellen Sie sich zum Beispiel einen Angriff einer bösen Angreiferin Evelyn auf Alice vor, die Paypal benutzt. Wenn Paypal seine Anmeldeseiten nicht vor CSRF-Angriffen geschützt hat (z. B. mit einem Anti-Fälschungs-Token), kann der Angreifer Alices Browser stillschweigend in Evelyns Konto bei Paypal anmelden. Alice wird auf die Paypal-Website weitergeleitet und Alice ist angemeldet, aber als Evelyn angemeldet. Angenommen, Alice klickt dann auf die Seite, um ihre Kreditkarte mit ihrem Paypal-Konto zu verknüpfen, und gibt ihre Kreditkartennummer ein. Alice glaubt, dass sie ihre Kreditkarte mit ihrem Paypal-Konto verknüpft, aber tatsächlich hat sie sie mit Evelyns Konto verknüpft. Jetzt kann Evelyn Sachen kaufen und sie von Alices Kreditkarte belasten lassen. Hoppla. Dies ist subtil und etwas unklar, aber so ernst, dass Sie Anti-Fälschungs-Token für das zum Anmelden verwendete Formularaktionsziel einschließen sollten. Weitere Informationen und einige Beispiele aus der Praxis finden Sie in diesem Dokument Schwachstellen.

Wann ist es in Ordnung, das Anti-Fälschungs-Token wegzulassen? Wenn das Ziel eine URL ist und der Zugriff auf diese URL keine Nebenwirkungen hat, müssen Sie im Allgemeinen kein Fälschungsschutz-Token in diese URL aufnehmen.

Die grobe Faustregel lautet: Fügen Sie allen POST-Anforderungen ein Fälschungsschutz-Token hinzu, das Sie jedoch für GET-Anforderungen nicht benötigen. Diese grobe Faustregel ist jedoch eine sehr grobe Annäherung. Es wird davon ausgegangen, dass alle GET-Anforderungen nebenwirkungsfrei sind. In einer gut gestalteten Webanwendung sollte dies hoffentlich der Fall sein, aber in der Praxis befolgen Webanwendungsdesigner manchmal diese Richtlinie nicht und implementieren GET-Handler, die Nebenwirkungen haben (dies ist eine schlechte Idee, aber nicht ungewöhnlich). . Aus diesem Grund schlage ich eine Richtlinie vor, die darauf basiert, ob die Anforderung einen Nebeneffekt auf den Status der Webanwendung hat oder nicht, anstatt auf GET vs POST.

Ich verstehe ... ich nehme an, das macht Sinn. Das einzige, was ich mir Sorgen mache, ist, die Benutzer darüber zu ärgern, dass, wenn zwei Formulare gleichzeitig geöffnet sind und dann versucht werden, sie zu veröffentlichen, eines von ihnen höchstwahrscheinlich die Validierung nicht besteht :(
+1, niice. CSRF-Twist bei der Fixierung der alten Sitzung ... Übrigens auch schönes Papier.
Gibt es keine Lösung für den Fehler, der auftritt, wenn sich der Benutzer über zwei Registerkarten anmeldet?
@AntonAnsgar, mit einem CSRF-Token bedeutet nicht, dass ein Fehler auftreten muss, wenn sich der Benutzer über zwei Registerkarten anmeldet. Wenn Sie einen solchen Fehler erhalten, verwenden Sie eine bessere CSRF-Token-Implementierung.
Vielen Dank. Der Benutzer öffnet die Anmeldeseite auf zwei Registerkarten. Meldet sich von einem an, geht zum anderen und versucht sich erneut anzumelden, die App löst eine Ausnahme aus. "System.Web.Mvc.HttpAntiForgeryException: Das bereitgestellte Anti-Fälschungs-Token war für den Benutzer bestimmt" ", aber der aktuelle Benutzer ist [email protected]" Dies ist in asp.net mvc 4. Ich verwende [ValidateAntiForgeryToken]
Habe ich Recht, wenn ich denke, dass die Einstellung - AntiForgeryConfig.SuppressIdentityHeuristicChecks = true, wie in diesem Beitrag erwähnt? Http://stackoverflow.com/questions/14970102/anti-forgery-token-is-meant-for-user-but-the-current-Benutzer ist Benutzername würden Sie effektiv wieder offen für den Angriff im Evelyn-Stil lassen?
@ChrisNevill, Ich weiß nicht - hört sich so an, als ob Sie eine separate Frage dazu stellen sollten.
Kann jemand bitte erklären, was dieser Satz bedeutet?"Wann ist es in Ordnung, das Anti-Fälschungs-Token wegzulassen? Wenn das Ziel eine URL ist und der Zugriff auf diese URL keine Nebenwirkungen hat, müssen Sie im Allgemeinen kein Anti-Fälschungs-Token in diese URL aufnehmen."
@Ned, Vielleicht könnten Sie eine neue Frage über die Schaltfläche "Frage stellen" oben rechts stellen?Sie können für den Kontext auf diesen Beitrag verlinken.Ich schlage vor, dass Sie in Ihrer Frage beschreiben, welche Teile Sie verstehen und worüber Sie konkret verwirrt sind, und uns helfen, Ihr derzeitiges Verständnisniveau zu verstehen und warum dies Ihnen unklar erscheint.
Vielen Dank für die Erklärung der richtigen Richtung, @D.W.Ich habe einen neuen Beitrag erstellt: https://security.stackexchange.com/questions/204041/when-is-it-okay-not-to-use-anti-forgery-token-in-login-page
#2
+2
Steve
2011-02-12 07:59:25 UTC
view on stackexchange narkive permalink

Möglicherweise muss das Token auf einer Anmeldeseite vorhanden sein, wenn Sie verhindern müssen, dass sich jemand mit bestimmten Anmeldeinformationen böswillig bei der Site anmeldet. Ich kann sehen, dass dies der Fall ist, wenn jemand für etwas gerahmt wird, für das eine Anmeldung bei einem bestimmten Benutzer erforderlich ist. Wenn das gesagt ist, ist es ein erfundenes Beispiel.

Nicht so erfunden ... Siehe die Antwort von @D.W.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 2.0-Lizenz, unter der er vertrieben wird.
Loading...