ASP.MVC-Antiforgery-Token und kryptografische Fehler

Question

Ich verwende ELMAH, um Fehler in meinen MVC-Sites zu behandeln, und habe in den letzten Wochen festgestellt, dass einige CryptographicExceptions ausgelöst werden.Die Nachricht lautet:

System.Security.Cryptography.CryptographicException:Die Polsterung ist ungültig und kann nicht entfernt werden.

System.Web.Mvc.HttpAntiForgeryException:Ein erforderliches Anti-Empan-Token wurde nicht geliefert oder war ungültig.---> System.Web.httpexception:Die Validierung von ViewState MAC ist fehlgeschlagen.Wenn diese Anwendung von einer Webfarm oder einem Cluster gehostet wird, stellen Sie sicher, dass die Konfiguration denselben ValidationKey- und Validierungsalgorithmus angibt.Autogenerate kann nicht in einem Cluster verwendet werden.--->

Die Anwendung wird nicht in einem Cluster ausgeführt und ich kann diese Fehler scheinbar nicht reproduzieren.Sie sehen aus wie gültige Anfragen – kein handgefertigter Beitrag – und enthalten das __RequestVerificationToken-Cookie.Ich habe den erforderlichen HTML-Helfer auf der Seite im Formular (meinem Anmeldeformular).

Ich habe noch keine Benutzerbeschwerden erhalten und gehe daher davon aus, dass es letztendlich für jeden funktioniert, der sich anmelden möchte. Ich frage mich aber, warum das passieren könnte.

Beobachtet noch jemand dieses Verhalten oder hat jemand eine Idee, wie man die Ausnahme diagnostizieren kann – wie gesagt, ich kann es nicht zum Scheitern bringen.Das Löschen des Cookies in FF führt zu einem anderen Fehler.Das Ändern des Cookies (Ändern oder Entfernen des Inhalts) führt ebenfalls zu einem anderen Fehler, ebenso wie das Ändern des Inhalts der versteckten Token-Eingabe auf der Seite.

Answer 1

Ich bin mir nicht sicher, ob es einen Zusammenhang gibt, aber nachdem ich eine robots.txt-Datei hinzugefügt habe, die meine Anmeldeaktionen ausschließt, werden mir diese Fehler nicht mehr angezeigt.Ich vermute, dass es damit zu tun hat, dass ein Crawler auf die Seite gelangt und versucht, die Anmeldeaktion aufzurufen.

BEARBEITEN:Dieses Problem ist mir auch beim Empfang alter Cookies aufgefallen, nachdem der Anwendungspool recycelt wurde.Ich habe darauf zurückgegriffen, den machineKey explizit festzulegen, damit Änderungen an den Validierungs-/Entschlüsselungsschlüsseln bei Anwendungsneustarts keine Auswirkungen auf alte Cookies haben, die möglicherweise erneut gesendet werden.

Nachdem ich die Website aktualisiert und zu einem festen machineKey gewechselt hatte, stellte ich fest, dass ich diese Fehlermeldungen immer noch von Leuten bekam, die Cookies aus der vorherigen Version hatten.Als vorübergehende Lösung habe ich den folgenden Application_Error-Handler hinzugefügt:

    public void Application_Error()
    {
        var exception = Server.GetLastError().GetBaseException();
        if (exception is System.Security.Cryptography.CryptographicException)
        {
            Server.ClearError();
            if (Request.IsAuthenticated)
            {
                var form = new FormsAuthenticationWrapper();
                form.SignOut();
                Session.Clear();
            }
            Response.Cookies.Clear();
            Response.Redirect( "~" );
        }
    }

Answer 2

Ich bin mir nicht so sicher, dies hat nichts speziell mit dem Fälschungssystem, die inneren Ausnahmezustände ‚Validierung von Viewstate-MAC.‘ Zu tun, von dem, was ich sagen kann, hat die Standard-Infrastruktur für das Fälschungssystem eine Abhängigkeit von der Ansichtszustand (eigentlich, wenn Sie mal hier vorbeischauen Sie werden sehen, die Abhängigkeit und Schrecken (die CreateFormatterGenerator Methode an der Unterseite)) sehen.

Was, warum der Ansichtszustand mac auf der gefälschten Anfrage fehlschlägt, kann ich nicht Sure-bin aber der Schrecken gegeben, die in Deserialisieren die Fälschungs Token vorhanden ist (Verarbeitung eine gesamte gefälschte Anfrage), es überrascht mich nicht. .