Cryptographic: Padding ist ungültig und kann nicht entfernt werden und Validierung von Viewstate-MAC

StackOverflow https://stackoverflow.com/questions/1821243

Frage

Die Überwachung meiner globalen Ausnahmeprotokolle dieser Fehler unmöglich zu sein scheint egal zu entfernen, was ich tue, ich dachte, ich habe endlich wieder los, aber es ist wieder zurück. Sie können auf einem ähnliche Post hier .

Notizen über die Umwelt:

IIS 6.0, .NET 3.5 SP1 einzelne Server ASP.NET-Anwendung

Schritte bereits gemacht: 

  <system.web>
    <machineKey validationKey="big encryption key"
      decryptionKey="big decryption key"
      validation="SHA1" decryption="AES" />

In meiner Seite Basis für alle meine Seiten 

  protected override void OnInit(EventArgs e)
  {
    const string viewStateKey = "big key value";

    Page.ViewStateUserKey = viewStateKey;
  }

Auch in der Quelle der Seite kann ich sehen, dass alle von der ASP.NET erzeugt versteckte Felder korrekt am oberen Rand der Seite sind.

War es hilfreich?

Lösung

Zunächst einmal lässt sich aus der Tatsache beginnen, dass Dieser Fehlerzustand Blick geschieht auf Postback .

Auch muss ich sagen, , dass ich all die Dinge getan haben, dass jeder vorschlagen zu tun, um dieses Problem zu vermeiden. Und ich habe einzelne Maschine, sondern 2 Pools, die die gleichen Seiten führen.

So jemand tun, um eine Aktion , Ether ein Mann, Äther eine andere Suchmaschine durch ‚klicken‘ auf Ihren Seiten, oder ein Hacker versuchen Sie das System auf Fehler zu überprüfen ...

Ich habe ähnliche Probleme (seltene, aber bestehende), und schließlich fand ich, dass die Leute versuchen, meine Seiten zu hacken-testen. (Von der gleichen IP Ich habe und DoS-Attacken)

I die Funktion LoadPageStateFromPersistenceMedium () ändern, dass der Ansichtszustand übersetzen, und sehen Sie, indem Sie sich, was genau der Eingang war, und von dem, was IPs ... dann begann ich Monitor sehen diese Ergebnisse und dass die Ansicht Zustand wurde von Hand geändert -. oder war total leer

Ein Fehler, den ich umleiten ihm nur auf die gleiche Seite ...

Hier ist, was ich getan habe ... 

public abstract class BasePage : System.Web.UI.Page
{
    protected override object LoadPageStateFromPersistenceMedium()
    {
        try
        {
            .. return the base, or make here your decompress, or what ever...
            return base.LoadPageStateFromPersistenceMedium();            
        }
        catch (Exception x)
        {
            string vsString = Request.Form[__VIEWSTATE];
            string cThePage = Request.RawUrl;

            ...log the x.ToString() error...
            ...log the vsString...
            ...log the ip coming from...
            ...log the cThePage...

        // check by your self for local errors
            Debug.Fail("Fail to load view state ! Reason:" + x.ToString());
        }

        // if reach here, then have fail, so I reload the page - maybe here you
        // can place somthing like ?rnd=RandomNumber&ErrorId=1 and show a message
        Responce.Redirect(Request.RawUrl, true);        

        // the return is not used after the redirect
        return string.Empty;
    }    
}

Zweiter Grund

Jetzt gibt es einen weiteren Grund, warum dies geschehen kann, und der Grund ist, weil einige, klicken Sie einfach auf Ihrer Seite vor dem __EVENTVALIDATION geladen wird.

Dieses Eventvalidation auf den letzten Knopf-even platziert, dass asp.net gefunden, und wenn man einige von ihnen auf vielen Platz auf der Seite haben, oder in der Nähe der Taste, das dann bis zum Ende der Seite.

So, selbst wenn Sie den Ansichtszustand auf der oben auf der Seite zu sehen, wo die Validierung ??? vielleicht ist dies nie geladen? - Seite korrumpieren, zu schnell Benutzer klicken Sie auf Seite 

<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" ... >

Um diese Art von Problem zu vermeiden ich ein einfaches Javascript gemacht, dass ich es nicht die Taste drücken lassen, es sei denn dieser Eingang geladen wurde !!!.

Ein weiterer Kommentar ist die __EVENTVALIDATION nicht immer präsentiert! so ist vielleicht sicherer nicht für dieses Feld zu suchen, wenn Sie eine allgemeine Lösung, aber ein Javascript Trick zu machen, um nur zu prüfen, ob die ganze Seite geladen wird, oder etwas anderes, das Sie denken.

Hier ist meine endgültige Lösung mit jQuery (! Bitte beachte, dass ich auf Pageload überprüfen, ob Eventvalidation vorhanden ist). Ich habe dies platziert auf meiner Masterpages. 

<script language="javascript" type="text/javascript">
    function AllowFormToRun()
    {
        var MyEventValidation = $("#__EVENTVALIDATION");

        if(MyEventValidation.length == 0 || MyEventValidation.val() == ""){
            alert("Please wait for the page to fully loaded.");
            return false;
        }

        return true; 
    }       
</script>

protected void Page_Load(object sender, EventArgs e)
{
    // I do not know if Page can be null - just in case I place it.
    if (Page != null && Page.EnableEventValidation)
    {
        Form.Attributes["onsubmit"] = "return AllowFormToRun();";
    }
}

Sie können testen, indem Sie in der Nähe der Taste Ihrer Seite eine Verzögerung setzt. 

<% System.Threading.Thread.Sleep(5000); %>

Update

Heute habe ich in log wieder sehen diese Nachricht für WebResource und was ich entdecken, dass ein Bot die Seiten bekommen und machen den Charakter auf die Links in Kleinbuchstaben , einschließlich der Parameter, so war dies ein Grund mehr, immer die richtige codierte Zeichenfolge nicht, und eine Meldung wie wirft Padding ungültig ist und nicht entfernt werden kann.

Hope diese Hilfe Sie mehr.

Andere Tipps

Eine Übersicht über die Web-Seiten mit mehreren der Schlüsselwörter aus der Fehlermeldung gefunden zeigen, dass diese type Fehler relativ häufig ist, in der Regel zufällig (zumindest in Erscheinung) und leider selten inklusive ein explizite Behelfslösung oder Erklärung ...

Die Existenz von vielen ähnlichen-nicht-unterschiedlichen Situationen ist wahrscheinlich auf die sehr viele verschiedenen Architekturen gebunden und die zugrunde liegende Konfigurationen, die irgendwie auf die Unfähigkeit der Krypto-Schicht führen können die Echtheit der MAC (Message Authentication Codes) in der behaupten Anfrage Seiten:

  • Server-Farm-Setup
  • Cross-Domain / syndizierte Seiten
  • Dritte-Widget-Bibliotheken und so
  • Ist-ASP Programmlogik (natürlich)

Ein relativ häufiger "Marker", um diese Fehlerberichte ist die Erwähnung von Ressourcenanforderungen (z. B. WebResource.axd ).
Beachten Sie, dass solche Anfragen sind oft nicht angemeldet (damit sie die Log-Dateien Größe mit Fall relativ wenig Interesse aufblasen). Diese Abwesenheit aus der Protokolldatei und die Tatsache, dass sie oft zwischengespeichert werden (und damit das relative zufällig und selten Auftreten des Fehlers) kann erklären, wie dieser mögliche Ursprung des Fehlers gehen „unter dem Radar“. Dies deutet darauf hin, dass bei dem Versuch, den Fehler zu erstellen, (während in den Protokollen in Echtzeit usw. Tracking) kann es sinnvoll sein, den Web-Browser-Caching zu verhindern (oder für die es am wenigsten zu löschen Cache zunächst).

Kurz gesagt, hier sind ein paar Ideen und Dinge zu suchen:

  • Starten Sie die * .axd Anfragen Anmeldung
  • versuchen und Co-beziehen sich solche axd Anfragen mit den Fehlerereignisse im Ausnahmeprotokoll
  • Suchen Sie nach Seiten mit Ressourcenreferenzen
  • wenn in einem landwirtschaftlichen Betrieb, sicherzustellen, dass alle Instanzen die gleichen Schlüssel (offenbar die Schnipsel, die in der Frage Hinweis auf mehr IIS-Server)
    • verwenden
  • Seien Sie misstrauisch von Seiten mit 3rd-Party-Tie-In (Suchdienst, Affiliate-Programme, ...)

Hope, das hilft; -)

Sind Sie sicher, dass Ihr Problem ist Kryptographie verwandt und nicht durch übergroße Viewstate verursacht? Wenn Viewstate das Problem ist, können Sie chunk es - den Wert der Seiten / MaxPageStateFieldLength in web.config ändern

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top