Estaba leyendo esta pregunta sobre el uso del patrón de token de Synchronizer para protegerse contra CSRF y los comentarios de la respuesta me intrigaron. Por supuesto, como dice el último comentario, si su sitio tiene una vulnerabilidad XSS, entonces CSRF no es su mayor preocupación. Pero, ¿qué sucede si el otro sitio es una vulnerabilidad XSS?
Déjame poner el escenario.
- fakebank.com = su banco que tiene una página de transferencia de fondos que requiere que use un token único que obtiene en una página de obtención que debe incluirse en una publicación. Actualmente estás conectado a él.
- insecurefun.com = un sitio que está visitando actualmente. Tiene numerosos problemas, incluida la vulnerabilidad XSS.
- malicioussite.com = un sitio desagradable que nunca querrá visitar, pero es posible que haya publicado algunos complementos en insecurefun.com.
Por lo tanto, carga insecurefun.com y obtiene un anuncio de malwaresite.com. El complemento redirige un acceso a fakebank.com utilizando los datos de su sesión, lo que hace que fakebank.com envíe a su navegador la página de transferencia de confirmación que incluye el token único. Luego, el complemento explota la vulnerabilidad XSS de insecurefun.com para ejecutar javascript para obtener el token y finalmente realiza una publicación, lo que hace que su banco transfiera fondos.
Ahora, estoy bastante seguro de que esto no puede funcionar, porque si el Patrón de token del sincronizador se pudiera explotar tan fácilmente, no se recomendaría como protección contra los ataques CSRF. Pero, lo que no entiendo es por qué esto no puede ser explotado.
Mi única suposición es que la secuencia de comandos malintencionada no puede retener el token único para usarlo debido a la misma política de dominio. Pero si haces algo como this , parece que el script malicioso podría iniciar el GET Han devuelto el código HTML como una cadena, analizan los datos para el token único y luego inician la POST sin informar al usuario. ¿Qué me falta para evitar que esto funcione?
