Imagina un restaurante con un solo camarero y un chef. Si el camarero interpreta tu pedido de una forma y el chef de otra totalmente diferente, es seguro que habrá problemas, ¿cierto? Pues bien, eso es, en esencia, la vulnerabilidad HTTP Request Smuggling. Se produce cuando hay una diferencia en la interpretación de las solicitudes HTTP entre los servidores front-end y back-end, similar a la confusión entre el camarero y el chef, lo que puede llevar a resultados inesperados y, en el contexto digital, potencialmente peligrosos.
En este artículo, exploramos la vulnerabilidad de HTTP Request Smuggling, detallando su concepto, el papel de los encabezados Content-Length y Transfer-Encoding, y cómo su incorrecta gestión puede generar brechas de seguridad. Analizamos los distintos tipos de smuggling y presentamos estrategias efectivas para prevenir esta amenaza.
¿Qué es HTTP Request Smuggling?
Las vulnerabilidades de HTTP Smuggling se presentan cuando el inicio y fin de una solicitud HTTP son interpretados de manera diferente por el frontend y el backend de una aplicación. Esta discrepancia ocurre debido a que diversas bibliotecas frontend y backend se apartan de las especificaciones RFC en cuanto a los encabezados “Content-Length” y “Transfer-Encoding”.
Desde HTTP/1.1 existe soporte generalizado para enviar múltiples solicitudes HTTP a través de un único socket TCP. El protocolo es extremadamente simple: las solicitudes HTTP se colocan una detrás de la otra, y el servidor analiza los encabezados (Transfer-Encoding o Content-Length) para determinar dónde termina cada una y dónde comienza la siguiente.
¿Para qué sirven los encabezados Content-Length y Transfer-Encoding ?
El encabezado HTTP Content-Length, indica el tamaño del mensaje. Esto se ve comúnmente en las solicitudes HTTP POST que tienen un cuerpo de datos.
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 3
123
Además, el encabezado HTTP Transfer-Encoding, fue diseñado para posibilitar la transferencia de datos binarios a través de HTTP.
El Transfer-Encoding tiene varias directivas, siendo la directiva “chunked” la más comúnmente utilizada para aprovechar el HTTP smuggling. Cuando se emplea ‘Transfer-Encoding: chunked’, el tamaño del mensaje se indica con un número en formato hexadecimal dentro del cuerpo del mensaje, seguido de un salto de línea y retorno de carro (\r\n). Luego sigue el propio mensaje y, finalmente, un 0 con un nuevo salto de línea y retorno de carro (\r\n) para señalar el final del mensaje.
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
3
123
0
¿Cómo surgen las vulnerabilidades de HTTP Request Smuggling?
Como la especificación HTTP/1 proporciona dos métodos diferentes para especificar la longitud de los mensajes HTTP, es posible que un solo mensaje utilice ambos métodos a la vez, de modo que entren en conflicto entre sí. La especificación intenta evitar este problema indicando que si los encabezados Content-Length y Transfer-Encoding están presentes, entonces el encabezado Content-Length debe ignorarse.
Esto podría ser suficiente para evitar ambigüedades cuando solo hay un servidor en juego, pero no cuando dos o más servidores están encadenados. En esta situación, pueden surgir problemas por dos motivos:
- Algunos servidores no admiten el encabezado Transfer-Encoding en las solicitudes.
- Se puede inducir a algunos servidores que admiten el encabezado Transfer-Encoding a no procesarlo si el encabezado está ofuscado de alguna manera.
Si los servidores front-end y back-end se comportan de manera diferente en relación con el encabezado Transfer-Encoding (posiblemente ofuscado), entonces podrían no estar de acuerdo sobre los límites entre solicitudes sucesivas, lo que generaría vulnerabilidades HTTP Request Smuggling.
Tipos de HTTP Request Smuggling
Los ataques clásicos de HTTP Request Smuggling implican colocar tanto el encabezado Content-Length como el encabezado Transfer-Encoding en una única solicitud HTTP/1.1 y manipularlos para que los servidores front-end y back-end procesen la solicitud de manera diferente. La forma exacta en que se hace esto depende del comportamiento de los dos servidores:
- CL.TE: el servidor de front-end usa el encabezado Content-Length y el servidor de back-end usa el encabezado Transfer-Encoding.
- TE.CL: el servidor front-end usa el encabezado Transfer-Encoding y el servidor back-end usa el encabezado Content-Length.
- TE.TE: los servidores front-end y back-end admiten el encabezado Transfer-Encoding, pero se puede inducir a uno de los servidores a no procesarlo ofuscando el encabezado de alguna manera.
¿Cómo prevenir?
Para evitar vulnerabilidades de HTTP Request Smuggling, recomendamos las siguientes medidas:
- Utilizar HTTP/2 de extremo a extremo y deshabilite HTTP si es posible. HTTP/2 utiliza un mecanismo robusto para determinar la longitud de las solicitudes y, cuando se utiliza de un extremo a otro, está inherentemente protegido contra el HTTP Request Smuggling. Si no puede evitar el uso de HTTP, asegúrese de validar la solicitud reescrita con la especificación HTTP/1.
- Haga que el servidor de front-end normalice las solicitudes ambiguas y haga que el servidor de back-end rechace las que aún sean ambiguas, cerrando la conexión TCP en el proceso.
- Nunca asuma que las solicitudes no tendrán cuerpo. Esta es la causa fundamental de las vulnerabilidades de desincronización tanto de CL.0 como del lado del cliente.
- De forma predeterminada, se debe descartar la conexión si se activan excepciones a nivel de servidor al manejar solicitudes.
- Si dirige el tráfico a través de un proxy, asegúrese de que HTTP/2 ascendente esté habilitado si es posible.
Conclusión
Para defenderte del HTTP Request Smuggling, necesitas comprender a fondo cómo interactúan los servidores front-end y back-end, además de mantener una constante vigilancia sobre las prácticas de codificación segura. En Hackmetrix, destacamos por simular ataques cibernéticos personalizados, incluyendo pruebas de penetración que revelan vulnerabilidades como el HTTP Request Smuggling. Nuestra Plataforma de Seguridad y Cumplimiento, apoyada por un equipo experto en Hacking Ético, asegura que puedas identificar y remediar estas brechas de seguridad antes de que sean explotadas. Si te preocupa la seguridad de tu sitio web y quieres estar seguro contra amenazas ¡Contáctanos!
