Wir haben kürzlich unsere Lösung auf MVC 2 aktualisiert, und dies hat die Art und Weise, wie dieAntiForgeryToken funktioniert. Leider passt dies 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 des @ des BenutzerName Eigenschaft (vonIPrincipal). Wir sind in der Lage, einen neuen Benutzer mit AJAX sicher zu registrieren. Danach sind nachfolgende AJAX-Aufrufe ungültig, da sich das Anti-Fälschungs-Token ändert, wenn dem Benutzer ein neuer Principal gewährt wurde. Es gibt auch andere Fälle, in denen dies vorkommen kann, z. B. ein Benutzer, der seinen Namen aktualisiert usw.

Meine Hauptfrage ist, warum MVC 2 überhaupt symmetrische Verschlüsselung verwendet. Und warum kümmert es sich dann um die Benutzername-Eigenschaft des Principals?

Wenn ich das richtig verstehe, genügt ein zufälliges gemeinsames Geheimnis. Das Grundprinzip ist, dass dem Benutzer ein Cookie mit bestimmten Daten (HttpOnly!) Gesendet wird. Dieses Cookie muss dann mit einer Formularvariablen übereinstimmen, die bei jeder Anforderung zurückgesendet wird, die Nebenwirkungen haben kann (in der Regel POSTs). Da dies nur zum Schutz vor Cross-Site-Angriffen gedacht ist, ist es einfach, eine Antwort zu erstellen, die den Test problemlos besteht, aber nur, wenn Sie vollen Zugriff auf das Cookie haben. Da ein Cross-Site-Angreifer keinen Zugriff auf Ihre Benutzer-Cookies hat, sind Sie geschützt.

Was ist der Vorteil einer symmetrischen Verschlüsselung bei der Überprüfung des Cookie-Inhalts? Wenn ich bereits ein HttpOnly-Cookie gesendet habe, kann der Angreifer es nicht überschreiben (es sei denn, ein Browser hat ein schwerwiegendes Sicherheitsproblem). Warum muss ich es dann erneut überprüfen?

Nachdem Sie darüber nachgedacht haben, scheint es sich um einen dieser Fälle mit zusätzlicher Sicherheit zu handeln - aber wenn Ihre erste Verteidigungslinie gefallen ist (HttpOnly), wird der Angreifer die zweite Ebene sowieso überwinden, da sie voll ist Zugriff auf die Cookie-Sammlung der Benutzer, und sie könnten sich nur direkt als solche ausgeben, anstatt einen indirekten XSS / CSRF-Angriff durchzuführen.

Natürlich könnte mir ein großes Problem fehlen, aber ich habe es noch nicht gefunden. Wenn es hier offensichtliche oder subtile Probleme gibt, würde ich gerne darauf aufmerksam werden.