¿ASP.NET Viewstate previene implícitamente los ataques CSRF? ¿Qué significa esto para MVC?

El propósito de ASP.NET ViewState es mantener el estado de control entre post-backs (ver explicación de MDSN ), no habilita implícitamente la seguridad que impediría CSRF.

También tenga en cuenta que ViewState encriptado en versiones anteriores de ASP.NET sin parches es susceptible a una vulnerabilidad de encriptación .

Para habilitar este tipo de protección, podría:

• Use ViewStateUserKey (vea una descripción de alto nivel de la función, la docsMSDN para ViewStateUserKey y el hoja de trucos de prevención OWASP CSRF .

• Use un método personalizado para representar un campo oculto administrado personalizado (por transacción) en el formulario y verifíquelo con cada solicitud del cliente.

• Utilice una biblioteca de terceros dedicada a CSRF, como AntiCSRF .

ASP.NET MVC3 tiene un token anti-falsificación que se usa con el atributo [ValidateAntiForgeryToken] en la acción del controlador (consulte enlace ). En la etiqueta de formulario de la vista, llame al Html.AntiForgeryToken helper (consulte enlace ) con la siguiente sintaxis:

Formularios web:

<%= Html.AntiForgeryToken() %>

Razor:

@Html.AntiForgeryToken()

Es difícil ejecutar un ataque CSRF exitoso en una aplicación usando viewstate pero no imposible. Una forma de realizar un ataque CSRF exitoso en una aplicación con _viewstate es

1. Attacker puede iniciar sesión en la aplicación (usando credenciales propias o adquiridas)
2. Visite la página (con los estados de variable más comunes o más útiles) contra los que desea crear un ataque CSRF para
3. Copie el _Viewstate
4. Inserta este _viewstate en su página de ataque
5. Envía la página de ataque a la víctima
6. Con un poco de suerte y buenas adivinanzas, el ataque podría funcionar

Se ha introducido una solución a esto en 1.1. En lugar de usar solo _viewstate, puede usar ViewStateUser-Key. Esto utiliza la clave de sesión de uso para crear el token de estado que será realmente difícil de adivinar o copiar por el atacante.

Todavía sugeriría implementar un mecanismo de token CSRF independiente para la protección contra CSRF en su aplicación (sé que muchos difieren en esto)