Tenía que ver con la protección CSRF de Spring Security framework de Spring Security framework para ver cómo funciona. Spring no utiliza el patrón de envío doble, sino que asocia el token CSRF con la sesión del usuario. La documentacion incluye la siguiente explicación de por qué es decir:
Uno podría preguntarse por qué el CsrfToken esperado no se almacena en una cookie. Esto se debe a que existen vulnerabilidades conocidas en las que otros dominios pueden configurar encabezados (es decir, especificar las cookies). [...] Consulte este hilo de webappsec.org para obtener detalles sobre cómo realizar el exploit.
La esencia de lo que dice el hilo de webappsec.org es:
- El atacante coloca el documento de Flash en un sitio web controlado por un atacante, el usuario lo visita
- La aplicación Flash realiza una solicitud del mismo origen al sitio web de los atacantes, que establece el encabezado de destino, y esto está permitido por crossdomain.xml en el sitio web del atacante
- El sitio web de los atacantes responde a esta solicitud con un redireccionamiento 302 o 307 al sitio web de destino
- Flash (en "ciertas circunstancias") ignora el crossdomain.xml del sitio web de destino y realiza la solicitud al sitio web de destino con el encabezado adicional incluido
Mi pregunta es: ¿es esta una preocupación válida?
No pude reproducir el problema siguiendo los pasos del hilo de webappsec.org, y además parece que esto fue un error directo en Flash en lugar de una vulnerabilidad con el patrón de cookies de doble envío. Aunque este problema dio como resultado al menos dos CVE en los marcos de aplicaciones web No pude encontrar ningún error correspondiente para Flash, pero parece que o bien se ha corregido desde entonces, o no estaba reproduciendo correctamente las "determinadas circunstancias" no especificadas en las que esto sucede.