Django suministra middleware GZip, pero docs emiten un Stark advertencia acerca de BREACH , que hasta ahora había olvidado. Lo primero que pensé fue que debería poder modificar el middleware para agregar primero una cantidad aleatoria de caracteres aleatorios en el cuerpo de la solicitud antes de GZipearlo y hacer que BREACH sea inútil. ¿Es correcto o estoy malinterpretando por completo el INCUMPLIMIENTO?
Si siempre tienes la misma cantidad de datos aleatorios, el ataque probablemente funcionará de la misma manera. Si en su lugar agrega una cantidad aleatoria de datos aleatorios, es posible que el ataque original ya no funcione, pero creo que puede modificarse simplemente intentándolo una y otra vez con la esperanza de que la misma cantidad de datos aleatorios se agregue con la suficiente frecuencia. Lo que significa que ralentizará el ataque solo y la cantidad depende de la cantidad de datos aleatorios que agregue. Por ejemplo, si agrega entre 1 y 10 caracteres aleatorios en la parte superior del archivo, probablemente ralentizará el ataque en un factor de 10. Si agrega 1..100 caracteres, la ralentización será un factor de 100.
Un mejor enfoque sería crear un valor aleatorio y modificar el token CSRF para que conste de este valor aleatorio y un XOR o con este valor con el token CSRF original. De esta manera, el token CSRF cambiará todo el tiempo dentro del HTML para que BREACH ya no funcione. Y la aplicación puede recuperar fácilmente el token CSRF original.
agregue una cantidad aleatoria de caracteres aleatorios en el cuerpo de la solicitud antes de GZipearla
Esto ralentizará el ataque, pero no lo impedirá.
La idea detrás de BREACH (y oráculos de compresión en general) es que el texto plano (y por lo tanto el texto cifrado) será un poco más corto si el atacante adivina el siguiente byte del token secreto correctamente. Si hay algo de aleatoriedad en la longitud del texto simple, el atacante puede hacer la misma conjetura muchas veces y "promediar" los resultados. Las solicitudes realizadas utilizando el cálculo correcto serán un poco más cortas en promedio .
(Un atacante real usaría una técnica estadística más sofisticada para reducir la cantidad de solicitudes requeridas, pero entiendes la idea).
Lea otras preguntas en las etiquetas exploit known-vulnerabilities compression