¿Es este un método anti-CSRF apropiado?

Question

¿Es este un método anti-CSRF apropiado?

#1 de Rahil Arora (1 votos)
#2 de SilverlightFox (1 votos)

3

Tengo el siguiente sistema en mi aplicación web y me gustaría saber si es seguro.

La cookie contiene el token CSRF.
La aplicación detecta el token CSRF en la cookie.
La aplicación coloca el token en un encabezado.
El servidor verifica el token en el encabezado.

No he visto ninguna información definitiva sobre si está bien o no usar las cookies como un lugar para almacenar tokens CSRF. Por favor, ilumíname.

EDITAR: Más detalles: Angular busca un token CSRF en las cookies, y cuando encuentra uno, agrega un encabezado con este valor. Entonces el servidor determina si el valor del encabezado es legítimo.

web-application csrf

pregunta Jack 09.07.2015 - 17:41

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application csrf

PCI DSS 3.0: 11.3 - ¿Qué sucede si una vulnerabilidad de bajo riesgo impide el cumplimiento de otro requisito? Seguridad de OpenVPN frente a una solución sofisticada de DPI

score 1 · Answer 1

No veo ningún defecto en el método y creo que se puede usar para proteger contra CSRF. Solo hay un pequeño problema: este método funcionará bien siempre y cuando la cookie que almacena el token CSRF esté NO configurada como HTTPOnly . El problema es con este requisito:

La aplicación detecta / coloca el token.

Esta implementación es similar a Double Submit Cookies . El envío doble de cookies se define como el envío de un valor aleatorio tanto en una cookie como en un parámetro de solicitud, con el servidor verificando si el valor de la cookie y el valor de la solicitud son iguales. La ventaja de utilizar este método es que la aplicación no tiene que guardar este valor de ninguna manera.

Dado que su implementación requiere que el valor de la cookie se lea a través de scripts del lado del cliente (JavaScript) y luego se coloque como encabezado de solicitud, puede interrumpir la funcionalidad de la aplicación si se establece como HttpOnly (lo que impide JavaScript de leer su valor) en cualquier momento en el futuro.

score 1 · Answer 2

Sí, agregar un encabezado personalizado, incluso sin un token y usando uno estático como X-Requested-With: XMLHttpRequest protege inherentemente contra CSRF porque los encabezados personalizados no se pueden pasar entre dominios sin habilitar CORS en el servidor.

Si existe una relación de uno a uno entre su dominio de UI y su dominio de API (o que son el mismo dominio), agregar cualquier encabezado personalizado mitigará el CSRF.

Si planea usar su API para servir múltiples sitios web, posiblemente no fiables, entonces deberá asegurarse de que uno de los sitios web que respalda no pueda realizar solicitudes de API en nombre de otro, por lo tanto, su enfoque de token en un encabezado es más adecuado para eso. El token se puede validar para garantizar que coincida con la sesión del usuario y que tenga una clave de API válida del sitio web que se utiliza para el front-end. Sin embargo, esto encajaría mejor con el