ViewState ASP.NET impedisce implicitamente gli attacchi CSRF? Cosa significa questo per MVC?

Lo scopo di ASP.NET ViewState è di mantenere lo stato di controllo tra postback (vedere spiegazione MDSN ), non abilita implicitamente la sicurezza che impedirebbe CSRF.

Si noti inoltre che ViewState crittografato in versioni precedenti di ASP.NET prive di patch è suscettibile a una vulnerabilità di crittografia .

Per abilitare questo tipo di protezione puoi:

• Usa ViewStateUserKey (Vedi una descrizione di alto livello della funzione, la Documenti MSDN per ViewStateUserKey e Scheda cheat di prevenzione OWASP CSRF .

• Utilizza un metodo personalizzato per eseguire il rendering di un campo nascosto gestito personalizzato (per transazione) nel modulo e controllalo per ogni richiesta del client.

• Utilizza una libreria di terze parti dedicata a CSRF come AntiCSRF .

ASP.NET MVC3 ha un token anti-contraffazione che viene utilizzato con l'attributo [ValidateAntiForgeryToken] sull'azione del controller (vedere link ). Nel tag modulo della vista chiama l'helper Html.AntiForgeryToken (vedi link ) con la seguente sintassi:

Web Form:

<%= Html.AntiForgeryToken() %>

Razor:

@Html.AntiForgeryToken()

È difficile eseguire un attacco CSRF di successo su un'applicazione utilizzando viewstate ma non impossibile. Un modo per eseguire un attacco CSRF succcessivo su un'applicazione con _viewstate è

1. L'attaccante è in grado di accedere all'applicazione (utilizzando credenziali proprie o acquisite)
2. Visita la pagina (con gli stati delle variabili più comuni o più utili) rispetto ai quali desidera creare un attacco CSRF per
3. Copia il _Viewstate
4. Inserisci questo _viewstate nella sua pagina di attacco
5. Invia la pagina di attacco alla vittima
6. Con un po 'di fortuna e indovinando l'attacco potrebbe funzionare

Una soluzione a questo è stata introdotta in 1.1. Invece di usare solo _viewstate puoi usare ViewStateUser-Key. Questo utilizza la chiave di sessione use per creare il token di stato che sarà davvero difficile da indovinare o copiare dall'attaccante.

Suggerirei comunque di implementare un meccanismo di token Indipendent CSRF per la protezione contro CSRF nella tua applicazione (so che molti saranno diversi su questo)