¿Qué sucede si mi token anti-CSRF se ve comprometido por un ataque XSS?

7

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:

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:

  1. Tokens del sincronizador (es decir, CSRF)
  2. Defensa de doble cookie
  3. 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.

    
pregunta Daniel 11.01.2018 - 05:34
fuente

2 respuestas

8

Si alguien tiene un XSS en su sitio, puede hacer cualquier cosa que desee en ese origen: envíe cualquier formulario, realice cualquier operación, etc. Javascript puede modificar el DOM de manera arbitraria, envíe formularios, modificar la vista del usuario, etc.

En consecuencia, robar el token CSRF es la menor de sus preocupaciones: el XSS permite cualquier cosa en el mismo origen que un CSRF permitiría. La única vez que podría preocuparse por esto es si comparte el mismo token CSRF en varios orígenes (lo que sería una mala práctica para empezar).

    
respondido por el David 11.01.2018 - 07:12
fuente
3

Con XSS, tiene acceso de lectura y escritura al DOM, entre otros, del usuario atacado. Por ejemplo, puede leer datos confidenciales o realizar ataques de phishing.

Pero si no pudo leer el token anti-CSRF (que, por supuesto, sí puede) y no puede leer el token de sesión, no pudo realizar acciones de escritura en el Servidor en nombre del usuario atacado. Aún podría realizar acciones de lectura en el servidor, por lo que podría obtener datos confidenciales que el usuario aún no muestra, pero no pudo realizar acciones que cambien las cosas.

Pero cuando su token anti-CSRF está comprometido, un atacante podría realizar cualquier acción que no esté protegida por mecanismos de respuesta-desafío (esto suele ser el caso cuando, por ejemplo, se cambia la contraseña o Dirección de correo electrónico, que comúnmente requiere la introducción de la contraseña actual).

Así que no estoy de acuerdo con la gente que diría que no es nada de qué preocuparse. Comprometer el token anti-CSRF permite a un atacante hacer mucho más daño, ya que actualiza el acceso de solo lectura al servidor para el acceso de lectura y escritura en el nombre del usuario atacado; solo en la medida en que sea irrelevante, ya que no puede evitar que se ponga en peligro el token una vez que tenga una vulnerabilidad XSS.

    
respondido por el tim 11.01.2018 - 10:50
fuente

Lea otras preguntas en las etiquetas