HTTP/2 Desync: La próxima generación de ataques de Request Smuggling

Descubre cómo el framing binario de HTTP/2 introduce nuevos vectores de smuggling que evaden las defensas tradicionales. Desde el smuggling H2C hasta el abuso de nombres de encabezados, estos ataques funcionan cuando las protecciones HTTP/1.1 no aplican.

Introducción: La falsa promesa de la seguridad en HTTP/2

El request smuggling en HTTP ha afectado a las aplicaciones web desde 2005, explotando inconsistencias en cómo los servidores interpretan los límites de las solicitudes. Cuando surgió HTTP/2 con su protocolo de framing binario, muchos creyeron que eliminaría estas vulnerabilidades por completo. Después de todo, HTTP/2 usa campos de longitud explícitos para cada marco de datos, eliminando la ambigüedad que aquejaba a los encabezados Content-Length y Transfer-Encoding en HTTP/1.1.

Lamentablemente, este optimismo resultó prematuro. La degradación de HTTP/2—donde un servidor front-end habla HTTP/2 con los clientes pero reescribe las solicitudes a HTTP/1.1 antes de enviarlas a los servidores back-end—permite una variedad de ataques, incluido el request smuggling. Esta traducción de protocolo crea un espacio peligroso donde las garantías de seguridad de HTTP/2 se evaporan, y atacantes sofisticados pueden explotar las costuras entre protocolos.

Este artículo explora la evolución del request smuggling en la era de HTTP/2, examinando cómo los atacantes aprovechan el smuggling H2C, la inyección CRLF y la manipulación de encabezados para evadir los controles de seguridad modernos.

Entendiendo los fundamentos del HTTP/2 Request Smuggling

Por qué se suponía que HTTP/2 sería inmune

Las solicitudes HTTP/2 no se envían como mensajes de texto plano, sino que se convierten en formato binario. La solicitud se representa como “frames”, donde cada frame tiene un campo de longitud explícito que indica al servidor cuántos bytes debe leer. Esta arquitectura elimina la ambigüedad entre Content-Length y Transfer-Encoding que hacía vulnerable a HTTP/1.1.

El request smuggling en HTTP no es realmente una vulnerabilidad en sí misma del protocolo HTTP/1.1, sino la existencia de dos formas diferentes de especificar cómo termina la solicitud (Content-Length y Transfer-Encoding) que deja espacio para implementaciones incorrectas en la cadena de proxy HTTP. La mecanismo de longitud único e inequívoco de HTTP/2 debería, en teoría, prevenir estos ataques.

El problema de la degradación

La realidad es que los entornos puramente HTTP/2 siguen siendo relativamente raros. Aunque HTTP/2 está ampliamente utilizado, todavía existen servidores back-end legacy que usan exclusivamente HTTP/1.1, ya que el protocolo más reciente sigue siendo relativamente nuevo en implementaciones empresariales. Esto crea entornos mixtos donde los front-ends HTTP/2 se comunican con back-ends HTTP/1.1.

La especificación de HTTP/2 recomienda que cualquier solicitud que contenga el encabezado Transfer-Encoding sea eliminada o bloqueada por el servidor front-end. Pero si el servidor front-end ignora la especificación y permite que la solicitud pase con el encabezado intacto, posteriormente degrada la solicitud a HTTP/1.1 y la envía a un servidor back-end que soporta codificación en bloques. Aquí es donde reaparecen las vulnerabilidades de request smuggling.

Vectores de ataque: Desincronización H2.CL y H2.TE

Ataques HTTP/2 a Content-Length (H2.CL)

En ataques H2.CL, el servidor front-end HTTP/2 pasa un encabezado Content-Length que no debería existir en el contexto de HTTP/2. Cuando la solicitud se degrada a HTTP/1.1, el servidor back-end usa este encabezado para determinar los límites de la solicitud, creando oportunidades para el manipulación.

Al redirigir inclusiones de JavaScript, los atacantes podrían ejecutar JavaScript malicioso para comprometer cuentas de usuario y robar contraseñas y números de tarjetas de crédito. Ejecutando este ataque en un ciclo, podrían comprometer gradualmente a todos los usuarios activos del sitio, sin interacción del usuario. Netflix sufrió exactamente esta vulnerabilidad, rastreada a través de su proxy Zuul hasta Netty, resultando en CVE-2021-21295 y una recompensa máxima de $20,000.

Ataques HTTP/2 a Transfer-Encoding (H2.TE)

El RFC establece que cualquier mensaje que contenga campos de encabezado específicos de conexión debe tratarse como malformado. Uno de estos campos es Transfer-Encoding. El balanceador de carga de Amazon Web Services falló en obedecer esta línea y aceptó solicitudes que contenían Transfer-Encoding, permitiendo la explotación en casi todos los sitios web que lo usan mediante una desincronización H2.TE.

Estos ataques demuestran cómo incluso grandes proveedores de la nube pueden implementar HTTP/2 incorrectamente, dejando vulnerables a millones de sitios web.

Smuggling H2C: La técnica de actualización de conexión en texto claro

¿Qué es H2C Smuggling?

H2C smuggling representa una de las técnicas de ataque más innovadoras descubiertas en años recientes. Revelada por investigadores de Bishop Fox en septiembre de 2020, el smuggling de HTTP/2 en texto claro (H2C) abusa de front-ends que no son conscientes de H2C para crear un túnel hacia sistemas back-end, permitiendo a los atacantes evadir reglas de reescritura front-end y explotar encabezados HTTP internos.

Actualizar conexiones HTTP/1.1 a conexiones HTTP/2 en texto claro (h2c) menos conocidas puede permitir evadir controles de acceso en el borde. Esta técnica fue reconocida como la principal técnica de hacking web de 2020 por la votación anual de la comunidad de seguridad de PortSwigger.

Cómo funciona el ataque

El ataque explota cómo las conexiones HTTP pueden actualizarse de HTTP/1.1 a HTTP/2. Esta técnica de smuggling H2C permite a los atacantes evadir controles proxy transmitiendo solicitudes de actualización HTTP/1.1 vía TLS, que van directamente a los servidores back-end. Las actualizaciones H2C hechas sobre TLS violan la especificación del protocolo, pero muchos servidores las aceptan de todos modos.

h2cSmuggler es una prueba de concepto en Python por Bishop Fox para automatizar el ataque de actualización en texto claro.

Impacto en el mundo real

Tras investigar el impacto del smuggling H2C en varios objetivos de recompensas por bugs, los investigadores descubrieron varias formas de evadir autenticación, enrutamiento y WAF en múltiples proveedores de la nube. Incluso proveedores que inicialmente parecían inmunes resultaron vulnerables cuando se aplicó la técnica de manera más exhaustiva.

Con este tipo de request smuggling, puedes enviar tantas solicitudes como desees vía multiplexación HTTP/2. El request smuggling permite una amplia variedad de ataques, incluyendo falsificación de encabezados internos, acceso a endpoints administrativos restringidos y, en ocasiones, SSRF en el encabezado Host, permitiendo mayor movimiento dentro de la red.

Inyección CRLF en encabezados HTTP/2

La vulnerabilidad del protocolo binario

La naturaleza binaria de HTTP/2 debería prevenir ataques de inyección CRLF (Carriage Return Line Feed) que afectan a HTTP/1.1. Sin embargo, debido a la naturaleza binaria de HTTP/2, existen varias formas de intentar evadir las protecciones. La inyección CRLF que permite smuggling de encabezados más allá del front-end HTTP/2 es un vector principal.

La especificación de HTTP/2 para valores de encabezado establece que un valor de campo no debe contener el valor cero (ASCII NUL, 0x00), salto de línea (ASCII LF, 0x0a) o retorno de carro (ASCII CR, 0x0d) en ninguna posición. Si estos caracteres se incluyen en un valor adjunto a uno de los encabezados en una solicitud, esa solicitud debe tratarse como malformada y ser manejada o descartada. Muchos servidores no aplican esta restricción.

Técnica de explotación

La inyección de Transfer-Encoding debe insertarse en el valor de un encabezado arbitrario con una secuencia CRLF, por ejemplo Foo: bar\r\nTransfer-Encoding: chunked. Es necesario que exista una duplicación del encabezado arbitrario en la solicitud.

Cuando el front-end degrada esta solicitud HTTP/2 a HTTP/1.1, procesa los caracteres CRLF literalmente, creando nuevas líneas de encabezado que no existían en la solicitud HTTP/2 original. El servidor back-end ve entonces un encabezado Transfer-Encoding que evadió todos los controles de seguridad del front-end.

Al intentar explotar el request smuggling en HTTP/2 a HTTP/1.1, la inyección CRLF suele ser necesaria. A diferencia de HTTP/1.1, que es basado en texto, HTTP/2 es un protocolo binario y ya no usa los mismos delimitadores para estructurar solicitudes. Cuando un servidor front-end convierte una solicitud HTTP/2 en HTTP/1.1, puede interpretar ciertos caracteres binarios como saltos de línea, permitiendo a un atacante inyectar encabezados adicionales y manipular la solicitud reescrita.

Envenenamiento de cola de respuesta y secuestro de sesión

Entendiendo la desincronización de respuesta

Una de las consecuencias más graves de la desincronización es el envenenamiento de la cola de respuesta. Cuando ocurre una desincronización, puede conducir a la exposición de datos sensibles de usuarios, contaminación de sesiones entre usuarios y compromiso persistente hasta que se cierra la conexión.

El envenenamiento de la cola de respuesta funciona al smugglear una solicitud adicional después de la primera. La primera solicitud provoca la desincronización de la cola de respuesta, causando que los usuarios reciban respuestas de otros usuarios.

Robo de sesiones en la práctica

Usando desincronización de la cola de respuesta junto con técnicas tradicionales de request smuggling en HTTP/1.1, los atacantes pueden capturar solicitudes de usuarios legítimos, permitiendo la toma de control de cuentas y acceso a información sensible.

El ataque procede así: un atacante envía una solicitud cuidadosamente diseñada que causa desincronización, y las solicitudes legítimas subsecuentes del usuario se añaden a los prefijos controlados por el atacante. El atacante puede capturar cookies de sesión, tokens de autenticación y otros datos sensibles de víctimas que envían solicitudes inmediatamente después del ataque.

Desincronización del lado del cliente: una nueva frontera

Más allá de los ataques servidor a servidor

Uno de los avances más recientes en la investigación de ataques de desincronización es el descubrimiento de ataques de desincronización del lado del cliente (CSD). Una desincronización del cliente es un ataque en el que el navegador de la víctima es engañado para desincronizar su conexión con el sitio vulnerable, diferente a los ataques tradicionales de request smuggling que causan desincronización entre un servidor front-end y back-end.

Esta evolución significa que incluso arquitecturas diseñadas para aislar conexiones de usuarios pueden ser vulnerables, ya que el ataque apunta a la propia conexión del cliente en lugar de la infraestructura compartida del servidor.

Técnicas avanzadas: abuso de nombres de encabezados y trucos de codificación

Explotando validaciones débiles de encabezados

Cloudflare aplicó validaciones más débiles después del encabezado 100 antes de reenviar la solicitud a un servidor upstream. Si un servidor HTTP acepta y analiza encabezados HTTP que terminan en tabulación o espacio, esto puede causar desincronización en HTTP/1.1 debido al ataque de HTTP/2.

Mientras los dos puntos, saltos de línea y caracteres A-Z siguen prohibidos en encabezados smuggled, los espacios y tabulaciones son suficientes para realizar el ataque en algunos casos. Para desencadenar desincronización en conexiones HTTP keep-alive, un atacante puede usar algo como “transfer-encoding : chunked” (nota el espacio antes de los dos puntos).

Variantes emergentes de ataque

La investigación continúa descubriendo nuevas técnicas de desincronización: ataques 0.CL explotando encabezados Content-Length de longitud cero, manipulación del encabezado Expect aprovechando el mecanismo 100-Continue, y encadenamiento de protocolos combinando HTTP/2, HTTP/1.1 y actualizaciones de WebSocket. Este tema sigue siendo poco investigado, y los profesionales de seguridad continúan descubriendo nuevas técnicas de explotación.

Vulnerabilidades recientes y ejemplos del mundo real

CVEs destacados

Varias vulnerabilidades críticas demuestran la amenaza en curso:

CVE-2023-25690 afectó a Apache HTTP Server donde las reglas de reescritura de mod_proxy podían encadenarse para request splitting y smuggling, corregido en la versión 2.4.56. CVE-2023-25950 impactó a HAProxy 2.⁷⁄₂.6 donde el parser HTX manejaba mal las solicitudes en pipeline. CVE-2022-41721 afectó a MaxBytesHandler de Go, causando que bytes sobrantes del cuerpo se interpretaran como marcos HTTP/2, permitiendo el smuggling entre protocolos.

Versiones de Apache HTTP Server hasta la 2.4.63 contenían vulnerabilidades que permitían a atacantes man-in-the-middle realizar ataques de desincronización HTTP y secuestrar sesiones HTTP durante actualizaciones TLS. La vulnerabilidad CVE-2025-49812 específicamente permitía a atacantes explotar la funcionalidad de actualización TLS para realizar ataques de desincronización, demostrando que incluso conexiones cifradas pueden ser vulnerables.

Impacto en recompensas por bugs

En 2024, la resistencia a vulnerabilidades TE.0 y chunks extraños se volvió crítica, y en 2025 se confirmó inmunidad a ataques basados en Expect y 0.CL, con recompensas superiores a $350,000. Estos pagos reflejan la gravedad de las vulnerabilidades de desincronización en HTTP/2.

Herramientas de detección y prueba

Enfoques profesionales de prueba

Las solicitudes TRACE pueden ser muy útiles al analizar una vulnerabilidad de smuggling. La respuesta muestra exactamente qué recibe el back-end, proporcionando información sobre encabezados modificados o añadidos por el proxy e incluso modificaciones de protocolo, como la degradación de HTTP/2 a HTTP/1.1, que es la fuente de muchas vulnerabilidades de desincronización.

Varias herramientas ayudan a los profesionales de seguridad a identificar estas vulnerabilidades:

Burp Request Smuggler desde v1.26 prueba automáticamente H2.TE/H2.CL y soporte oculto de ALPN—habilita “HTTP/2 probing” en las opciones de extensión. h2cSmuggler es una prueba de concepto en Python de Bishop Fox para automatizar el ataque de actualización en texto claro.

La herramienta de código abierto http2smugl permite a ingenieros, DevOps y equipos de seguridad verificar si sus balanceadores de carga son vulnerables a HTTP/2 request smuggling de forma gratuita, y también es útil para investigaciones de bug bounty y descubrimiento de nuevas vulnerabilidades.

Estrategias de prevención y mitigación

Defensa principal: End-to-End HTTP/2

Para prevenir vulnerabilidades de request smuggling, usa HTTP/2 de extremo a extremo y desactiva la degradación de HTTP si es posible. HTTP/2 usa un mecanismo robusto para determinar la longitud de las solicitudes y, cuando se usa de extremo a extremo, está protegido de forma inherente contra request smuggling.

Asegúrate de usar conexiones HTTP/2 de extremo a extremo y no degradarlas. Esto evitará todos los ataques basados en degradación. Si configuras o gestionas un servidor HTTP/2, especialmente uno que soporta degradación, asegúrate de rechazar solicitudes con encabezados que especifiquen tamaños de cuerpo excesivos.

Cuando la degradación es inevitable

Si no puedes evitar la degradación HTTP, valida la solicitud reescrita contra la especificación HTTP/1.1. Otras medidas incluyen:

Rechazar solicitudes ambiguas que contengan tanto Content-Length como Transfer-Encoding, tanto en el front-end como en el back-end. Evitar reutilizar conexiones entre el servidor front-end y back-end para prevenir la persistencia de solicitudes fuera de sincronía. Implementar un WAF configurado para detectar y bloquear intentos de request smuggling. Alinear la pila tecnológica usando el mismo servidor para front-end y back-end para evitar diferencias en el análisis e interpretación de las solicitudes HTTP.

Mitigaciones específicas para H2C

La mitigación para H2C es sencilla—eliminar o codificar la cabecera Upgrade en el borde, excepto para WebSockets.

Mantener estrategias de defensa en profundidad, reducir la importancia de los encabezados smuggled en tu arquitectura y estar preparado para identificar y rechazar solicitudes sospechosas en el back-end ayudará a reducir el impacto de futuras técnicas de ataque.

Prevención de inyección CRLF

Otra estrategia de mitigación es bloquear cualquier encabezado que contenga secuencias específicas, como CRLF. Los servidores deben aplicar estrictamente la prohibición de caracteres de retorno de carro y salto de línea en los valores de los encabezados, según la especificación HTTP/2.

Perspectivas futuras y tendencias emergentes

La persistencia de HTTP/1.1

HTTP/1.1 sigue siendo especialmente vulnerable al request smuggling porque sus límites de mensaje pueden expresarse de varias formas. Los RFCs definen reglas estrictas, pero en la práctica muchos servidores fueron construidos en diferentes momentos con distintas interpretaciones. Para mantener compatibilidad con clientes reales, las implementaciones a menudo aceptan solicitudes ligeramente malformadas en lugar de rechazarlas.

El request smuggling sigue siendo prevalente porque muchas aplicaciones modernas aún dependen de pilas HTTP/1.1 heredadas en lugar del sucesor actual, HTTP/2. Además, parchear es a menudo difícil debido a la falta de soporte uniforme para el protocolo HTTP en diferentes entornos de servidor.

Investigación en curso

Los ataques de smuggling, incluyendo la desincronización, son amenazas principales para la web moderna y siguen siendo relevantes tanto para HTTP/1.1 como para HTTP/2. A medida que los investigadores continúan examinando la interacción entre protocolos, probablemente emerjan nuevos vectores de ataque.

Conclusión

Los ataques de desincronización en HTTP/2 representan una evolución sofisticada del request smuggling que explota la brecha entre versiones del protocolo. Aunque el framing binario de HTTP/2 fue diseñado para eliminar la ambigüedad que permitía ataques tradicionales, la práctica extendida de degradar solicitudes a HTTP/1.1 para comunicación con back-end reintroduce estas vulnerabilidades.

Las organizaciones deben entender que simplemente adoptar HTTP/2 en el borde no proporciona protección completa. La verdadera seguridad requiere una implementación de extremo a extremo en HTTP/2, validación estricta de encabezados, manejo cuidadoso de actualizaciones de protocolo y vigilancia continua contra nuevas variantes de ataque.

A medida que la infraestructura web evoluciona, la interacción entre diferentes versiones del protocolo seguirá siendo un objetivo atractivo para los atacantes. Los equipos de seguridad deben priorizar eliminar la degradación HTTP cuando sea posible, implementar validaciones robustas de encabezados y mantenerse actualizados con las investigaciones emergentes en este campo en rápida expansión.

Puntos clave:

La degradación de HTTP/2 reintroduce vulnerabilidades de request smuggling que HTTP/2 puro evitaría
El smuggling H2C evade controles en el borde explotando mecanismos de actualización en texto claro
La inyección CRLF en encabezados HTTP/2 puede smugglear encabezados adicionales más allá de la validación frontal
La implementación de extremo a extremo en HTTP/2 es la defensa más efectiva contra estos ataques
La investigación continua revela nuevas técnicas de explotación en la interacción de protocolos