CryptographicException: Padding non è valido e non può essere rimosso e la convalida del MAC di viewstate non è riuscita

Monitorando la mia eccezione globale registra che questo errore sembra imansible da rimuovere, non importa quello che faccio, ho pensato che alla fine mi sono liberato ma è tornato di nuovo. Qui puoi vedere una traccia dell’errore su un post simile .

Note sull’ambiente:

Applicazione ASP.NET a server singolo di IIS 6.0, .NET 3.5 SP1

Passi già presi:

  

Nella mia base di pagina per tutte le mie pagine

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

    Anche nell’origine della pagina posso vedere che tutti i campi nascosti generati da ASP.NET sono correttamente nella parte superiore della pagina.

    Innanzitutto, partiamo dal fatto che questo stato di errore di visualizzazione si verifica su PostBack .

    Devo anche dire che ho fatto tutte le cose che tutti suggeriscono di fare per evitare questo problema. E ho una macchina singola, ma 2 pool che eseguono le stesse pagine.

    Quindi qualcuno fa un’azione , etere un uomo, etere qualche altra macchina di ricerca facendo “clic” sulle tue pagine, o qualche hacker prova a controllare il tuo sistema per problemi …

    Ho problemi simili (rari ma esistenti) e alla fine ho scoperto che la gente prova a hackerare le mie pagine. (dallo stesso IP che ho e dos attacchi)

    Modifico la funzione LoadPageStateFromPersistenceMedium () che traduce il viewstate e vedo loggando esattamente l’input e da quali IP … poi ho iniziato a monitorare questi risultati e ho visto che lo stato della vista era cambiato a mano – o era completamente vuoto .

    Per errore lo ho semplicemente reindirizzato alla stessa pagina …

    Ecco cosa ho fatto …

     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; } } 

    Seconda ragione

    Ora c’è un altro motivo per cui ciò può accadere e il motivo è perché alcuni fanno clic sulla tua pagina prima che venga caricato __EVENTVALIDATION.

    Questo evento è valido nell’ultimo pulsante, anche se è stato trovato asp.net e, se ne hai alcuni in molti punti della pagina o vicino al pulsante, vai alla fine della pagina.

    Quindi, anche se vedi il viewstate in cima alla pagina, dov’è la validazione ??? forse questo non è mai stato caricato – pagina corrotta?, troppo veloce clic utente sulla pagina?

      

    Per evitare questo tipo di problema ho fatto un semplice javascript che non mi permetta di premere il pulsante a meno che questo input non sia stato caricato !!!.

    Un altro commento, la __EVENTVALIDATION non è sempre presente! quindi è forse più sicuro non cercare questo campo se si fa una soluzione generale, ma fare un trucco javascript per controllare solo se viene caricata la pagina intera o qualcos’altro che si pensa.

    Ecco la mia soluzione finale con jQuery: (nota che controllo su PageLoad se esiste la convalida dell’evento!). Ho messo questo sul mio MasterPages.

      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();"; } } 

    Puoi eseguire il test posizionando vicino al pulsante della pagina un ritardo.

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

    Aggiornare

    Oggi vedo nuovamente questo messaggio nel registro per WebResource e quello che scopro è che un bot riceve le pagine e crea tutto il carattere sui collegamenti in minuscolo , inclusi i parametri, quindi questo era un motivo in più per non ottenere la stringa corretta codificata e lancia un messaggio come Padding non valido e non può essere rimosso.

    Spero che questo ti aiuti di più.

    Un sondaggio delle pagine web trovate con molte delle parole chiave del messaggio di errore indica che questo tipo di errore è relativamente comune, di solito casuale (almeno in apparenza) e sfortunatamente raramente include un esplicito work-around o spiegazione …

    L’esistenza di molte situazioni simili eppure diverse è probabilmente legata alle molte diverse architetture e configurazioni sottostanti che possono in qualche modo portare all’incapacità del livello crittografico di affermare l’autenticità del MAC (Message Authentication Codes) nelle pagine di richiesta:

    • Configurazione della server farm
    • Cross domain / pagine sindacate
    • librerie di widget di terze parti e simili
    • Logica del programma ASP reale (ovviamente)

    Un “marker” relativamente frequente attorno a queste segnalazioni di bug è la menzione delle richieste di risorse (ad esempio WebResource.axd ).
    Si noti che tali richieste spesso non vengono registrate (per non gonfiare la dimensione dei file di registro con un evento di relativo scarso interesse). Questa assenza dal file di log e il fatto che siano spesso memorizzati nella cache (e quindi la relativa casualità e rara frequenza del bug) possono spiegare come questa ansible origine del bug vada “sotto il radar”. Ciò suggerisce anche che, nel tentativo di ricreare il bug, (durante il tracciamento dei log, in tempo reale, ecc.) Potrebbe essere utile evitare che il browser Web caching (o per lo meno di svuotare la cache inizialmente).

    In breve, ecco alcune idee e cose da cercare:

    • inizia a registrare le richieste * .axd
    • provare e correlare tali richieste axd con gli eventi di errore nel registro delle eccezioni
    • cercare pagine con riferimenti di risorse
    • se in un’impostazione di farm, assicurati che tutte le istanze utilizzino la stessa chiave (apparentemente lo snippet fornito nel suggerimento della domanda su più server IIS)
    • Siate sospettosi delle pagine con tie-in di terze parti (servizi di ricerca, programmi di affiliazione …)

    Spero che questo ti aiuti 😉

    Sei sicuro che il tuo problema sia legato alla crittografia e non causato da ViewState sovradimensionato? Se ViewState è il problema, puoi spostarlo – cambiare il valore delle pagine / MaxPageStateFieldLength in web.config