HTTP Request Smuggling: qué es, ataques y defensa

El HTTP request smuggling es una técnica que aprovecha que dos servidores en cadena (un front-end y un back-end) interpretan de forma distinta dónde termina una petición HTTP. Cuando el proxy delantero y el servidor de aplicación no se ponen de acuerdo sobre la longitud del cuerpo, un atacante puede "colar" una petición dentro de otra, envenenar la conexión reutilizada y afectar a las peticiones de otros usuarios. El resultado va desde saltarse controles perimetrales hasta secuestrar sesiones ajenas, sin explotar ningún fallo de memoria: todo el ataque vive en la ambigüedad del propio protocolo.

Esta guía cubre por qué se produce la desincronización front-end/back-end, las variantes clásicas (CL.TE, TE.CL y TE.TE), el smuggling moderno sobre HTTP/2 y downgrade, cómo se detecta con Burp Suite y qué defensas por normalización cierran realmente el vector.

Lo esencial. El request smuggling no es un bug de un servidor concreto, es un desacuerdo de parsing entre dos servidores que comparten una conexión TCP. La causa raíz suele ser el manejo divergente de las cabeceras Content-Length y Transfer-Encoding. Las defensas efectivas son normalizar o rechazar peticiones ambiguas en el front-end, usar HTTP/2 de extremo a extremo sin downgrade y, como último recurso, deshabilitar la reutilización de conexión hacia el back-end.

Qué es el HTTP request smuggling

Casi ninguna aplicación moderna atiende directamente al usuario. Entre el cliente y el servidor de aplicación hay una cadena: balanceadores de carga, CDN, proxies inversos, WAF y gateways. Para ser eficientes, esos componentes reutilizan conexiones TCP hacia el back-end: varias peticiones de distintos usuarios viajan por la misma conexión, una detrás de otra.

El problema aparece cuando el front-end y el back-end delimitan las peticiones de forma diferente. HTTP/1.1 ofrece dos mecanismos para indicar la longitud del cuerpo:

• Content-Length: declara el número exacto de bytes del cuerpo.
• Transfer-Encoding: chunked: el cuerpo llega en fragmentos, cada uno precedido por su tamaño en hexadecimal, y termina con un fragmento de tamaño cero.

La especificación (RFC 9112, antes RFC 7230) es clara: si una petición incluye ambas cabeceras, se debe ignorar Content-Length o rechazar la petición. En la práctica muchos servidores no siguen la regla igual. Si el front-end respeta Content-Length y el back-end respeta Transfer-Encoding (o al revés), el atacante controla dónde cree cada servidor que acaba la petición. Ese descuadre es la desincronización, y lo que queda "sobrante" para uno de los servidores se convierte en el prefijo de la siguiente petición de la cola.

Cómo se produce la desincronización front-end/back-end

Imaginemos que el atacante envía una única petición con cabeceras contradictorias. El front-end la lee entera según su criterio y la reenvía por la conexión persistente al back-end. El back-end, que aplica el otro criterio, considera que parte de esos bytes son una petición nueva e independiente. Esos bytes quedan "en espera" al principio del buffer de la conexión.

Cuando otro usuario legítimo envía su petición por esa misma conexión reutilizada, el back-end la concatena detrás del fragmento colado. El atacante ha antepuesto su carga a la petición de la víctima y puede redirigirla a otro endpoint, capturar su cookie de sesión o forzar una respuesta envenenada, sin necesidad de credenciales.

Hacen falta dos condiciones: una cadena de al menos dos servidores con parsing divergente y una conexión al back-end que se reutilice entre peticiones. Por eso la técnica es especialmente relevante en arquitecturas con CDN, reverse proxy y microservicios.

Variantes clásicas: CL.TE, TE.CL y TE.TE

La nomenclatura describe qué cabecera prioriza cada servidor. La primera sigla es el front-end, la segunda el back-end.

CL.TE

El front-end usa Content-Length y el back-end usa Transfer-Encoding. El atacante declara un Content-Length que abarca solo el principio del cuerpo. El front-end reenvía todo, pero el back-end, al procesar el chunked, cierra la petición en el fragmento de tamaño cero y trata el resto como una petición nueva. Es la variante más habitual contra front-ends que no soportan chunked.

TE.CL

El front-end usa Transfer-Encoding y el back-end usa Content-Length. Aquí el atacante construye un cuerpo chunked donde el front-end ve una petición completa, mientras el back-end, guiado por un Content-Length corto, corta antes y deja el resto del chunk como inicio de la siguiente petición. Requiere ajustar con cuidado los tamaños en hexadecimal.

TE.TE

Ambos servidores soportan Transfer-Encoding, pero uno de ellos puede ser inducido a ignorarlo mediante ofuscación de la cabecera. Variantes como Transfer-Encoding: xchunked, un espacio antes de los dos puntos, Transfer-Encoding : chunked, saltos de línea incrustados o una cabecera duplicada logran que un servidor la procese y el otro no. Al desactivar la interpretación en uno de los dos, TE.TE degenera en un caso CL.TE o TE.CL.

HTTP/2 downgrade y desincronización moderna

HTTP/2 elimina en teoría el problema porque usa una trama con longitud explícita en lugar de cabeceras textuales ambiguas. El riesgo reaparece cuando el front-end habla HTTP/2 con el cliente pero traduce (downgrade) a HTTP/1.1 hacia el back-end. En esa reescritura, valores maliciosos incrustados en las pseudo-cabeceras o en cabeceras como content-length y transfer-encoding se convierten en peticiones HTTP/1.1 ambiguas aguas abajo. James Kettle documentó estas familias en "HTTP/2: The Sequel is Always Worse" (Black Hat 2021), incluyendo H2.CL y H2.TE, donde la longitud declarada en la trama HTTP/2 no coincide con la que ve el back-end tras el downgrade.

En los últimos años han surgido variantes que no necesitan una cabecera de longitud contradictoria clásica:

• CL.0: el back-end ignora por completo el Content-Length en ciertas rutas (por ejemplo, ficheros estáticos o redirecciones), de modo que el cuerpo se interpreta como una petición independiente.
• Client-side desync (0.CL) y browser-powered request smuggling: técnicas presentadas por Kettle en 2022 que permiten disparar la desincronización desde el navegador de la víctima, ampliando el impacto a objetivos que solo hablan HTTP/2 de cara al cliente.
• Request tunnelling: cuando la conexión no se comparte entre usuarios pero sí se puede encadenar una segunda petición sobre la primera para leer respuestas ocultas.

Impacto real de un ataque de request smuggling

El smuggling rara vez es el objetivo final: es el pivote que habilita otros ataques.

• Bypass de controles perimetrales. La petición colada llega al back-end sin pasar por las comprobaciones que el front-end o el WAF aplican a las peticiones normales, dando acceso a endpoints internos o administrativos.
• Captura de peticiones de otros usuarios. Anteponiendo un cuerpo que almacena o refleja la siguiente petición, el atacante recupera cookies de sesión, tokens y cabeceras de autenticación de víctimas reales.
• Envenenamiento de caché web. Combinado con una caché intermedia, una respuesta manipulada se almacena y se sirve a todos los usuarios posteriores de esa URL.
• Escalada hacia otros vectores. Un smuggling puede encadenarse con SSRF para alcanzar servicios internos, o con redirecciones abiertas para robar credenciales. Como casi todo en ofensiva web, el impacto crítico surge del encadenamiento, no de un único fallo.

Detección con Burp Suite y otras herramientas

El request smuggling se detecta por comportamiento diferencial, no por firmas estáticas. Las dos señales principales son la temporización (una petición malformada provoca un retardo porque el back-end espera bytes que nunca llegan) y la respuesta diferencial (la petición del atacante afecta a una petición de seguimiento).

• HTTP Request Smuggler. La extensión de PortSwigger para Burp Suite, desarrollada a partir de la investigación de James Kettle, automatiza la detección por timing de CL.TE y TE.CL, ayuda a construir el ataque y valida la desincronización sin degradar el servicio para usuarios reales.
• Turbo Intruder. Permite enviar peticiones concurrentes por la misma conexión para confirmar que una petición influye en otra, imprescindible al validar el impacto.
• smuggler.py. Herramienta en Python que prueba de forma sistemática decenas de mutaciones de cabeceras Transfer-Encoding para descubrir qué ofuscación acepta cada extremo.
• h2csmuggler. Orientada a abusar de upgrades a HTTP/2 sobre texto claro (h2c) que a veces permiten tunelizar peticiones hacia el back-end.

El proceso responsable es siempre en entornos autorizados y con técnicas de baja huella: las pruebas de smuggling pueden desestabilizar peticiones de terceros, por lo que se ejecutan con ventanas acordadas y priorizando la detección por temporización sobre la explotación destructiva.

CVEs y casos reales

El smuggling no es teórico ni exclusivo de software a medida. Ha afectado a servidores de referencia:

• CVE-2019-20372 en nginx: la directiva error_page permitía inyectar una petición en el flujo bajo ciertas configuraciones.
• CVE-2021-33193 en Apache HTTP Server (mod_http2): peticiones HTTP/2 manipuladas provocaban smuggling al reenviarse.
• CVE-2023-25690 en Apache (mod_proxy con reescrituras RewriteRule/ProxyPassMatch mal formadas): permitía dividir la petición y envenenar la caché o saltar controles de acceso.
• Runtimes como Node.js han publicado múltiples avisos ligados al parser llhttp por interpretación laxa de cabeceras de longitud.

El patrón se repite: cuando dos implementaciones distintas comparten una petición, cualquier desviación respecto al RFC se convierte en superficie de ataque.

Defensas: normalización y arquitectura

Las contramedidas eficaces actúan en el punto donde nace la ambigüedad.

• Normalizar o rechazar en el front-end. El borde debe rechazar toda petición que incluya a la vez Content-Length y Transfer-Encoding, o cualquier Transfer-Encoding ofuscado o duplicado, tal como recomienda el RFC 9112. Si el front-end normaliza la petición antes de reenviarla, el back-end recibe algo inequívoco.
• HTTP/2 de extremo a extremo sin downgrade. Mantener HTTP/2 también entre el front-end y el back-end elimina la reescritura a HTTP/1.1 que habilita H2.CL y H2.TE. Si el downgrade es inevitable, hay que validar estrictamente las cabeceras reescritas.
• Front-end y back-end coherentes. Usar el mismo software y versión, o al menos servidores que apliquen idéntico criterio de parsing, reduce la probabilidad de desacuerdo.
• Deshabilitar la reutilización de conexión hacia el back-end. Es la mitigación de fuerza bruta: sin conexión compartida no hay petición de víctima que contaminar. Tiene coste de rendimiento, por lo que se reserva como red de seguridad.
• Actualizar la cadena completa. Proxies, CDN, balanceadores y servidores de aplicación deben estar parcheados frente a los CVE conocidos.
• Pruebas periódicas. Incluir el smuggling en el alcance del pentesting de aplicaciones web garantiza que los cambios de arquitectura no reintroduzcan el vector.

Preguntas frecuentes

¿El HTTP request smuggling afecta también a HTTP/2?

Sí, aunque de forma indirecta. HTTP/2 usa longitudes de trama explícitas y no debería ser ambiguo, pero la mayoría de despliegues hacen downgrade a HTTP/1.1 hacia el back-end. En ese punto reaparecen las variantes H2.CL y H2.TE. La defensa robusta es mantener HTTP/2 de extremo a extremo o validar con rigor la reescritura.

¿Un WAF protege frente al request smuggling?

Solo parcialmente. Un WAF basado en firmas puede bloquear payloads conocidos, pero la esencia del ataque es precisamente colar una petición que el WAF no inspecciona con el mismo criterio que el back-end. Peor aún, un WAF y el servidor de aplicación pueden formar la propia pareja desincronizada. La protección real es la normalización de peticiones, no la detección de patrones.

¿Qué diferencia hay entre CL.TE y TE.CL?

La diferencia es qué cabecera prioriza cada servidor. En CL.TE el front-end respeta Content-Length y el back-end Transfer-Encoding. En TE.CL es al revés. El sentido de la desincronización cambia la forma de construir el cuerpo chunked y qué fragmento queda "colado" para la siguiente petición.

¿Cómo se detecta sin romper el servicio en producción?

La detección responsable se basa en temporización, no en explotación. La extensión HTTP Request Smuggler de Burp envía peticiones que, si hay desincronización, provocan un retardo medible sin envenenar peticiones reales. Solo tras confirmar el vector en un entorno controlado se valida el impacto, y siempre dentro de una ventana acordada.

¿Es un fallo de la aplicación o de la infraestructura?

Casi siempre de la infraestructura y su configuración: la vulnerabilidad vive en la cadena de proxies y servidores, no en el código de negocio. Por eso el equipo de plataforma es clave para remediarla, aunque el hallazgo surja durante una auditoría de la aplicación.

Recursos relacionados

• Pentesting de aplicaciones web: guía completa
• Qué es Burp Suite y para qué sirve en pentesting web
• Qué es SSRF (Server Side Request Forgery)
• Qué es un WAF (Web Application Firewall)
• 5 vulnerabilidades web más comunes en 2025

Cómo trabajamos el request smuggling en Secra

En Secra incluimos el HTTP request smuggling dentro del alcance de las auditorías web sobre OWASP WSTG, con detección por temporización, validación controlada del impacto y recomendaciones concretas de normalización para el equipo de plataforma. El objetivo no es solo confirmar la desincronización, sino documentar la cadena de servidores responsable y verificar que la mitigación aplicada cierra el vector sin degradar el rendimiento.

Si tu organización opera detrás de CDN, reverse proxy o gateways y quieres validar que la cadena no es vulnerable a smuggling, puedes escribirnos a través de contacto o consultar el servicio de auditoría web y móvil.