Wir haben vor kurzem unsere Lösung für MVC 2 aktualisiert, und dies hat die Funktionsweise von AntiForgeryToken aktualisiert. Leider passt das nicht mehr zu unserem AJAX-Framework.
Das Problem ist, dass MVC 2 jetzt symmetrische Verschlüsselung verwendet, um einige Eigenschaften des Benutzers zu verschlüsseln, einschließlich der Name -Eigenschaft des Benutzers (aus IPrincipal ). Wir können einen neuen Benutzer sicher mit AJAX registrieren, woraufhin nachfolgende AJAX-Aufrufe ungültig werden, da sich das Anti-Fälschungstoken ändert, wenn dem Benutzer ein neuer Prinzipal zugewiesen wurde. Es gibt auch andere Fälle, in denen dies passieren kann, beispielsweise wenn ein Benutzer seinen Namen aktualisiert usw.
Meine Hauptfrage ist, warum MVC 2 überhaupt die symmetrische Verschlüsselung verwendet? Und warum interessiert es dann die Eigenschaft user name auf dem Principal?
Wenn mein Verständnis stimmt, dann wird jedes zufällige gemeinsame Geheimnis ausreichen. Das Grundprinzip ist, dass dem Benutzer ein Cookie mit bestimmten Daten gesendet wird (HttpOnly!). Dieser Cookie muss dann eine Formularvariable abgleichen, die mit jeder Anfrage zurückgeschickt wird, die Nebenwirkungen haben kann (POST ist normalerweise). Da dies nur zum Schutz vor Cross-Site-Angriffen gedacht ist, ist es leicht, eine Antwort zu erstellen, die den Test problemlos bestehen würde, aber nur, wenn Sie vollen Zugriff auf den Cookie hatten. Da ein Cross-Site-Angreifer keinen Zugriff auf Ihre Benutzer-Cookies hat, sind Sie geschützt.
Was ist bei der Verwendung der symmetrischen Verschlüsselung der Vorteil, wenn Sie den Inhalt des Cookies überprüfen? Das heißt, wenn ich bereits einen HttpOnly-Cookie gesendet habe, kann der Angreifer ihn nicht überschreiben (es sei denn, ein Browser hat ein größeres Sicherheitsproblem). Warum muss ich ihn dann erneut überprüfen?
Nachdem Sie darüber nachgedacht haben, scheint es einer dieser "zusätzlichen Sicherheitsschichten" zu sein - aber wenn Ihre erste Verteidigungslinie gefallen ist (HttpOnly), dann wird der Angreifer sowieso die zweite Ebene hinter sich lassen Sie haben vollen Zugriff auf die Cookie-Sammlung des Benutzers und können sie nur direkt als direkte Repräsentation verwenden, anstatt einen indirekten XSS / CSRF-Angriff zu verwenden.
Natürlich könnte mir ein großes Problem fehlen, aber ich habe es noch nicht gefunden. Wenn hier einige offensichtliche oder subtile Probleme im Spiel sind, würde ich gerne auf sie achten.
Es wurde hinzugefügt, um einen besseren Schutz für den Fall zu bieten, dass eine Subdomain versucht, eine andere Subdomain anzugreifen - bad.example.com versucht, good.example.com anzugreifen. Durch das Hinzufügen des Benutzernamens wird es für bad.example.com schwieriger, good.example.com hinter den Kulissen zu kontaktieren und zu versuchen, es dazu zu bringen, in Ihrem Namen ein Token zu generieren.
In Zukunft ist es möglich, dass der Cookie entfernt wird, da dies für das ordnungsgemäße Funktionieren des Systems nicht unbedingt notwendig ist. (Wenn Sie beispielsweise die Formularauthentifizierung verwenden, könnte das -Cookie als Anti-XSRF-Cookie dienen, anstatt dass das System einen zweiten Cookie generiert.) Der Cookie wird möglicherweise nur in diesem Fall ausgegeben von anonymen Benutzern zum Beispiel.
Betrachte neben dem von Levi umrissenen "bösen Subdomain" -Szenario einen Angreifer mit einem Account auf der Zielseite. Wenn das CSRF-Token keine benutzerspezifischen Informationen codiert, kann der Server nicht überprüfen, dass das Token exklusiv für den angemeldeten Benutzer generiert wurde. Der Angreifer könnte dann einen seiner legitim erworbenen CSRF-Token verwenden, wenn er eine gefälschte Anfrage erstellt.
Das heißt, anonyme Tokens werden unter bestimmten Umständen von ASP.NET MVC akzeptiert. Siehe Warum erlaubt ValidateAntiForgeryTokenAttribute anonyme Token?
Tags und Links asp.net-mvc asp.net asp.net-mvc-2 antiforgerytoken csrf