¿Es segura la compresión HTTP?

Navega tus respuestas
37

El ataque de CRIME nos enseñó que el uso de la compresión puede poner en peligro la confidencialidad. En particular, es peligroso concatenar datos suministrados por el atacante con datos secretos confidenciales y luego comprimir y cifrar la concatenación; Cada vez que vemos que ocurre, en cualquier capa de la pila del sistema, debemos sospechar del potencial de ataques tipo CRIME.

Ahora el ataque CRIME, al menos como se ha descrito públicamente hasta ahora, es un ataque a la compresión TLS. Antecedentes: TLS incluye un mecanismo de compresión incorporado, que ocurre en el nivel TLS (toda la conexión está comprimida). Por lo tanto, tenemos una situación en la que los datos proporcionados por el atacante (por ejemplo, el cuerpo de una solicitud POST) se mezclan con los secretos (por ejemplo, las cookies en los encabezados HTTP), que es lo que habilitó el ataque por CRIMEN.

Sin embargo, también hay otras capas de la pila del sistema que pueden usar la compresión. Estoy pensando especialmente en compresión HTTP . El protocolo HTTP tiene soporte incorporado para comprimir cualquier recurso que descargue a través de HTTP. Cuando la compresión HTTP está habilitada, la compresión se aplica al cuerpo de la respuesta (pero no a los encabezados). La compresión HTTP se habilitará solo si tanto el navegador como el servidor lo admiten, pero la mayoría de los navegadores y muchos servidores lo hacen, porque mejora el rendimiento . Tenga en cuenta que la compresión HTTP es un mecanismo diferente de la compresión TLS; La compresión HTTP se negocia en un nivel más alto de la pila y solo se aplica al cuerpo de la respuesta. Sin embargo, la compresión HTTP se puede aplicar a los datos que se descargan a través de una conexión SSL / TLS, es decir, a los recursos descargados a través de HTTPS.

Mi pregunta: ¿Es segura la compresión HTTP en los recursos HTTPS? ¿Debo hacer algo especial para deshabilitar la compresión HTTP de los recursos a los que se accede a través de HTTPS? O, si la compresión HTTP es segura, ¿por qué es segura?

    
pregunta D.W. 20.09.2012 - 02:07
fuente

2 respuestas

38

Me parece arriesgado. La compresión HTTP está bien para los recursos estáticos, pero para algunos recursos dinámicos servidos sobre SSL, parece que la compresión HTTP puede ser peligrosa. Me parece que la compresión HTTP puede, en algunas circunstancias, permitir ataques tipo CRIME.

Considere una aplicación web que tenga una página dinámica con las siguientes características:

  1. Se sirve a través de HTTPS.

  2. El servidor admite la compresión HTTP (esta página se enviará al navegador en forma comprimida, si el navegador admite la compresión HTTP).

  3. La página tiene un token CSRF en alguna parte. El token CSRF está fijo durante la vida útil de la sesión (por ejemplo). Este es el secreto que el ataque tratará de aprender.

  4. La página contiene contenido dinámico que puede especificar el usuario. Para simplificar, supongamos que hay un parámetro de URL que se refleja directamente en la página (quizás con algún escape de HTML aplicado para evitar XSS, pero eso está bien y no detendrá el ataque descrito).

Luego, creo que los ataques de estilo CRIME podrían permitir que un atacante aprenda el token CSRF y monte los ataques CSRF en el sitio web.

Déjame dar un ejemplo. Supongamos que la aplicación web de destino es un sitio web bancario en www.bank.com , y la página vulnerable es https://www.bank.com/buggypage.html . Supongamos que el banco se asegura de que solo se pueda acceder a la banca mediante SSL (https). Y, supongamos que si el navegador visita https://www.bank.com/buggypage.html?name=D.W. , entonces el servidor responderá con un documento HTML con una apariencia vagamente similar a esta: 

<html>...<body>
Hi, D.W.!  Pleasure to see you again.  Some actions you can take:
<a href="/closeacct&csrftoken=29238091">close my account</a>,
<a href="/viewbalance&csrftoken=...">view my balance</a>, ...
</body></html>

Supongamos que está navegando por la web a través de una conexión Wifi abierta, de modo que un atacante pueda escuchar todo el tráfico de su red. Supongamos que actualmente está conectado a su banco, por lo que su navegador tiene una sesión abierta con el sitio web de su banco, pero en realidad no está realizando ninguna actividad bancaria a través de la conexión Wifi abierta. Supongamos, además, que el atacante puede atraerlo para que visite el sitio web del atacante http://www.evil.com/ (por ejemplo, tal vez realizando un ataque de hombre en el medio hacia usted y redirigiéndolo cuando intente visitar otro sitio http).

Luego, cuando su navegador visita http://www.evil.com/ , esa página puede desencadenar solicitudes de dominios cruzados al sitio web de su banco, en un intento de conocer el token CSRF secreto. Tenga en cuenta que Javascript tiene permiso para realizar solicitudes de dominios cruzados. La política del mismo origen no le permite ver la respuesta a una solicitud de varios dominios. No obstante, dado que el atacante puede espiar el tráfico de la red, el atacante puede observar la longitud de todos los paquetes cifrados y así inferir algo sobre la longitud de los recursos que se están descargando a través de la conexión SSL a su banco.

En particular, la página maliciosa http://www.evil.com/ puede desencadenar una solicitud a https://www.bank.com/buggypage.html?name=closeacct&csrftoken=1 y ver qué tan bien se comprime la página HTML resultante (al espiar los paquetes y observar la longitud del paquete SSL del banco). A continuación, puede desencadenar una solicitud a https://www.bank.com/buggypage.html?name=closeacct&csrftoken=2 y ver qué tan bien se comprime la respuesta. Y así sucesivamente, para cada posibilidad para el primer dígito del token CSRF. Uno de ellos debería comprimir un poco mejor que los otros: uno donde el dígito en el parámetro de URL coincide con el token CSRF en la página. Esto le permite al atacante aprender el primer dígito del token CSRF.

De esta manera, parece que el atacante puede aprender cada dígito del token CSRF, recuperándolos dígito a dígito, hasta que el atacante aprenda todo el token CSRF. Luego, una vez que el atacante conoce el token CSRF, puede hacer que su página maliciosa en www.evil.com desencadene una solicitud de dominio cruzado que contenga el token CSRF apropiado, lo que supera con éxito las protecciones CSRF del banco.

Parece que esto puede permitir a un atacante montar un ataque CSRF exitoso en aplicaciones web, cuando se aplican las condiciones anteriores, si la compresión HTTP está habilitada. El ataque es posible porque estamos combinando secretos con datos controlados por un atacante en la misma carga útil, y luego comprimimos y ciframos esa carga útil.

Si hay otros secretos que se almacenan en HTML dinámico, podría imaginar que ataques similares podrían ser posibles para aprender esos secretos. Este es solo un ejemplo del tipo de ataque en el que estoy pensando. Por lo tanto, me parece que el uso de la compresión HTTP en páginas dinámicas a las que se accede a través de HTTPS es un poco arriesgado. Puede haber buenas razones para deshabilitar la compresión HTTP en todos los recursos servidos a través de HTTPS, a excepción de las páginas / recursos estáticos (por ejemplo, CSS, Javascript).

    
respondido por el D.W. 20.09.2012 - 02:19
fuente
23

La compresión, en general, altera la longitud de lo que se comprime (es exactamente por eso que comprimimos). Compresión sin pérdida altera la longitud según los datos en sí mismos (mientras que la compresión con pérdida puede alcanzar una compresión fija relación, por ejemplo, un archivo MP3 a un estricto 128 kbit / s). La longitud de los datos es lo que se filtra a través del cifrado, por lo que estamos interesados en él.

De una manera muy genérica, una fuga de longitud puede ser fatal, incluso en presencia de un atacante pasivo; es un tipo de análisis de tráfico . Un ejemplo es de la Primera Guerra Mundial, donde los criptógrafos franceses podrían predecir la importancia de un mensaje basado en la longitud del encabezado (encriptado): se envió un mensaje importante al coronel ( Oberst ) mientras que es menos importante los mensajes fueron etiquetados para un teniente ( Oberleutnant , un término mucho más largo).

La compresión hace que las fugas de longitud solo empeoren, ya que evita que corrijas las fugas de longitud al normalizar las longitudes de los mensajes.

Cuando el atacante puede agregar algunos datos propios en los fragmentos comprimidos, amplifica la fuga de longitud, que puede convertirse en un vector de ataque práctico para datos de objetivos arbitrarios, como el ataque CRIME demuestra Sin embargo, sostengo que el problema ya estaba allí. En esa vista, la compresión a nivel de HTTP no es un riesgo nuevo; es más bien un factor agravante de un riesgo preexistente. Permitir que el atacante agregue algunos de sus propios datos en el flujo cifrado es otro factor agravante, y estos factores se suman.

Apuesto a que no eres el primero en tener esta idea. No solo muchas personas (yo incluido) lo pensaron en los últimos 10 días, sino que si intentas acceder a esta URL: 

http://www.google.com/sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa

luego obtienes un error 404 de Google, que contiene la palabra "sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa". Oye, ese atacante eligió los datos reflejados, ¡eso podría ser divertido! Así que intentemos nuevamente con una URL HTTPS: 

https://www.google.com/sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa

y luego, no 404, no es divertido, eres redirigido sin ceremonias a la página de inicio de Google. Esto me hace pensar que algunas personas en Google también lo pensaron, y desactivaron de forma proactiva el bit de reflexión cuando usan SSL (porque al usar SSL, obtienes las campanas y silbidos de Google+, por lo tanto, datos potencialmente peligrosos).

    
respondido por el Thomas Pornin 20.09.2012 - 03:05
fuente

Lea otras preguntas en las etiquetas

¿Cómo puede cambiar su DNS proteger su privacidad en línea? Si el correo electrónico es inseguro, ¿por qué lo usamos para restablecer la contraseña?