¿Cuál es el propósito del encabezado / cookie predeterminado en un token anti-falsificación MVC?

ASP.NET MVC utiliza una variación de sincronizador patrón / a>. En una implementación típica, el patrón de token de syncrhonizer funciona al generar un token aleatorio grande y conservarlo en dos ubicaciones:

1. Estado de la sesión (ya sea en el servidor o en el cliente)
2. En un campo de formulario oculto

Cuando se envía un formulario, el servidor verificará que ambos valores coincidan y fallen si no lo hacen. Esto funciona porque un atacante no puede obtener el valor del token por adelantado.

ASP.NET MVC modifica ligeramente este patrón al no usar el estado de sesión, en lugar de usar la cookie de sesión. El token también contiene algunos datos adicionales dependiendo de si se trata de un token de cookie o un token de campo de formulario:

    /* The serialized format of the anti-XSRF token is as follows:
     * Version: 1 byte integer
     * SecurityToken: 16 byte binary blob
     * IsCookieToken: 1 byte Boolean
     * [if IsCookieToken != true]
     *   +- IsClaimsBased: 1 byte Boolean
     *   |  [if IsClaimsBased = true]
     *   |    '- ClaimUid: 32 byte binary blob
     *   |  [if IsClaimsBased = false]
     *   |    '- Username: UTF-8 string with 7-bit integer length prefix
     *   '- AdditionalData: UTF-8 string with 7-bit integer length prefix
     */

Ambos tokens están cifrados y autenticados y, por lo tanto, no se pueden leer en el lado del cliente. Consulte la implementación del serializador aquí . Dada la anatomía del token anterior, puede ver que ni siquiera son idénticos en el lado del cliente, ambos se cifrarán en dos textos cifrados diferentes y no se pueden validar allí.

Probablemente pueda cambiar el comportamiento de una manera en que no se necesita una cookie almacenando el lado del servidor del token CSRF en el estado de la sesión. Pero realmente necesita dos de ellos y realmente necesita compararlos para hacer que la protección CSRF funcione.

EDIT

Para responder más directamente a tu pregunta original

  

¿Cuál es el propósito del encabezado / cookie predeterminado en un MVC?   token anti-falsificación?

Para dar una solución completa que funcione todo el tiempo y para cualquier aplicación.

Incluso tiene un capacidad para proteger páginas de inicio de sesión :

  

Autenticación anónima

     

El sistema anti-XSRF contiene soporte especial para usuarios anónimos,   donde "anónimo" se define como un usuario donde el   La propiedad IIdentity.IsAuthenticated devuelve false. Los escenarios incluyen   proporcionando protección XSRF a la página de inicio de sesión (antes de que el usuario esté   autenticado) y esquemas de autenticación personalizados donde la aplicación   utiliza un mecanismo distinto de Identity para identificar a los usuarios. Apoyar   En estos escenarios, recuerde que la sesión y los tokens de campo están unidos.   por un token de seguridad, que es un opaco de 128 bits generado aleatoriamente   identificador Este token de seguridad se utiliza para rastrear un usuario individual   sesión mientras navega por el sitio, por lo que efectivamente sirve a la   propósito de un identificador anónimo. Se usa una cadena vacía en su lugar   del nombre de usuario para las rutinas de generación y validación descritas.   arriba.

Según sus comentarios, se pregunta si puede hacerlo sin una cookie incluyendo el nombre de usuario y la fecha de caducidad cifrados en un campo de formulario oculto. La respuesta sería depende .

Tal token podría ser robado con un ataque XSS mientras que una cookie de autenticación (o cookie de token CSRF) marcada con httpOnly no podría. Esto haría que su solución sea vulnerable en el plazo de su vencimiento. Si esto es aceptable o no depende de usted y del tipo de aplicación. Por ejemplo, una aplicación de banca en red no toleraría ningún tipo de vulnerabilidad CSRF pero un juego en línea simple podría.

Puede evitar el CSRF por completo si no utiliza cookies para almacenar tokens de autenticación.

No importa dónde colocar la cookie de hash del lado del cliente o lo que sea. Puedes ponerlo incluso en un campo oculto de un formulario. Todo en el lado del cliente será accesible de todos modos. Eso no es un problema, mientras que el usuario legítimo es quien está accediendo a ellos.

El punto como usted dijo es generarlo en el lado del servidor al mismo tiempo y luego recibirlo del cliente para verificar si la coincidencia es correcta. De esa forma puedes legitimar la solicitud. Eso es todo.

Tal vez, si un atacante puede robar una cookie / hash de un cliente, podrá realizar el ataque CSRF, pero no tiene mucho sentido ... probablemente si él es capaz de robar a un cliente allí ser cosas más interesantes para robar como la cookie de sesión para iniciar sesión o algo más.