Vulnerabilidad HTTP request smuggling
www.onlinetis.com
La vulnerabilidad de HTTP Request Smuggling ("contrabando de peticiones HTTP") es una técnica avanzada de ciberataque que explota las diferencias en la forma en que los servidores web y los servidores proxy (como load balancers, firewalls o caches) interpretan el límite de una petición HTTP.
Un atacante envía una sola petición HTTP, pero la construye de tal manera que el servidor proxy la interpreta como una petición, mientras que el servidor de backend (el servidor web final) la interpreta como dos. Esto permite al atacante "esconder" una segunda petición maliciosa al principio de una cola, esperando a ser procesada por el siguiente usuario.
¿Cómo funciona un ataque de Request Smuggling?
El ataque se basa en dos encabezados HTTP que definen la longitud del cuerpo de la petición: Content-Length
y Transfer-Encoding
.
Content-Length
(CL): Define el número exacto de bytes del cuerpo de la petición.Transfer-Encoding: chunked
(TE): Indica que el cuerpo está dividido en fragmentos (chunks), cada uno con su tamaño precediendo al contenido. El final se marca con un fragmento de tamaño cero (0
).
El problema ocurre cuando el proxy y el servidor de backend no están sincronizados en su interpretación de estos encabezados. Hay tres escenarios principales:
CL.TE: El proxy utiliza
Content-Length
, pero el servidor de backend utilizaTransfer-Encoding
.TE.CL: El proxy utiliza
Transfer-Encoding
, pero el servidor de backend utilizaContent-Length
.TE.TE: Tanto el proxy como el servidor de backend utilizan
Transfer-Encoding
, pero uno de ellos puede ser engañado para no reconocer el encabezadoTransfer-Encoding
debido a una ofuscación (por ejemplo,Transfer-Encoding: chunked
).
Ejemplo (Escenario CL.TE) 💥
Un atacante envía la siguiente petición a un servidor proxy:
POST /search HTTP/1.1
Host: ejemplo.com
Content-Length: 13
Transfer-Encoding: chunked
5
GET /private
0
El servidor proxy lee el encabezado
Content-Length: 13
y envía los 13 bytes completos al servidor de backend.Contenido enviado:
5\r\nGET /private\r\n0
(13 bytes)
El servidor de backend ignora
Content-Length
y leeTransfer-Encoding: chunked
.Lee el primer fragmento,
5
, y consume los 5 bytes siguientes:GET /
.El resto del contenido (
private\r\n0
) queda sin procesar.
El servidor de backend espera una segunda petición, pero el contenido restante (
private\r\n0
) es malinterpretado como el inicio de la siguiente petición. Cuando un usuario legítimo envía su petición, esta se unirá al fragmento sobrante, formando una petición completamente nueva que el atacante ha "escondido".
¿Qué se puede lograr con Request Smuggling?
Evadir firewalls: El atacante puede eludir reglas de seguridad o filtros de entrada al disfrazar su ataque dentro de la petición HTTP.
Acceder a APIs internas: Se pueden utilizar para acceder a servicios internos o de administración que no deberían ser accesibles desde internet.
Secuestro de sesión: Al manipular las peticiones, un atacante puede robar las cookies de otros usuarios.
Redirecciones maliciosas: Puede redirigir peticiones de usuarios legítimos a sitios de phishing.
Prevención
La mitigación de esta vulnerabilidad se centra en asegurar que todos los componentes de la cadena de servidores (desde el cliente hasta el servidor final) interpreten las peticiones HTTP de la misma manera.
Deshabilitar la reutilización de conexiones: Esto asegura que cada petición tenga su propia conexión, impidiendo que los fragmentos de una petición se mezclen con los de otra.
Usar protocolos modernos: Utilizar HTTP/2, que resuelve este problema de manera nativa al no usar los encabezados
Content-Length
yTransfer-Encoding
.Normalización de encabezados: Si se utiliza HTTP/1.1, configurar el servidor proxy para que normalice los encabezados de forma estricta, por ejemplo, eliminando siempre el encabezado
Transfer-Encoding
cuando también esté presenteContent-Length
.