¿Por qué es común colocar tokens de prevención de CSRF en las cookies?

Nuestro grupo especializado despúes de días de trabajo y recopilación de de información, dieron con la solución, esperamos que resulte útil para ti en tu plan.

Solución:

Una buena razón, que en cierto modo ha mencionado, es que una vez que se ha recibido la cookie CSRF, está disponible para su uso en toda la aplicación en el script del cliente para su uso tanto en formularios normales como en AJAX POST. Esto tendrá sentido en una aplicación pesada de JavaScript como la empleada por AngularJS (el uso de AngularJS no requiere que la aplicación sea una aplicación de una sola página, por lo que sería útil cuando el estado debe fluir entre diferentes solicitudes de página donde el valor CSRF normalmente no puede persistir en el navegador).

Considere los siguientes escenarios y procesos en una aplicación típica para conocer algunos pros y contras de cada enfoque que describa. Estos se basan en el patrón de token del sincronizador.

Solicitud de enfoque corporal

1. El usuario inicia sesión correctamente.
2. El servidor emite una cookie de autenticación.
3. El usuario hace clic para navegar a un formulario.
4. Si aún no se ha generado para esta sesión, el servidor genera el token CSRF, lo almacena en la sesión del usuario y lo envía a un campo oculto.
5. El usuario envía el formulario.
6. El servidor verifica que el campo oculto coincida con el token almacenado de la sesión.

Ventajas:

• Sencillo de implementar.
• Funciona con AJAX.
• Funciona con formularios.
• La cookie puede ser solo HTTP.

Desventajas:

• Todos los formularios deben generar el campo oculto en HTML.
• Cualquier POST de AJAX también debe incluir el valor.
• La página debe saber de antemano que requiere el token CSRF para poder incluirlo en el contenido de la página, por lo que todas las páginas deben contener el valor del token en algún lugar, lo que podría hacer que la implementación en un sitio grande lleve mucho tiempo.

Encabezado HTTP personalizado (descendente)

1. El usuario inicia sesión correctamente.
2. El servidor emite una cookie de autenticación.
3. El usuario hace clic para navegar a un formulario.
4. La página se carga en el navegador, luego se realiza una solicitud AJAX para recuperar el token CSRF.
5. El servidor genera el token CSRF (si aún no se generó para la sesión), lo almacena en la sesión del usuario y lo envía a un encabezado.
6. El usuario envía el formulario (el token se envía a través de un campo oculto).
7. El servidor verifica que el campo oculto coincida con el token almacenado de la sesión.

Ventajas:

• Funciona con AJAX.
• La cookie puede ser solo HTTP.

Desventajas:

• No funciona sin una solicitud AJAX para obtener el valor del encabezado.
• Todos los formularios deben tener el valor agregado a su HTML de forma dinámica.
• Cualquier POST de AJAX también debe incluir el valor.
• La página debe realizar una solicitud AJAX primero para obtener el token CSRF, por lo que significará un viaje de ida y vuelta adicional cada vez.
• También podría haber enviado el token a la página, lo que guardaría la solicitud adicional.

Encabezado HTTP personalizado (ascendente)

1. El usuario inicia sesión correctamente.
2. El servidor emite una cookie de autenticación.
3. El usuario hace clic para navegar a un formulario.
4. Si aún no se ha generado para esta sesión, el servidor genera el token CSRF, lo almacena en la sesión del usuario y lo muestra en el contenido de la página en algún lugar.
5. El usuario envía el formulario a través de AJAX (el token se envía a través del encabezado).
6. El servidor comprueba que el encabezado personalizado coincide con el token almacenado de la sesión.

Ventajas:

• Funciona con AJAX.
• La cookie puede ser solo HTTP.

Desventajas:

• No funciona con formularios.
• Todos los POST de AJAX deben incluir el encabezado.

Encabezado HTTP personalizado (ascendente y descendente)

1. El usuario inicia sesión correctamente.
2. El servidor emite una cookie de autenticación.
3. El usuario hace clic para navegar a un formulario.
4. La página se carga en el navegador, luego se realiza una solicitud AJAX para recuperar el token CSRF.
5. El servidor genera el token CSRF (si aún no se generó para la sesión), lo almacena en la sesión del usuario y lo envía a un encabezado.
6. El usuario envía el formulario a través de AJAX (el token se envía a través del encabezado).
7. El servidor comprueba que el encabezado personalizado coincide con el token almacenado de la sesión.

Ventajas:

• Funciona con AJAX.
• La cookie puede ser solo HTTP.

Desventajas:

• No funciona con formularios.
• Todos los POST de AJAX también deben incluir el valor.
• La página debe realizar una solicitud AJAX primero para obtener el token CRSF, por lo que significará un viaje de ida y vuelta adicional cada vez.

Set-Cookie

1. El usuario inicia sesión correctamente.
2. El servidor emite una cookie de autenticación.
3. El usuario hace clic para navegar a un formulario.
4. El servidor genera un token CSRF, lo almacena en la sesión del usuario y lo envía a una cookie.
5. El usuario envía el formulario a través de AJAX o mediante un formulario HTML.
6. El servidor verifica que el encabezado personalizado (o el campo de formulario oculto) coincida con el token almacenado en la sesión.
7. La cookie está disponible en el navegador para su uso en AJAX adicional y solicitudes de formulario sin solicitudes adicionales al servidor para recuperar el token CSRF.

Ventajas:

• Sencillo de implementar.
• Funciona con AJAX.
• Funciona con formularios.
• No requiere necesariamente una solicitud AJAX para obtener el valor de la cookie. Cualquier solicitud HTTP puede recuperarlo y puede adjuntarse a todos los formularios / solicitudes AJAX a través de JavaScript.
• Una vez que se ha recuperado el token CSRF, ya que está almacenado en una cookie, el valor se puede reutilizar sin solicitudes adicionales.

Desventajas:

• Todos los formularios deben tener el valor agregado a su HTML de forma dinámica.
• Cualquier POST de AJAX también debe incluir el valor.
• La cookie se enviará para cada solicitud (es decir, todos los GET para imágenes, CSS, JS, etc., que no están involucrados en el proceso CSRF) aumentando el tamaño de la solicitud.
• La cookie no puede ser solo HTTP.

Por lo tanto, el enfoque de cookies es bastante dinámico y ofrece una manera fácil de recuperar el valor de la cookie (cualquier solicitud HTTP) y usarlo (JS puede agregar el valor a cualquier formulario automáticamente y se puede emplear en solicitudes AJAX como encabezado o como valor de forma). Una vez que se ha recibido el token CSRF para la sesión, no es necesario volver a generarlo, ya que un atacante que emplea un exploit CSRF no tiene ningún método para recuperar este token. Si un usuario malintencionado intenta leer el token CSRF del usuario en cualquiera de los métodos anteriores, la Política del mismo origen lo impedirá. Si un usuario malintencionado intenta recuperar el lado del servidor del token CSRF (por ejemplo, a través de curl), entonces este token no se asociará a la misma cuenta de usuario, ya que la cookie de sesión de autenticación de la víctima faltará en la solicitud (sería la del atacante, por lo tanto, no se asociará del lado del servidor con la sesión de la víctima).

Además del Synchronizer Token Pattern, también existe el método de prevención de doble envío de cookies CSRF, que por supuesto utiliza cookies para almacenar un tipo de token CSRF. Esto es más fácil de implementar ya que no requiere ningún estado del lado del servidor para el token CSRF. El token CSRF, de hecho, podría ser la cookie de autenticación estándar cuando se usa este método, y este valor se envía a través de cookies como de costumbre con la solicitud, pero el valor también se repite en un campo oculto o encabezado, del cual un atacante no puede replicar como no pueden leer el valor en primer lugar. Sin embargo, se recomienda elegir otra cookie que no sea la de autenticación para que la cookie de autenticación pueda protegerse marcando HttpOnly. Entonces, esta es otra razón común por la que encontraría la prevención de CSRF utilizando un método basado en cookies.

El uso de una cookie para proporcionar el token CSRF al cliente no permite un ataque exitoso porque el atacante no puede leer el valor de la cookie y, por lo tanto, no puede colocarlo donde la validación CSRF del lado del servidor lo requiere.

El atacante podrá generar una solicitud al servidor con la cookie del token de autenticación y la cookie CSRF en los encabezados de la solicitud. Pero el servidor no busca el token CSRF como una cookie en los encabezados de la solicitud, está buscando en la carga útil de la solicitud. E incluso si el atacante sabe dónde colocar el token CSRF en la carga útil, tendría que leer su valor para colocarlo allí. Pero la política de origen cruzado del navegador evita la lectura de cualquier valor de cookie del sitio web de destino.

La misma lógica no se aplica a la cookie de token de autenticación, porque el servidor la espera en los encabezados de la solicitud y el atacante no tiene que hacer nada especial para colocarla allí.

Mi mejor suposición en cuanto a la respuesta: considere estas 3 opciones sobre cómo descargar el token CSRF del servidor al navegador.

1. En el cuerpo de la solicitud (no un encabezado HTTP).
2. En un encabezado HTTP personalizado, no Set-Cookie.
3. Como cookie, en un encabezado Set-Cookie.

Creo que el primero, el cuerpo de la solicitud (aunque lo demuestra el tutorial Express que vinculé en la pregunta), no es tan portátil para una amplia variedad de situaciones; no todo el mundo genera todas las respuestas HTTP de forma dinámica; donde termina necesitando poner el token en la respuesta generada puede variar ampliamente (en un formulario de entrada oculto; en un fragmento de código JS o una variable accesible por otro código JS; tal vez incluso en una URL, aunque generalmente parece un mal lugar poner tokens CSRF). Entonces, si bien es factible con algo de personalización, el n. ° 1 es un lugar difícil para hacer un enfoque único para todos.

El segundo, el encabezado personalizado, es atractivo pero en realidad no funciona, porque si bien JS puede obtener los encabezados de un XHR que invoca, no puede obtener los encabezados de la página desde la que se cargó.

Eso deja al tercero, una cookie transportada por un encabezado Set-Cookie, como un enfoque que es fácil de usar en todas las situaciones (el servidor de cualquier persona podrá establecer encabezados de cookies por solicitud, y no importa qué tipo de los datos están en el cuerpo de la solicitud). Entonces, a pesar de sus desventajas, fue el método más fácil de implementar ampliamente para los marcos.

valoraciones y reseñas

---

---

Utiliza Nuestro Buscador