2014-07-23 10 views
8

Ho implementato la protezione anti-contraffazione utilizzando ValidateAntiForgeryTokenAttribute in MVC 5. Funziona bene, ma in futuro potremmo passare a un approccio più "web farm" all'hosting. Se eseguo la mia applicazione in fase di sviluppo e apro un modulo, riavvia il server Web (riavviando l'app in Visual Studio) e quindi invio un modulo, non lancia System.Web.Mvc.HttpAntiForgeryException.Come sopravvive il token anti-contraffazione MVC tra i riavvii del server Web?

La nostra applicazione non utilizza altri stati di sessione. Qualcuno può aiutarmi a capire come il mio server riprende da dove era stato interrotto? Non sto definendo un machineKey nel mio web.config o in qualsiasi altro posto che posso trovare. Ha qualcosa a che fare con l'esecuzione in un ambiente di sviluppo?

Gli unici riferimenti che posso trovare a questo sono per le versioni precedenti di MVC, quindi mi chiedo se questo è risolto in un modo diverso ora.

Sono contento che questa funzionalità funzioni, ma ho bisogno di capire perché.

risposta

2

Il server non sta ricordando nulla; non deve.

Le due cose al lavoro qui sono:

  • L'ingresso modulo nascosto
  • Un cookie

Ciò significa che se l'utente visita una pagina con un AntiForgeryToken su di esso, poi la il riavvio del server, non è un problema perché l'utente e il modulo __RequestVerificationToken sono ancora gli stessi che erano.

Il token di sicurezza effettivo è una chiave con hash memorizzata all'interno dell'oggetto AntiForgeryToken. Questo oggetto è serializzato su Base 64 e questo è ciò che si vede quando si guardano i valori dello __RequestVerificationToken. Poiché le chiavi di sicurezza vengono memorizzate ogni volta, anche se il server reimposta i valori sono ancora all'interno di tali oggetti. Le chiavi vengono quindi recuperate e confrontate per convalidare i token.

Non c'è alcuna decrittografia durante questo processo. I token vengono deserializzati, le chiavi di sicurezza vengono lette e quindi confrontate. Poiché le chiavi di sicurezza sono non crittografate, ma sono piuttosto hash, non possono essere decifrate; solo rispetto.

+0

Grazie per quello. Sono consapevole che i due valori vengono confrontati, ma penso che la chiave di crittografia utilizzata per decrittografare i valori debba essere rigenerata quando IIS viene riavviato. Non dovrebbe essere in grado di decifrare i valori dopo che ciò accade perché la chiave è nuova. – DustinA

+0

Ah, vedo cosa stai chiedendo. Grande domanda. Aggiornerò la mia risposta –

+0

Apprezzo il tempo che hai impiegato per scrivere quella risposta, ma non sono sicuro che sia corretto. Questo sito Web di Microsoft afferma che "i payload dei token anti-XSRF sono crittografati e firmati". Ecco l'URL della pagina: http://www.asp.net/mvc/overview/security/xsrfcsrf-prevention-in-aspnet-mvc-and-web-pages. Credo che quello che sta accadendo nel mio caso è che il MachineKey usato per cifrare e decifrare in realtà non cambia tra il riavvio del sito web o del pool di app come in passato. Non riesco a trovare la documentazione per supportarlo, ma è quello che penso stia accadendo. – DustinA

Problemi correlati