Hoy te voy a mostrar cómo los atacantes pueden
“colar” peticiones maliciosas dentro de otras aparentemente legítimas, aprovechando malentendidos entre servidores.
Un ataque invisible. Sutil. Pero devastador.En este artículo voy a enseñarte la vulnerabilidad
HTTP Request Smuggling,
cómo funciona y qué impacto tiene. Además,
al final del artículo voy a enseñarte a
explotarla en un laboratorio práctico.Lo primero es saber en qué consiste.
Qué es la vulnerabilidad HTTP request smuggling
La traducción de esta vulnerabilidad es
contrabando de solicitudes HTTP, así que ya podemos entender más o menos su funcionamiento. Cuando hablamos de
solicitudes HTTP, nos referimos a
solicitudes cliente-servidor. Es decir, nuestro navegador solicita visualizar una página al servidor.Teniendo esto claro, la vulnerabilidad consiste en
insertar una petición maliciosa dentro de una petición legítima, que es procesada sin problema por el servidor backend.Aquí se produce el
“contrabando”, porque esa solicitud maliciosa
pasa totalmente desapercibida por el servidor. Prácticamente se
envía una doble petición, una dentro de la otra.Bien, ¿y cómo funciona la vulnerabilidad y por qué ocurre?
Cómo funciona la vulnerabilidad HTTP request smuggling
Los responsables de este ataque son dos
cabeceras de la petición HTTP:
Content-Length y
Transfer-Encoding. Estas cabeceras son utilizadas para conocer
cuándo una petición finaliza.Cuando el
frontend (es decir, el frontal, la parte visible de la web) envía una solicitud al
backend, envía múltiples solicitudes paralelas de otros usuarios al mismo tiempo. Estas solicitudes se envían a través de la misma red del backend.Por lo tanto, es importante que tanto el front como el back sepan
dónde termina una solicitud y dónde empieza otra. De lo contrario, un atacante podría enviar una doble solicitud, crear
ambigüedad en los sistemas front y back, y estos los interpretarían de forma diferente.Es decir, que esta técnica se basa en
desincronizar la forma en que un servidor frontend y un backend procesan las solicitudes HTTP.Por ejemplo, el servidor frontal puede usar
Content-Length como referencia para saber dónde termina la petición, mientras que el backend puede usar
Transfer-Encoding: chunked.Si se manipulan adecuadamente estos encabezados, se puede lograr que el backend
procese una segunda petición que no fue visible para el frontend.El
Content-Length especifica la
longitud de la solicitud en bytes.Por ejemplo:
Content-Length: 500El
Transfer-Encoding utiliza
codificación fragmentada en bytes hexadecimales. El mensaje termina si el tamaño del fragmento es de
0 bytes.Por ejemplo, si quisiera enviar la palabra
«rinku» usando
Transfer-Encoding: chunked, donde el cuerpo del mensaje se divide en bloques (chunks), se vería así:
5\\r\\n
rinku\\r\\n
0\\r\\n
\\r\\n
Tipos de HTTP Request Smuggling
Podemos encontrarnos con los siguientes tipos:
- CL-TE: Front-end utiliza
Content-Length y back-end Transfer-Encoding - TE-CL: Front-end utiliza
Transfer-Encoding y back-end Content-Length - TE-TE: Se utilizan dos cabeceras Transfer-Encoding pero se puede convencer a uno de los servidores de no procesarlo ofuscando el encabezado de distintas formas manera.
- CL-CL: Y por último, aunque no es muy común, utilizar dos
Content-Length, haciendo que el servidor únicamente tome uno de los encabezados como válido y permita la doble petición.
Qué impacto tiene la vulnerabilidad
El impacto de esta vulnerabilidad es
alto y puede ser crítico dependiendo de lo que el atacante pueda hacer tras el envío de la doble petición. algunos ejemplos son:
1. Secuestro de sesión (Session Hijacking)
El atacante puede
inyectar una solicitud HTTP en la misma conexión TCP que usa un usuario legítimo. Si la víctima realiza una solicitud después del atacante, es posible que esa solicitud se combine con una solicitud «smuggled» del atacante, lo que puede permitir:
- Leer la respuesta de la víctima.
- Robar cookies o tokens de sesión.
- Tomar control de la sesión si el backend asocia esa conexión a un usuario autenticado.
2. Bypass de controles de acceso
Al realizar una petición maliciosa dentro de una legítima es posible burlar firewalls o WAFs que solo analizan la primera petición. Esto puede llevar a la
ejecución de acciones no autorizadas, como acceder a recursos internos.
3. SSRF (Server Side Request Forgery)
Si el servidor backend puede emitir solicitudes HTTP (por ejemplo, para integraciones con APIs externas), es posible
inyectar solicitudes que apunten a recursos internos como:
Esto puede derivar en
exfiltración de datos internos o
escalada de privilegios.
4. Ataques de desincronización
Cuando el backend procesa una petición smuggled, la respuesta puede quedar desincronizada respecto al frontend. Esto permite:
- Inyectar respuestas personalizadas en la conexión del usuario.
- Mostrar contenido falso (phishing desde un dominio legítimo).
- Ejecutar XSS incluso en páginas donde no es posible por vías tradicionales.
Como te podrás imaginar, esta vulnerabilidad es la puerta de entrada a muchas opciones y es por eso que en programas de
bug bounty se pagan muy bien.
Cómo prevenir la vulnerabilidad HTTP request smuggling
Llegados a este punto, para prevenir el HRS hay que llevar a cabo buenas prácticas como:
- Mantener consistencia en el uso de los encabezados. Tanto en el front-end como el back-end.
- Utilizar HTTP/2 y deshabilitar HTTP siempre que sea posible.
- O desactivar transfer-encoding si no es necesario. Si la aplicación no necesita recibir peticiones con
chunked, desactivar esta funcionalidad puede reducir el riesgo.
Cómo se explota la vulnerabilidad HTTP request smuggling
Ir al contenido
