HTTP Request Smuggling: Hablar dos idiomas para evadir la seguridad 🗣️

El HTTP request smuggling representa una de las vulnerabilidades de seguridad web más sofisticadas y peligrosas en las infraestructuras de aplicaciones modernas. Esta técnica de ataque explota desacuerdos fundamentales entre proxies web y servidores backend sobre dónde termina una solicitud HTTP y comienza otra, permitiendo a los atacantes inyectar solicitudes maliciosas, evadir controles de seguridad, envenenar caches e incluso secuestrar sesiones legítimas.

Entendiendo la base: Cómo HTTP define los límites de las solicitudes

Para comprender el HTTP request smuggling, primero debes entender cómo HTTP comunica la longitud de las solicitudes. El protocolo HTTP ofrece dos mecanismos principales para especificar dónde termina el cuerpo de una solicitud: la cabecera Content-Length y la cabecera Transfer-Encoding.

La cabecera Content-Length declara explícitamente el tamaño del cuerpo del mensaje en bytes. Por ejemplo, una cabecera que diga “Content-Length: 15” indica al servidor receptor que lea exactamente 15 bytes de datos después de las cabeceras.

La cabecera Transfer-Encoding, especialmente cuando está configurada como “chunked”, indica que el cuerpo del mensaje se envía en múltiples fragmentos, cada uno precedido por su tamaño en hexadecimal. Un tamaño de fragmento de cero señala el fin del mensaje.

Según las especificaciones HTTP, cuando ambas cabeceras aparecen en la misma solicitud, los servidores deberían rechazarla o priorizar Transfer-Encoding. Sin embargo, las implementaciones en el mundo real a menudo se desvían de estos estándares, creando inconsistencias explotables.

La vulnerabilidad principal: Cuando los sistemas no están de acuerdo

Las vulnerabilidades de HTTP request smuggling surgen cuando los servidores front-end (como balanceadores de carga, proxies reversos o CDN) y los servidores de aplicaciones back-end interpretan de manera diferente la misma solicitud HTTP. Las arquitecturas web modernas suelen encadenar múltiples componentes de procesamiento HTTP, y cada uno debe analizar las solicitudes de forma independiente.

Cuando el front-end y el back-end no están de acuerdo sobre los límites de la solicitud, un atacante puede crear solicitudes ambiguas que parecen una sola solicitud completa para el front-end, pero como dos solicitudes separadas para el back-end. Esta desincronización crea una ventana donde el contenido malicioso puede ser “smuggled” más allá de los controles de seguridad.

Vulnerabilidades recientes han demostrado que esta amenaza sigue activa y en evolución. En marzo de 2025, investigadores de seguridad descubrieron una vulnerabilidad de request smuggling en la infraestructura de Akamai que involucraba solicitudes OPTIONS con cabeceras Expect y plegado de línea obsoleto. De manera similar, en abril de 2025, Cloudflare abordó una vulnerabilidad crítica de smuggling en su componente proxy Pingora que podría permitir a los atacantes modificar cabeceras y URLs enviadas a los orígenes de clientes.

Variantes del ataque: Los diferentes idiomas del smuggling

Investigadores de seguridad han identificado varias variantes principales de HTTP request smuggling, cada una explotando diferentes discrepancias en el análisis:

CL.TE (Content-Length a Transfer-Encoding)

En esta variante, el servidor front-end procesa solicitudes basadas en la cabecera Content-Length, mientras que el back-end prioriza Transfer-Encoding. Un atacante envía una solicitud con ambas cabeceras, causando que el front-end reenvíe lo que cree que es una solicitud completa. Sin embargo, el back-end interpreta solo parte de estos datos como la primera solicitud y trata el resto como el inicio de una segunda.

TE.CL (Transfer-Encoding a Content-Length)

Este ataque invierte el escenario anterior. El front-end procesa Transfer-Encoding, mientras que el back-end se basa en Content-Length. El atacante declara un fragmento corto que el front-end acepta como completo, pero incluye contenido adicional que el back-end trata como una solicitud separada.

TE.TE (Obfuscación con Transfer-Encoding)

Ambos servidores soportan Transfer-Encoding, pero un atacante puede inducir a uno de ellos a ignorarlo mediante técnicas de ofuscación. Esto puede involucrar espacios inusuales, mayúsculas o caracteres ocultos que causan inconsistencias en el análisis.

TE.0 y CL.0 (Variantes de longitud cero)

Investigaciones en 2024 descubrieron nuevas variantes donde el servidor back-end ignora completamente Transfer-Encoding o Content-Length, tratando el cuerpo del mensaje como de longitud cero. Estas técnicas demostraron ser efectivas contra grandes proveedores de la nube, y los investigadores descubrieron una vulnerabilidad TE.0 que afectaba a miles de sitios web alojados en Google Cloud.

Escenarios de ataque devastadores

Evasión de controles de seguridad

El HTTP request smuggling es excelente para evadir medidas de seguridad front-end. Las organizaciones suelen implementar controles de acceso, verificaciones de autenticación y escaneo de seguridad en el perímetro. Cuando un atacante smuggles una solicitud, parece originarse de la infraestructura confiable del front-end, evadiendo estos mecanismos protectores.

Considera una aplicación que restringe funciones administrativas a solicitudes provenientes de localhost. Un atacante puede smuggle una solicitud con una cabecera Host modificada, haciendo que el back-end crea que la solicitud proviene localmente, mientras que el front-end la validó como legítima y externa.

Envenenamiento de cache

Los mecanismos de cache web almacenan respuestas para mejorar el rendimiento y reducir la carga del servidor. El HTTP request smuggling permite a los atacantes envenenar estos caches con contenido malicioso que luego se sirve a todos los usuarios que solicitan el recurso afectado.

En un escenario típico de envenenamiento de cache, un atacante smuggles una solicitud que hace que el servidor responda con contenido inesperado—quizás una redirección a un sitio malicioso. Si el cache del front-end interpreta esta respuesta como perteneciente a un recurso legítimo en cache, como un archivo JavaScript, almacena la respuesta maliciosa. Cada usuario posterior que solicite ese archivo JavaScript recibe el contenido envenenado, lo que potencialmente compromete sus sesiones mediante ataques de scripting entre sitios.

El impacto del envenenamiento de cache va más allá de usuarios individuales. Una vez que un cache está envenenado, el contenido malicioso se propaga a todos los usuarios que acceden a la URL afectada hasta que expira o los administradores lo invalidan manualmente. Esto lo convierte en un vector de denegación de servicio extremadamente potente o en un método para distribuir cargas útiles a gran escala.

Secuestro de solicitudes y robo de credenciales

Una de las aplicaciones más peligrosas del HTTP request smuggling consiste en capturar solicitudes de otros usuarios, incluyendo cookies de sesión y credenciales de autenticación. Este ataque explota la reutilización de conexiones en infraestructuras HTTP modernas.

Muchos sistemas web mantienen conexiones persistentes entre proxies front-end y servidores back-end para mejorar el rendimiento. Cuando un atacante logra smuggle una solicitud parcial, esta queda en cola en el servidor back-end. La siguiente solicitud legítima que llega por la misma conexión se añade a la solicitud smuggled como su “cuerpo”.

Los atacantes pueden crear la solicitud smuggled para incluir un campo de formulario que almacena este contenido añadido. Cuando posteriormente recuperan estos datos almacenados, obtienen la solicitud HTTP completa de otro usuario, incluyendo tokens de sesión, cabeceras de autenticación y datos sensibles del formulario. Esto básicamente permite al atacante hacerse pasar por cualquier usuario cuya solicitud quede atrapada en la trampa.

Impacto en el mundo real y descubrimientos recientes

La comunidad de seguridad continúa descubriendo vulnerabilidades de HTTP request smuggling en componentes de infraestructura importantes. Ejemplos recientes ilustran la amplitud de esta amenaza:

En 2024, investigadores identificaron vulnerabilidades en servidores web populares como gunicorn y webrick, demostrando que incluso proyectos de código abierto ampliamente utilizados siguen siendo susceptibles.

El descubrimiento en Google Cloud en 2024 reveló que miles de sitios web usando el Load Balancer de Google eran vulnerables a una variante TE.0 de smuggling. Los investigadores recibieron una recompensa de $8,500 tras que Google confirmó que ya habían corregido el problema tras un reporte de cliente.

Estos incidentes resaltan una realidad importante: las vulnerabilidades de HTTP request smuggling suelen afectar componentes de infraestructura en lugar del código de la aplicación. Esto significa que varias organizaciones se vuelven vulnerables simultáneamente cuando un proxy, balanceador de carga o CDN presenta una inconsistencia en el análisis.

Estrategias de detección y prevención

Para profesionales de seguridad

Detectar HTTP request smuggling requiere técnicas de prueba especializadas. Los investigadores de seguridad suelen usar métodos de detección basados en temporización, creando solicitudes ambiguas y midiendo retrasos en las respuestas. Cuando un servidor experimenta un timeout o retraso inusual, a menudo indica que está esperando datos adicionales debido a una desincronización.

Herramientas automatizadas como la extensión HTTP Request Smuggler de Burp Suite pueden probar sistemáticamente vulnerabilidades enviando solicitudes de sondeo y analizando patrones de respuesta. Sin embargo, las pruebas manuales siguen siendo valiosas para descubrir variantes nuevas que las herramientas automáticas puedan pasar por alto.

Para desarrolladores y equipos de operaciones

Prevenir HTTP request smuggling requiere abordar las inconsistencias fundamentales en el análisis entre sistemas:

Normalizar el manejo de solicitudes: Configurar todos los componentes de infraestructura para interpretar las cabeceras HTTP de manera coherente. La prevención más efectiva, aunque a menudo difícil en entornos heterogéneos con balanceadores de carga hardware y servidores de aplicaciones.

Desactivar funciones HTTP/1.1: Si no se requieren Transfer-Encoding y conexiones persistentes, desactivarlas elimina toda clase de ataques de smuggling. Sin embargo, esto puede afectar las optimizaciones de rendimiento.

Usar HTTP/2 de extremo a extremo: HTTP/2 usa un mecanismo de encuadre binario que elimina las ambigüedades inherentes en el análisis de solicitudes HTTP/1.1. Cuando tanto front-end como back-end comunican exclusivamente vía HTTP/2, la mayoría de las técnicas tradicionales de smuggling se vuelven imposibles.

Implementar validación estricta de solicitudes: Configurar los servidores front-end para rechazar solicitudes que contengan ambas cabeceras Content-Length y Transfer-Encoding, o cualquier solicitud con formato de cabecera inusual.

Desactivar la reutilización de conexiones: Si es técnicamente posible, impedir que el back-end reutilice conexiones entre diferentes clientes elimina completamente los ataques de secuestro de solicitudes, aunque sacrifica beneficios de rendimiento.

El panorama en evolución de amenazas

La investigación en HTTP request smuggling continúa avanzando, con profesionales de seguridad descubriendo regularmente nuevas variantes y técnicas. El descubrimiento en 2024 de TE.0 demuestra que la superficie de ataque sigue sin mapear completamente.

La complejidad de las arquitecturas web modernas—con múltiples capas de proxies, balanceadores, CDNs y dispositivos de seguridad—crea muchas oportunidades para inconsistencias en el análisis. A medida que las organizaciones adoptan arquitecturas de microservicios y computación sin servidor, el número de componentes de procesamiento HTTP en una ruta típica continúa creciendo, potencialmente ampliando la superficie de ataque.

Los proveedores de la nube se han convertido en objetivos particularmente importantes para la investigación de smuggling. Una sola vulnerabilidad en la infraestructura de una plataforma en la nube puede afectar simultáneamente a miles de aplicaciones de clientes, haciendo que estos descubrimientos sean especialmente valiosos tanto para atacantes como para investigadores.

Conclusión

El HTTP request smuggling ejemplifica los desafíos de seguridad que surgen de la ambigüedad del protocolo y la diversidad en las implementaciones. Al explotar desacuerdos sutiles entre sistemas sobre operaciones fundamentales del protocolo, los atacantes pueden evadir incluso controles de seguridad sofisticados.

La sofisticación necesaria para descubrir y explotar estas vulnerabilidades significa que, históricamente, han recibido menos atención que vectores de ataque más evidentes. Sin embargo, como señaló el investigador de seguridad James Kettle, HTTP request smuggling sigue siendo “en todas partes y ampliamente poco investigado”. Los descubrimientos recientes en plataformas en la nube de gran escala validan esta evaluación.

Las organizaciones deben reconocer que las vulnerabilidades de HTTP request smuggling suelen residir en componentes de infraestructura en lugar del código de la aplicación. Esto traslada la responsabilidad de detección y mitigación a los equipos de operaciones y seguridad que gestionan estos sistemas. Las evaluaciones de seguridad periódicas deben incluir pruebas especializadas para detectar request smuggling, especialmente tras desplegar nuevos componentes o actualizar los existentes.

A medida que las arquitecturas web siguen evolucionando, la comunidad de seguridad debe mantenerse vigilante ante inconsistencias en el análisis y ambigüedades del protocolo. La próxima variante importante de HTTP request smuggling probablemente ya exista, esperando que un investigador creativo descubra cómo dos sistemas pueden no estar de acuerdo en algo tan fundamental como dónde termina una solicitud y comienza otra.