it-swarm-eu.dev

Sollte ich AntiForgeryToken in allen Formen verwenden, auch bei Anmeldung und Registrierung?

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 das Anmelden und die Registrierung, verwenden jetzt auch das AntiForgeryToken, aber ich werde aus mehreren Gründen zunächst 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 bei jedem Laden der Seite unterschiedliche Werte. 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 seinen Formularen verwenden sollte oder nicht. Habe ich Recht, wenn ich davon ausgehe, dass die Verwendung des Tokens in jedem Post-Formular übertrieben ist, und wenn ja - welche Art von Formularen würde davon profitieren und welche würden definitiv nicht profitieren?

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

82
Artiom Chilaru

Ja, es ist wichtig, Anti-Fälschungs-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 unter dieses 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 ein Anti-Fälschungs-Token in alle POST -Anfragen ein, aber Sie benötigen es nicht für GET-Anfragen. 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 das hat einen Nebeneffekt (dies ist eine schlechte Idee, aber es ist nicht ungewöhnlich). Deshalb 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.

72
D.W.

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 bisschen ein erfundenes Beispiel.

2
Steve