BREACH - un nuevo ataque contra HTTP. ¿Qué se puede hacer?

Aunque el artículo no está lleno de detalles, podemos inferir algunas cosas:

• Attack usa la compresión con el mismo principio general que CRIME : el atacante puede hacer que un sistema objetivo comprima una secuencia de caracteres que incluya un valor secreto (que el atacante intenta adivinar) y algunos caracteres que el atacante puede elegir. Eso es un ataque de texto sin formato elegido . La longitud de comprimido dependerá de si la cadena del atacante "se parece" al secreto o no. La longitud comprimida se filtra a través del cifrado SSL, porque el cifrado oculta contenidos , no length.

• El artículo habla específicamente de "cualquier secreto que [...] se encuentre en el cuerpo ". Así que estamos hablando de compresión a nivel de HTTP, no de compresión a nivel de SSL. La compresión HTTP se aplica solo en el cuerpo de la solicitud, no en el encabezado. Así que los secretos en el encabezado , en particular los valores de las cookies, están a salvo de ese.

• Como hay "solicitudes de sondeo", entonces el ataque requiere algún código malicioso en el navegador del cliente; el atacante también debe observar los bytes cifrados en la red y coordinar ambos elementos. Esta es la misma configuración que para CRIME y BEAST.

• No está claro (del artículo solo, que es todo lo que tengo que discutir en este momento) si el cuerpo comprimido es uno del cliente o del servidor . La "solicitud de sondeo" es ciertamente enviada por el cliente (en nombre del atacante), pero las respuestas del servidor pueden incluir parte de lo que se envía en la solicitud, por lo que el "ataque de texto sin formato elegido" puede funcionar en ambos sentidos.

En cualquier caso, "BREACH" se parece a una metodología de ataque que debe adaptarse al caso específico de un sitio objetivo. En ese sentido, no es nada nuevo; ya era "bien conocido" que la compresión filtra información y no había ninguna razón para creer que la compresión a nivel HTTP fuera mágicamente inmune. Heck, se discutió aquí el año pasado. Sin embargo, es bueno que algunas personas hagan un esfuerzo adicional para mostrar demostraciones de trabajo porque, de lo contrario, las fallas nunca se arreglarían. Por ejemplo, los ataques oracle de relleno contra CBC se describieron e incluso se crearon un prototipo en 2002, pero se necesitó una demostración real contra ASP en 2010 para convencer a Microsoft de que el peligro era real. Del mismo modo, para BEAST en 2011 (la necesidad de un IV impredecible para el modo CBC también se conocía desde 2002) y CRIME en 2012; BREACH es más "CRIME II": una capa más de pedagogía para derribar a los incrédulos.

Desafortunadamente, muchas personas se equivocarán y creerán que se trata de un ataque contra SSL, pero no lo es. No tiene nada que ver con SSL, en realidad. Es un ataque que fuerza una fuga de información a través de un canal de datos de bajo ancho de banda, la longitud de datos , que SSL nunca ha cubierto, y nunca reclamó que cubra.

El resumen ejecutivo de una línea es que no comprimirás .

BREACH, al igual que CRIME, es un ataque relacionado con la compresión. Desactivar la compresión hace que el ataque sea imposible.

AÑADIDO
Tenga en cuenta que en este caso parece que desactiva una configuración de compresión diferente ; mientras que CRIME explota la compresión de la capa TLS, BREACH explota la compresión de la capa HTTP.

Acabo de pensar en una forma de agregar "Secretos aleatorios por solicitud", "Ocultamiento de longitud" y "Solicitudes de limitación de velocidad" a una medida de mitigación CSRF.

1. Considere qué formularios no querría que un atacante POST en nombre del usuario. Estos son los formularios que protegería de CSRF.
2. Para cada vista de página, genere una sal aleatoria de longitud aleatoria. Enviar esta sal como una entrada oculta. La longitud aleatoria debería ayudar a agregar ruido a las longitudes, incluso si su equilibrador de carga de front-end elimina comentarios o de lo contrario minimiza su HTML.
3. Calcule un hash del salt, el ID de sesión y un secreto del lado del servidor, y envíe esta clave CSRF como otra entrada oculta.
4. Opcionalmente, registre la clave salt o CSRF en una tabla. Esto permite limitar la velocidad de una cuenta de usuario o dirección IP en particular a una cantidad de hashes por hora y limitar las repeticiones de una sal en particular.
5. Cuando procese el formulario, calcule el hash de la misma forma que lo hizo en los pasos anteriores, utilizando el salt en el formulario, y asegúrese de que coincida con la clave CSRF.

El ataque funciona al inferir información del tamaño de la carga útil. El relleno artificial servido con páginas HTTPS (por ejemplo, una cadena de comentarios de tamaño aleatorio) podría mitigar su efectividad.