Ideas para la implementación de seguridad XSRF en ASP.NET MVC utilizando cookies de doble envío

Question

Decidí intentar usar las cookies dobles enviadas técnica para intentar prevenir ataques XSRF en el sitio en el que estoy trabajando. Entonces, la forma en que lo escribo aquí es que todas las acciones que realmente HAGAN algo más que OBTENER información, serán publicaciones. Gets será ... uh ... GETs. En segundo lugar, cada formulario que publique tendrá el combo de clave / cookie.

Mi pregunta es, ¿cuál sería la forma más fácil de implementar esto en una aplicación web ASP.NET MVC?

No para responder mi propia pregunta, pero aquí están mis pensamientos iniciales:

En este momento, todos mis controladores heredan de un controlador base, así que mi primer pensamiento fue anular el método OnActionExecuted para verificar la existencia del campo de formulario requerido, y desde allí si lo encuentra, verificarlo contra la cookie y permitir que la publicación continúe o enviarla a alguna página de error.

Para la parte del formulario, estaba pensando en generar mis propios métodos de extensión html como ... Html.BeginSecureForm () que sobrecarga todos los mismos métodos que BeginForm (en caso de que los necesite) pero genera automáticamente la clave pseudoaleatoria y la cookie y coloca la cookie y el campo del formulario dentro del formulario (¡SI ES UNA POST!) de forma automática.

Lo siento, si esto está un poco confuso, tengo notas dispersas por estas páginas y estoy tratando de organizarlas. Parte de eso es descubrir mi diseño para esta cosa de seguridad XSRF.

Answer 1

Utilice el soporte integrado para esto en ASP.NET MVC .

Answer 2

La protección incorporada ASP.NET MVC XSRF tiene una desventaja: envía otra cookie al cliente.

  

Al mismo tiempo, Html.AntiForgeryToken () le dará al visitante una cookie llamada __RequestVerificationToken , con el mismo valor que el valor oculto aleatorio que se muestra arriba.

Prefiero no enviar una tonelada de cookies al cliente, por lo que cuando tenga un rastreador único del lado del servidor para cada usuario (como, por ejemplo, una tabla de sesión en la base de datos ...) puede usar eso, en lugar. Una cookie menos: simplemente envíe un hash único de algo en la tabla de usuarios.

Pero luego hay usuarios anónimos que no tienen una cuenta de usuario y, por lo tanto, no tienen seguimiento del lado del servidor. En ese caso, me pregunto si de alguna manera podría obtener la cookie ASP.NET_SessionId existente (cuando las sesiones están habilitadas) que ya se está enviando a cada usuario ... en lugar de creando Yet Another Cookie.

¿Posible? ¿O no estoy pensando en esto ...?

Answer 3

Un método que gana tracción es el Patrón de Token Cifrado, implementado por un Framework llamado ARMOR. La premisa aquí es que no necesita sesión ni cookies para mantener la protección CSRF. El Patrón de token encriptado aprovecha un token encriptado Rijndael cuya integridad se mantiene mediante un algoritmo de hash SHA256.

ARMOR Framework es fácil de implementar en aplicaciones MVC y API web. Tutorial completo aquí .