La interesante pregunta de desbordamiento de pila "¿Las cookies protegen los tokens contra los ataques XSS?" se cerró como demasiado amplio, pero como se menciona en un comentario, hay una pregunta tangible de "¿Qué sucede si mi token anti-CSRF se ve comprometido por un ataque XSS?"; Me parece que las respuestas a esta pregunta pueden proporcionar información que ayudará a las personas a formarse opiniones sobre las preguntas planteadas en Stack Overflow. Por eso estoy planteando dicha pregunta tangible.
Supongamos que estamos usando el método de envío doble de cookies (a menos que haya un método mejor que desconozca) y que estemos almacenando JWT (por ejemplo, tokens de autenticación) en HttpOnly, cookies seguras.
Las siguientes páginas de intercambio de la pila de seguridad son relevantes:
- ¿Puede funcionar la protección CSRF incluso si Existe vulnerabilidad de XSS?
- LocalStorage vs. HTTP-Only Cookies + XSRF: ¿O es mejor cuando se trata de XSS?
- ¿Está JWT en las cookies con cualquier solución CSRF tan vulnerable al XSS como JWT en el almacenamiento local?
- Vulnerabilidades de doble envío de cookies
- ¿Por qué las cookies se consideran más seguras contra XSS?
- ¿Por qué las cookies de envío doble requieren una ¿cookie separada?
- ¿La configuración httponly evita que se robe una sesión? usando XSS?
- ¿Existe una protección sólida contra CSRF ejecutada desde el servidor de Sames a través de un XSS almacenado?
ACTUALIZACIÓN:
He estado leyendo más sobre los métodos anti-CSRF y encontré esta página OWASP comparando el método Double Submit Cookies con el Patrón de diseño de sincronizador alternativo y el Patrón de token cifrado, y declarando que en términos de fuerza de defensa se pueden ordenar como:
- Tokens del sincronizador (es decir, CSRF)
- Defensa de doble cookie
- Patrón de token cifrado
(OWASP también indica que 1. requiere un estado de sesión mientras que 2. y 3. no requiere un estado del lado del servidor. Existe una discusión sobre si el Patrón de token cifrado es realmente sin estado en los comentarios sobre el artículo titulado Aprovechando el patrón de token cifrado . Dicho artículo también describe las fallas de 1. y 2. que 3. resuelve, aparentemente sin presentar nuevas preocupaciones de seguridad o problemas de arquitectura. Como tal, no sé por qué OWASP lo clasificó como tercero en términos de fuerza de defensa. Tal vez debido a la cantidad de pruebas que se han realizado en este momento, ya que tanto ella como Double Submit Las cookies son relativamente nuevas; tal vez debido a la discusión sobre la apatridia / estado y la protección contra ataques de repetición en los comentarios del artículo. Sería bueno si hubiera una explicación de ese pedido.)
De todos modos ... Si alguien quiere responder a esta pregunta bajo la suposición alternativa de que se está utilizando el Patrón de token del sincronizador o el Patrón de token encriptado, sería genial.