2014-07-23 7 views
8

Ich habe einen Anti-Fälschungs-Schutz unter Verwendung des ValidateAntiForgeryTokenAttribute in MVC 5 implementiert. Es funktioniert gut, aber in Zukunft werden wir vielleicht eher zu einem "Webfarm" -Ansatz für das Hosting übergehen. Wenn ich meine Anwendung in Entwicklung ausführe und zu einem Formular gehe, den Webserver neu starte (indem ich die App in Visual Studio neu starte) und dann ein Formular abschicke, wird die System.Web.Mvc.HttpAntiForgeryException nicht ausgelöst.Wie funktioniert das MVC-Anti-Fälschungs-Token zwischen Neustarts von Webservern?

Unsere Anwendung verwendet keinen anderen Sitzungsstatus. Kann mir jemand helfen zu verstehen, wie mein Server dort weitermacht, wo er aufgehört hat? Ich definiere keinen ComputerKey in meiner web.config oder irgendwo anders, das ich finden kann. Hat es etwas damit zu tun, in einer Entwicklungsumgebung zu laufen?

Die einzigen Referenzen, die ich finden kann, sind für frühere Versionen von MVC, also frage ich mich, ob dies jetzt auf eine andere Weise gelöst wird.

Ich bin froh, dass diese Funktionalität funktioniert, aber ich muss verstehen, warum.

Antwort

2

Der Server selbst erinnert sich an nichts; es muss nicht.

Die beiden Dinge bei der Arbeit sind hier:

  • Die Form versteckte Eingang
  • Ein Cookie

Dies bedeutet, dass, wenn der Benutzer besucht eine Seite mit einem AntiForgeryToken drauf, dann ist die Server startet neu, es ist kein Problem, denn die __RequestVerificationToken des Benutzers und des Formulars sind immer noch die gleichen wie sie waren.

Das tatsächliche Sicherheitstoken ist ein Hash-Schlüssel, der innerhalb des Objekts AntiForgeryToken gespeichert wird. Dieses Objekt ist auf Base 64 serialisiert und das sehen Sie, wenn Sie die Werte von __RequestVerificationToken betrachten. Da die Sicherheitsschlüssel jedes Mal gespeichert werden, befinden sich die Werte selbst dann, wenn der Server zurückgesetzt wird, immer noch in diesen Objekten. Die Schlüssel werden dann abgerufen und verglichen, um die Token zu validieren.

Während dieses Vorgangs erfolgt keine Entschlüsselung. Die Token werden deserialisiert, die Sicherheitsschlüssel gelesen und verglichen. Da die Sicherheitsschlüssel nicht verschlüsselt sind, aber eher Hash sind, dann können sie nicht entschlüsselt werden; nur verglichen.

+0

Danke dafür. Ich bin mir bewusst, dass die beiden Werte verglichen werden, aber ich denke, dass der Verschlüsselungsschlüssel, der zum Entschlüsseln der Werte verwendet wird, neu generiert werden soll, wenn IIS neu gestartet wird. Es sollte nicht in der Lage sein, die Werte danach zu entschlüsseln, da der Schlüssel neu ist. – DustinA

+0

Ah, ich verstehe was du fragst. Große Frage. Ich werde meine Antwort aktualisieren. –

+0

Ich schätze die Zeit, die Sie gebraucht haben, um diese Antwort zu schreiben, aber ich bin mir nicht sicher, ob es richtig ist. Diese Microsoft-Website besagt, dass "die Payloads der Anti-XSRF-Tokens verschlüsselt und signiert sind". Hier ist die URL zur Seite: http://www.asp.net/mvc/overview/security/xsrfcsrf-prevention-in-aspnet-mvc-and-web-pages. Ich glaube, was in meinem Fall passiert, ist, dass der MachineKey, der zum Verschlüsseln und Entschlüsseln verwendet wird, sich nicht zwischen dem Neustart der Website oder des App-Pools wie früher ändert. Ich kann keine Dokumentation finden, die das unterstützt, aber das ist es, was ich denke. – DustinA

Verwandte Themen