El token CSRF no está vinculado a la sesión en la aplicación Spring

Por lo tanto, lo hemos resuelto. Spring Security establece el CSRF-Token como una cookie a la que el sitio malvado example.com no puede acceder porque los sitios no pueden acceder a las cookies que no pertenecen a su dominio. Al enviar los formularios, hay un campo de entrada oculto que tiene el token y también se envía. Spring compara el token en la cookie con el token en la entrada oculta enviada. Si coinciden, todo está bien, de lo contrario se devuelve 403. Debido a que el sitio example.com es malo, no se puede acceder al token en la cookie, los formularios enviados desde el sitio example.com no pueden tener el token CSRF correcto en la entrada oculta (creo que la falsificación de DNS podría darles acceso al token en la cookie, pero luego tenemos un hombre en el ataque central, así como CSRF)

El problema con nuestras pruebas anteriores fue que estábamos cambiando ambos tokens: el de la entrada oculta y el de la cookie, que, como se mencionó anteriormente, un atacante no puede hacer, por lo que nuestro vector de ataque fue realmente poco realista.

Además, debido a esto, Spring Security no necesita vincular explícitamente el token de la cookie a una sesión porque sabe que solo nuestro dominio, es decir, nuestra aplicación, puede cambiar el token (en realidad creo que hay un concepto de "cookies de sesión" también, pero eso no surgió aquí), lo que significa que mientras se cambien los tokens en la cookie y la entrada oculta a un UUID válido, los tokens coincidirán en el lado del servidor y Seguridad de primavera no le importará. Incluso fuimos tan lejos como para usar UUID para los tokens que no fueron generados por Spring Security, lo que significa que Spring Security no los tenía en su tokenRepository y a Spring Security todavía no le importaba. Esto nos sorprendió un poco al principio, pero supongo que como el atacante no puede acceder al token de la cookie, Spring Security solo se preocupa si coinciden.

Generalmente puedo hablar con CSRF, pero no con el framework Spring (que no he usado). Como no puedo verificar sus reclamaciones con Spring, voy a tomar sus reclamaciones a su valor nominal. A saber:

1. Puede obtener un token CSRF haciendo una llamada válida usando cualquier sesión de su elección
2. Si obliga a cualquier otro usuario a realizar una solicitud con su token CSRF, Spring lo aceptará como un token válido

Suponiendo que sus hallazgos son precisos (una vez más, no estoy dudando de usted, simplemente no puedo verificarlo), estos son mis pensamientos inmediatos:

1. No se debe permitir que los tokens CSRF crucen sesiones como esta.
2. Ciertamente consideraría esto como una vulnerabilidad de seguridad.
3. Detalles adicionales sobre cómo Spring valida los tokens CSRF son necesarios para decidir si hay un vector de ataque realista aquí.

En detalle, los tokens CSRF definitivamente no deberían poder cruzar sesiones. Cada token CSRF debe estar asociado con la sesión que lo generó, y no debe ser un token válido para ninguna otra sesión. Como señala, al permitir que los tokens para cruzar las sesiones, es posible que un atacante genere tokens válidos de antemano. Esto definitivamente puede ser un problema. Sin embargo, hay algunas circunstancias que pueden mitigar la amenaza potencial aquí:

Más que solo verificación de token

Los tokens son solo una forma de protegerse contra los ataques CSRF. Personalmente, creo que son la forma más directa y confiable. Sin embargo, no son la única manera. Otra opción es verificar los encabezados REFERRER y ORIGIN . Si Spring también está comprobando los encabezados REFERRER y ORIGIN, es poco probable que esta debilidad en su token CSRF sea explotable. La prueba que hiciste (cambiando manualmente el token CSRF a través de las herramientas del navegador) aún te dejará con los encabezados REFERRER y ORIGIN adecuados, lo que significa que pasarás ambas comprobaciones CSRF. Sin embargo, no sería posible para un atacante reproducir esto. Funciona para usted porque estaba en la página de la aplicación real y editó la página de la aplicación directamente. Un atacante hará que ocurra un ataque CSRF desde algún lugar completamente diferente, y no puede forzar los encabezados de REFERENCIA y ORIGEN. Por lo tanto, si Spring también también verifica los encabezados REFERRER y ORIGIN, entonces está bien.

¿La primavera hace ambas cosas? No lo sé. ¿Por qué Spring haría ambas cosas? No estoy seguro, aunque estaría en línea con el concepto de "Defensa en profundidad", por lo que no sería una locura que hiciera ambas pruebas. Si está haciendo ambas cosas, obviamente, incluso una gran debilidad en el token CSRF no importará. Sin embargo, si hace ambas cosas e ignora una u otra en ciertas circunstancias, entonces podría haber un vector de ataque si puede hacer que ignore las comprobaciones de encabezado y también falsificar el token CSRF.

Caducidad del token CSRF

También puede haber un vencimiento del token que hará que sea difícil convertir esto en un vector de ataque explotable. De hecho, es casi seguro que tiene un vencimiento simbólico. Como atacante, puede generar un token CSRF válido, pero si tiene una caducidad corta, debe colocarlo delante de un objetivo rápidamente. Supongamos que creó un vector de ataque CSRF que elevó efectivamente su cuenta de usuario a administrador cuando un administrador ve una página maliciosa que generó. Esto solo le servirá de nada si puede engañar a un administrador para que vea su página de ataque antes de que caduque su token. Dependiendo de su método de entrega y la duración de la caducidad del token, esto puede ser muy difícil.

Para resumir: ¿es esta la norma para CSRF? No, de hecho es potencialmente peligroso. ¿Es explotable? Eso es más difícil de responder. Como siempre, el diablo está en los detalles. ¿Vale la pena profundizar en más? Yo diría que sí.