La comunidad
Dentro se pregunta, se enseña lo que se ha encontrado y se resuelve en grupo lo que atascaría a cualquiera solo. Se entra gratis: sin cuenta, sin plan y sin dejar el correo.
Es gratis y abierto. No hace falta tener cuenta en BBLABS para entrar.
Qué es el HTTP Request Smuggling, por qué ocurre, sus variantes CL.TE, TE.CL y TE.TE, cómo detectarlo con técnicas de timing y diferenciales, su impacto (bypass de controles, envenenamiento de caché, robo de peticiones) y cómo probarlo con la extensión HTTP Request Smuggler de Burp.
Gorka El Bochi
Fundador de BBLABS
Deja de leer sobre bugs y empieza a cazarlos
Sin tarjeta · Academy gratis · cancela cuando quieras
Respuesta rápida: El HTTP Request Smuggling es un ataque que aprovecha que dos servidores encadenados (un front-end y un back-end) interpretan de forma distinta dónde acaba una petición HTTP. Manipulando las cabeceras
Content-LengthyTransfer-Encoding"cuelas" parte de una petición que el back-end atribuye a la siguiente, permitiendo saltarte controles, envenenar la caché o robar peticiones de otros usuarios.
En la web moderna, tu petición casi nunca llega directa al servidor de aplicación. Pasa por una cadena: un proxy inverso, un CDN o un balanceador (el front-end) reenvía las peticiones a uno o varios servidores de aplicación (el back-end), reutilizando la misma conexión para varias peticiones.
El problema aparece cuando el front-end y el back-end discrepan sobre dónde termina una petición. El HTTP permite indicar el fin del cuerpo de dos maneras: con la cabecera Content-Length (cuántos bytes tiene el cuerpo) o con Transfer-Encoding: chunked (el cuerpo se envía por trozos y acaba con un chunk de tamaño cero). Si uno de los servidores hace caso a una cabecera y el otro a la otra, un atacante puede construir una petición ambigua donde parte de sus bytes se interpreta como el principio de la siguiente petición. Eso es el smuggling: contrabandear una petición dentro de otra.
Es una vulnerabilidad de gama alta que suele puntuar como severidad alta o crítica. Su teoría, junto con otras técnicas complejas, la tienes en Academy › Avanzado.
La raíz está en dos decisiones de diseño de la web moderna que, combinadas, abren la puerta:
Transfer-Encoding debe tener prioridad sobre Content-Length, y que una petición con las dos cabeceras es ambigua y debería rechazarse. Pero en la práctica, distintos servidores (Nginx, Apache, IIS, CDNs, balanceadores) han implementado esto de formas ligeramente distintas durante años. Esa inconsistencia es la grieta.Cuando un atacante manda ambas cabeceras a la vez, o una Transfer-Encoding ofuscada, apuesta a que el front-end y el back-end las traten distinto. Si acierta, desincroniza la conexión. Por eso la corrección de fondo pasa por normalizar cómo se parsean estas cabeceras en toda la cadena.
La notación describe qué cabecera prioriza cada servidor. El primer término es el front-end; el segundo, el back-end.
El front-end usa Content-Length y el back-end usa Transfer-Encoding. El front reenvía lo que cree que es una petición según su longitud, pero el back la parsea por chunks y "sobra" contenido que trata como el inicio de la siguiente petición.
POST / HTTP/1.1
Host: target.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
El front-end, guiándose por Content-Length: 13, envía todo el bloque. El back-end, guiándose por Transfer-Encoding: chunked, ve el 0 como fin del cuerpo y trata SMUGGLED como el comienzo de la siguiente petición.
Al revés: el front-end usa Transfer-Encoding y el back-end usa Content-Length. El bloque contrabandeado se coloca dentro de un chunk, y el back-end —que solo mira la longitud— deja parte fuera para la petición siguiente.
Ambos soportan Transfer-Encoding, pero uno de los dos puede ser inducido a ignorarla ofuscando la cabecera (por ejemplo, Transfer-Encoding : chunked con un espacio raro, mayúsculas alteradas o valores duplicados). Al conseguir que uno la descarte, el escenario degenera en un CL.TE o TE.CL. La clave aquí es la ofuscación de la cabecera. Variantes típicas de ofuscación que un servidor puede procesar y otro ignorar:
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: chunked
Transfer-Encoding: identity
X: X[\n]Transfer-Encoding: chunked
Cada línea explota un detalle de parseo distinto (un espacio antes de los dos puntos, un valor duplicado, un prefijo raro). El objetivo es siempre el mismo: que uno de los dos servidores respete la cabecera y el otro la descarte.
Detectarlo sin romper el servicio es un arte. Dos enfoques principales:
1. Técnica de timing (temporización). Envías una petición diseñada para que, si hay desincronización, el back-end espere más bytes que nunca llegan y provoque un retardo. Un tiempo de respuesta anómalo (varios segundos frente a milisegundos) delata la vulnerabilidad. Es la técnica más segura para una primera detección porque no envenena a otros usuarios.
2. Técnica diferencial (confirmación). Envías dos peticiones seguidas: la primera contrabandea un prefijo que altera la respuesta de la segunda. Si la segunda petición devuelve algo distinto de lo normal (un error, otra ruta), confirmas la desincronización. Aquí ya hay que tener cuidado: mal hecho, puedes afectar a peticiones de usuarios reales.
Regla de oro ética: en un programa de bug bounty, detecta con timing, confirma con el mínimo impacto posible y nunca lances pruebas que envenenen respuestas de otros usuarios más allá de lo estrictamente necesario para demostrar el fallo. Documenta y para.
47 comprobaciones ordenadas por coste: primero lo que te puede meter en un lío, luego lo barato, y al final lo caro — que es donde están los bounties grandes. Te la mando al correo ahora mismo.
Te das de baja en un clic, desde cualquier correo.
El smuggling es peligroso porque lo que contrabandeas afecta a la conexión compartida, no solo a ti:
Esa capacidad de afectar a terceros es lo que sube el severity: no es un fallo que solo te afecta a ti.
La herramienta de referencia es HTTP Request Smuggler, la extensión de Burp Suite creada por James Kettle (el investigador que popularizó estas técnicas modernas). Se instala desde el BApp Store y automatiza gran parte del trabajo:
Trabajar el smuggling a mano exige entender muy bien HTTP a bajo nivel; la extensión reduce el error, pero el criterio sobre qué es seguro probar lo pones tú.
La investigación reciente ha mostrado que el problema no murió con HTTP/2. Cuando un front-end habla HTTP/2 con el cliente pero rebaja (downgrade) la conexión a HTTP/1.1 para hablar con el back-end, puede reintroducir la ambigüedad de las cabeceras al hacer esa traducción. Son las variantes de "H2.CL" y "H2.TE": el front-end HTTP/2 genera cabeceras Content-Length o Transfer-Encoding inconsistentes al convertir. Es terreno avanzado, pero conviene saber que la superficie sigue viva incluso en infraestructuras modernas.
Del lado defensivo, las mitigaciones reales son claras:
Content-Length y Transfer-Encoding, en lugar de intentar interpretarla.Como hunter, entender la defensa mejora tu reporte: puedes explicar no solo el fallo, sino la corrección concreta que el equipo debería aplicar.
¿Es peligroso probar request smuggling en un objetivo real?
Puede serlo. Las pruebas diferenciales pueden afectar a peticiones de otros usuarios. Detecta con la técnica de timing (segura), confirma con el mínimo impacto y para en cuanto lo demuestres. Nunca envenenes respuestas de usuarios reales más allá de lo imprescindible.
¿Sirve de algo si el sitio solo tiene un servidor?
El smuggling necesita una cadena de al menos dos sistemas que parseen HTTP (proxy/CDN/balanceador + back-end). Si la petición llega directa a un único servidor sin intermediarios, no hay dos interpretaciones que enfrentar.
¿Qué severidad tiene un request smuggling?
Normalmente alta o crítica, porque permite afectar a otros usuarios: robar sus peticiones, saltarse controles del front-end o envenenar la caché. El impacto exacto depende de qué puedas encadenar.
¿Necesito la extensión de Burp o puedo hacerlo a mano?
Se puede a mano si dominas HTTP a bajo nivel, pero HTTP Request Smuggler reduce muchísimo el margen de error en la detección y la construcción del ataque. Para empezar, la extensión es muy recomendable.
Es una técnica avanzada: no es lo primero que atacas de recién llegado. La ruta razonable es dominar antes las familias del OWASP Top 10 a mano, entender bien el ciclo petición/respuesta con un proxy, y luego subir a técnicas de desincronización como esta.
Para llegar preparado, entrena la explotación web con labs que replican reportes reales y estudia la teoría avanzada en Academy › Avanzado. Cuando el ciclo HTTP te sea transparente, el smuggling deja de parecer magia y se convierte en una desincronización que sabes leer, detectar y demostrar con responsabilidad.
hunters entrenando
labs de hackeos reales
completaciones
pagados por estos bugs
Crea tu cuenta gratis y practica sobre labs basados en hackeos reales que pagaron miles de euros. La Academy es gratis para siempre.
Sin tarjeta · Academy gratis · cancela cuando quieras
Aprende a identificar y explotar vulnerabilidades IDOR (Insecure Direct Object Reference) en aplicaciones web. Desde los conceptos básicos hasta la escritura de reportes efectivos.
Explora las técnicas más comunes para atacar implementaciones inseguras de JSON Web Tokens: desde el algoritmo none hasta inyección de JKU/JWK.
Aprende a escalar vulnerabilidades SSRF desde una severidad baja hasta un impacto crítico. Técnicas de explotación, bypass de filtros y cadenas de ataque en entornos cloud.