¿Cuáles son los detalles de implementación y el fundamento de AntiForgeryToken de ASP.NET MVC3?

Question

AntiForgeryToken se usa para prevenir ataques CSRF, sin embargo, los enlaces en MSDN no me dan mucha información sobre qué hace exactamente AntiForgeryToken, o cómo funciona, o por qué las cosas se hacen como están.

Por lo que deduzco, crea un hash dentro de una página web y una cookie. Uno o ambos usan el código hash IPrincipal.Name y usan encriptación simétrica.

¿Alguien puede arrojar luz en cuanto a:

1. Cómo la AntiForgeryToken funciona internamente
2. Lo que se debe utilizar para proteger
3. Lo que no debería ser usado para proteger
4. ¿Cuál es el razonamiento detrás de las opciones de implementación para el n. ° 1 anterior?
   • Ejemplo:
     • es la implementación salvo de "DoubleSubmit" cookies y otra vulnerabilidad común
     • ¿Existen cuestiones de aplicación si el usuario abre varias pestañas
     • Lo que hace que la implementación de MSFT diferente de la que está disponible en SANS

Answer 1

bien, aquí es mi mejor oportunidad.

1) Internamente, mvc usa métodos de cifrado RNG para crear una cadena de 128 bits para actuar como el token XSRF. Esta cadena se almacena en una cookie, así como en un campo oculto en algún lugar de la forma. El nombre de la cookie parece estar en la forma de __RequestVerificationToken + una versión codificada en base 64 de la ruta de la aplicación (lado del servidor). La parte HTML de este utiliza el AntiForgeryDataSerializer para serializar las siguientes piezas de datos - sal - valor (la cadena token) - las garrapatas de la fecha de creación - El nombre de usuario (parece que Context.User)

la El método de validación básicamente deserializa los valores de la cookie y del formulario y los compara en función de los valores (salt/value/ticks/username).

2/3) Creo que esta discusión es más sobre cuándo usar tokens XSRF y cuándo no. En mi opinión, debes usar esto en todas las formas (me refiero a por qué no). Lo único que puedo pensar que esto no protege es si realmente has golpeado el formulario en cuestión o no. Conocer la codificación base64 del nombre de la aplicación permitirá que el atacante pueda ver la cookie durante el ataque XSRF. Tal vez mi interpretación de eso es incorrecta.

4) ¿No está seguro exactamente de lo que está buscando aquí? Supongo que habría creado un mecanismo en el que intentaría almacenar el token XSRF en la sesión (si uno ya estaba disponible) y si no, intente con el método de cookies. En cuanto al tipo de crypto utilizado, encontré este SO artilugio. Pros and cons of RNGCryptoServiceProvider