La mayoría de las discusiones sobre la vulnerabilidad BREACH se refieren al robo de tokens CSRF basados en sesiones. Pero si puede robar un token basado en sesión, ¿podría también robar el token de sesión? Obviamente, hay algunos puntos más finos del ataque BREACH que no entiendo :)
Estoy específicamente interesado en Django. En todas las solicitudes para las que el navegador envía una cookie csrftoken , el navegador también envía una cookie sessionid .
Editar :
Si mi nueva comprensión es correcta, entonces la respuesta es trivialmente NO. El BREACH paper dice:
Para ser vulnerable a este canal lateral, una aplicación web debe: (1) Servirse desde un servidor que usa compresión a nivel HTTP, Y (2) Refleja la entrada del usuario en los cuerpos de respuesta HTTP, Y (3) Refleja un secreto (como un token CSRF) en los cuerpos de respuesta HTTP.
¿Se refieren (2) y (3) a la misma cosa? Es decir, ¿el ataque solo es posible si la entrada del usuario repetida en el cuerpo de la respuesta HTTP es LA MISMA COSA como el secreto que está intentando robar?
Si esto es correcto, entonces tiene sentido.
Puede robar un token CSRF, porque el usuario lo ingresa (generalmente a través de un formulario POST param o cookie) Y puede repetirse nuevamente en la respuesta (ya sea como entrada oculta de un formulario o como una cookie ), Y es el secreto que estás intentando robar.
No puede robar un token de sesión, porque el usuario no puede alterar la salida basándose en esa entrada. Quiero decir, seguro, el usuario puede enviar una cookie de sesión modificada, pero el servidor (con suerte) nunca repetirá el token de sesión no válido en la respuesta.