Trabajar con HTTP/2 en Burp Suite: pruebas, ajustes y ataques de alto nivel

Home » Python » Trabajar con HTTP/2 en Burp Suite: pruebas, ajustes y ataques de alto nivel

HTTP/2 ha abierto una superficie de pruebas que antes era casi intocable con herramientas centradas en HTTP/1. Burp Suite, desde su Inspector y su editor de mensajes, permite manipular y analizar solicitudes H2 con un control que no vas a encontrar en otros productos. Si ya haces pentesting web, dominar cómo Burp trabaja con HTTP/2 es clave para descubrir fallos modernos como desincronizaciones, request smuggling en downgrades o inyecciones imposibles en HTTP/1.

Además, los ajustes finos de Burp (protocolo por defecto, opciones de Repeater, listeners del Proxy y tratamiento de respuestas especiales) marcan la diferencia entre ver un falso negativo y explotar una brecha crítica. Aquí tienes una guía práctica, de nivel profesional, que integra lo esencial del protocolo, las funciones únicas de Burp y las técnicas de ataque más actuales, todo explicado en un español natural y directo.

Por qué HTTP/2 cambia las reglas del juego en Burp Suite

Muchos servidores ya hablan HTTP/2, y con ello aparecen fallos imposibles de detectar si te limitas a HTTP/1. Burp Suite te deja elegir entre dos modos de trabajo con peticiones H2: una representación estilo HTTP/1 en el editor (Burp normaliza y envía el equivalente en HTTP/2) o la vista fiel de HTTP/2 en el Inspector, que muestra cabeceras y pseudo-cabeceras reales y te permite construir ataques exclusivos de HTTP/2.

Con esta combinación, puedes explorar vectores que apenas han sido auditados por falta de herramientas adecuadas hasta hace poco. La capacidad de Burp para ver y editar pseudo-cabeceras, inyectar nuevos caracteres en cabeceras y manipular el formato binario de H2 se traduce en hallazgos muy jugosos, como variantes modernas de request smuggling.

Por defecto, Burp negocia HTTP/2 cuando el servidor lo anuncia vía ALPN durante el handshake TLS. Aunque no busques fallos de protocolo, te aprovechas del rendimiento de H2; y cuando sí los buscas, puedes forzar la versión en cada solicitud desde el Inspector.

Cuando estás cazando vulnerabilidades a nivel de protocolo, es imprescindible saber qué versión usas en cada golpe. Burp lo deja claro en varios puntos: línea de petición y de estado en el editor, etiqueta de protocolo en Repeater (zona superior derecha) y Request Attributes en el Inspector. En contextos no editables, es informativo; en Proxy/Repetidor, puedes alternar la versión y reenviar.

También puedes cambiar protocolo a mano por petición. Burp transforma automáticamente el mensaje para que sea válido en el nuevo formato. Si quieres probar HTTP/2 aunque el servidor no lo anuncie por ALPN, activa Allow HTTP/2 ALPN override en el menú de Repeater y podrás tantear soporte H2 oculto.

Conceptos clave de HTTP/2 que necesitas dominar

HTTP/2 es binario. En HTTP/1 todo es texto y los servidores separan campos con operaciones de cadena (dos puntos, saltos de línea, etc.). En H2 los datos están a offsets definidos, así que los delimitadores pierden significado. Esto abre la puerta a meter nuevas secuencias en nombres y valores de cabeceras que en H1 te romperían el mensaje, y algunos servidores las toleran pese a lo que dicta la especificación.

En la red, los mensajes H2 viajan en frames: uno de cabeceras (equivalente a línea de petición + cabeceras de H1) y, si toca, varios de datos con el cuerpo. Burp por simplicidad no te muestra los frames por separado; te ofrece una vista unificada para trabajar cómodo sin perder la fidelidad del contenido.

La longitud del mensaje en H2 es explícita: cada frame lleva su propio campo de longitud y el servidor suma. Esto evita ambigüedades típicas de Content-Length o Transfer-Encoding en H1. Aun así, ese choque entre mundos se vuelve arma cuando hay front-ends que degradan H2 a H1 para hablar con el back-end.

HTTP/2 introduce pseudo-cabeceras que sustituyen a la request line y la status line: :method, :path, :authority, :scheme y :status (esta última solo en respuestas). Según la RFC, deben ir antes que las cabeceras normales, y Burp las envía en orden fijo a menos que lo cambies en el Inspector.

Ojo con la compatibilidad: los nombres de cabecera en H2 deberían ir en minúsculas. Es técnicamente posible usar mayúsculas, pero algunos servidores rechazan la petición por incumplir la especificación. Por eso, la normalización de Burp evita que conviertas sin querer un mensaje válido en H1 en uno inválido en H2.

Dos formas de trabajar con peticiones en Burp: editor vs Inspector

En el editor de mensajes puedes usar una representación estilo HTTP/1 para peticiones HTTP/2. Burp normaliza tus cambios y envía un equivalente H2 al servidor. Es ideal cuando el protocolo te da igual y quieres ir rápido probando la app.

En el Inspector, en cambio, tienes una vista nativa de HTTP/2 con las pseudo-cabeceras y cada cabecera en campos de Nombre/Valor. Como no depende de la sintaxis H1, puedes construir payloads H2 exclusivos: inyectar dos puntos en nombres de cabecera, espacios o saltos de línea en método y path, o CRLF dentro de cabeceras. Muchas de estas ediciones son tan simples como doble clic y teclear, y para insertar CRLF puedes abrir el detalle de la cabecera y usar Shift + Return para introducir \r\n.

Al hacer ediciones que no se pueden representar en H1 sin perder información, Burp marca la solicitud como kettled. En ese caso, el editor deja de intentar mostrarte un equivalente H1 y verás una notificación explicando por qué está kettled; el cuerpo sigue visible, pero cualquier cambio en cabeceras lo harás desde el Inspector.

Rastrear y cambiar el protocolo en cada petición

Burp usa HTTP/2 por defecto si el servidor lo anuncia por ALPN. Si necesitas centrarte en fallos que requieren H1 (por ejemplo, CL.TE o TE.CL clásicos), puedes cambiar el protocolo por defecto del proyecto en Settings > Network > HTTP, desmarcando la opción de preferir H2. Siempre podrás sobrescribirlo por petición con el conmutador de protocolo del Inspector.

Para identificar la versión en uso, Burp lo expone en varios sitios: línea de petición/estado del editor, el indicador en Repeater junto al host de destino, y en el Inspector > Request Attributes. En contextos editables, ese selector te permite upgradear o downgradear la solicitud al vuelo.

Si quieres probar soporte H2 no anunciado (HTTP/2 oculto), activa en Repeater Allow HTTP/2 ALPN override. Con esto, podrás forzar HTTP/2 incluso cuando el servidor no lo publique por ALPN y descubrir superficies de ataque escondidas.

En escenarios raros en los que el cliente que navega a través del Proxy tenga problemas con su implementación H2, puedes desactivar HTTP/2 en un listener del Proxy: Settings > Tools > Proxy > Proxy listeners > Edit > pestaña HTTP/2 y desmarcar Support HTTP/2. Esto afecta solo la conexión cliente-Burp; no cambia la conexión Burp-servidor.

Peticiones kettled: qué son, cómo se producen y cómo revertirlas

Una petición se vuelve kettled cuando introduces modificaciones que no se pueden representar con sintaxis HTTP/1 sin perder información. Ejemplos: añadir una letra mayúscula o dos puntos al nombre de una cabecera, CRLF en el nombre o valor, espacios en :path o :method, modificar :scheme, duplicar pseudo-cabeceras o insertar ; y espacio en un valor de cookie.

Si te has pasado de frenada, puedes deshacer con Ctrl/Cmd + Z, revertir manualmente desde el Inspector los cambios que causaron el estado kettled (la notificación del editor te lo chiva) o forzar el downgrade a HTTP/1 aceptando que se perderán cambios incompatibles: Burp normalizará la solicitud y descartará lo ilegible en H1.

Las extensiones pueden crear y emitir nuevas peticiones kettled, por lo que ya puedes desarrollar tus propios complementos para pruebas en H2. Sin embargo, de momento no pueden modificar solicitudes kettled que haya creado Burp, porque solo acceden a la representación normalizada estilo H1.

Como mejora en el roadmap de Burp, se trabaja en ampliar el soporte de kettled en más herramientas, con especial foco en que Intruder pueda manejarlas de forma nativa.

Opciones y ajustes HTTP/2 en Burp

Repeater incorpora opciones específicas para H2. Puedes mantener el protocolo en redirecciones entre dominios (enforce protocol choice) para que los saltos cross-domain sigan con la versión seleccionada, crucial cuando las vulnerabilidades H2 disparan peticiones a otros hosts. También puedes habilitar o deshabilitar la reutilización de conexiones H2: algunos servidores tratan diferente la primera petición o dejan conexiones en estado corrupto, provocando intermitencias; si lo desactivas, tu solicitud será siempre la primera del socket.

Otra opción de Repeater: por defecto Burp elimina la cabecera Connection en solicitudes H2, porque muchos servidores H2 las rechazan. Si te apetece experimentar, puedes cambiar esta conducta y enviar Connection igualmente. Y, como ya hemos visto, Allow HTTP/2 ALPN override te permite forzar H2 aun sin anuncio ALPN.

Más allá de H2, Burp permite configurar tipos de redirección permitidos (3xx con Location, Refresh header, meta refresh, JavaScript, cualquier status con Location), y tratar respuestas en streaming para no romper aplicaciones de salida continua (como interfaces con LLMs o SSE). El Proxy puede pasar el stream en tiempo real, Repeater actualiza la respuesta al vuelo y el resto de herramientas lo ignoran. Puedes decidir si almacenar streams completos, eliminar metadatos de chunked o tratar text/event-stream como streaming automáticamente.

En respuestas con Status 100, Burp puede entender 100-Continue (saltando la respuesta intermedia y analizando la real) y retirar cabeceras 100 antes de pasarlas al resto de herramientas. En HTTP/1, Burp puede usar keep-alive si el servidor lo soporta y cierra conexiones TCP inactivas a los 5 segundos. Todos estos son ajustes de proyecto, aplican solo al proyecto actual.

HTTP/2 oculto: detección y mitigación

Es habitual encontrar servidores que soportan H2 pero no lo anuncian por ALPN. Esto oculta superficie de ataque y puede derivar en request smuggling por downgrade. La receta es sencilla: ignora ALPN y prueba a mandar H2. Con Burp (ALPN override en Repeater) o con utilidades como curl usando prior-knowledge, puedes detectar este patrón rápidamente.

En cuanto a defensa, si quieres usar H2, asegúrate de anunciarlo bien. Y si no lo necesitas, desactívalo del todo para no exponer superficie innecesaria. En entornos con downgrades H2->H1, la recomendación es evitarlos y hablar H2 extremo a extremo.

Ataques y vectores exclusivos de HTTP/2

La gran familia de fallos en H2 llega con el downgrade H2 a H1 en el front-end. El front entiende la longitud por frames de H2, pero el back-end degradado vuelve a Content-Length/Transfer-Encoding. Ese desacuerdo reintroduce desincronizaciones con nuevas variantes: H2.CL (el front no valida CL) y H2.TE (acepta cabeceras de conexión prohibidas como TE).

Un caso célebre de H2.CL afectó a un gran sitio de streaming. Al mandar una petición HTTP/2 con Content-Length erróneo y un payload diseñado, el back-end cortaba antes de tiempo y trataba el resto como nueva petición, permitiendo prefijar la solicitud de otro usuario. Con un prefijo que provocaba redirecciones controladas, el impacto escalaba a robo de cuentas y datos sensibles.

En la vertiente H2.TE, algunos balanceadores aceptaron indebidamente Transfer-Encoding: chunked en el downgrade y lo priorizaron frente a un Content-Length inyectado por el front-end. Resultado: colapsas el cuerpo antes y cuelas una segunda petición, con impactos desde fugas de códigos OAuth hasta ejecución de JS vía redirecciones en recursos estáticos.

Otro patrón potente es la inyección de cabeceras durante el downgrade usando CRLF dentro del valor de una cabecera H2. En ciertos CDN, esto permitía introducir Transfer-Encoding: chunked al volcarlo a H1 y desencadenar H2.TE con cache poisoning persistente, logrando control de páginas servidas desde la caché.

La variante H2.X por request splitting aparece cuando, al degradar, el front-end inserta el \r\n\r\n de cierre de cabeceras y convierte tu prefijo en una petición completa. Se observó un efecto dominó: cada usuario recibía la respuesta destinada al anterior, con exposición de PII y cookies de sesión. Algunos intentos de parcheo incompletos dejaron vías como inyección en pseudo-cabeceras o bloquear CRLF pero no LF suelto, que sigue siendo explotable.

Túneles de petición (request tunnelling): confirmar y explotar

Hay front-ends que no reutilizan conexiones al back-end o aplican políticas 1:1 con el cliente. En estos escenarios, no puedes influir en la siguiente petición y las técnicas clásicas de confirmación fallan. Lo que sí queda es el túnel de petición: colar una segunda solicitud en el mismo viaje y obtener dos respuestas del back-end.

La confirmación con H1 es ambigua porque concatenar respuestas es normal en keep-alive. Con H2, si ves cabeceras HTTP/1 incrustadas en el cuerpo de la respuesta H2, tienes la prueba del algodón. Un problema adicional: algunos front-ends leen solo tantos bytes como indique el Content-Length de la primera respuesta, ocultando la segunda.

La solución práctica que mejor funciona es cambiar a HEAD en la solicitud visible, de forma que la primera respuesta traiga solo cabeceras. Esto hace que el front-end sobre-lea y te entregue el inicio de la segunda respuesta. Si además tuneas una segunda solicitud inválida, su respuesta de error suele llegar antes y facilita la detección. Ten paciencia: por sensibilidad temporal, puede requerir varios intentos.

Para explotar de verdad, céntrate en cabeceras internas que el front-end inyecta (identidad del usuario, claves internas, routing). Con request tunnelling puedes bypassar la reescritura/protección y colarlas sin filtros. Si no conoces sus nombres, usa herramientas como Param Miner, que pueden adivinar cabeceras internas por diferencias en la respuesta cuando viajan por el túnel.

Incluso sin conocerlas, puedes provocar desacuerdo sobre dónde empieza el cuerpo: si el front cree que parte de tu payload es cabecera, insertará sus internas en medio; el back puede tratarlas como parte de tu parámetro y reflejarte esos valores. Esta técnica es útil incluso cuando el túnel es ciego y solo recuperas una respuesta.

En condiciones favorables, el túnel permite un cache poisoning avanzado: usando HEAD, mezclas cabeceras de una respuesta con Location reflectante de otra y consigues que navegadores interpreten el contenido como HTML/JS, tomando control persistente de rutas cacheadas.

Primitivas extra: duplicados, :scheme y división de nombres

HTTP/2 permite escenarios impensables en H1: he visto servidores que aceptan múltiples :path y usan uno u otro de forma inconsistente, abriendo vías de desvío de ruta. También existe la coexistencia de :authority y Host; al poder faltar uno u otro, emergen ataques de Host header cambiando cómo una capa u otra resuelve el destino.

La pseudo-cabecera :scheme merece atención. Algunos sistemas la usan para construir URLs de forma ingenua; si puedes escribir bytes arbitrarios, inyectas prefijos de URL, cambias paths y en ocasiones envenenas cachés o provocas SSRF si se utiliza para rutear la petición aguas abajo.

Otra técnica es la división del nombre de cabecera permitiendo dos puntos en el nombre. No siempre genera desync porque el downgrade añade otro : final, pero sí favorece ataques de Host cuando los servidores ignoran lo que sigue al puerto. Si el back tolera rarezas, puedes forzar líneas de petición válidas inyectando espacios en :method (observado en combinaciones con mod_proxy) para saltarte bloqueos de rutas.

Por último, hay back-ends que aún soportan line folding en H1. Si el front-end acepta nombres de cabecera que empiezan con espacio y no ordena cabeceras, puedes contaminar cabeceras posteriores (incluidas internas). Se han visto ejemplos donde el Request-Id reflejado terminaba mostrando datos insertados mediante una cabecera con espacio inicial.

Herramientas, flujo de trabajo y trucos de productividad

Para automatizar, existe un stack HTTP/2 simplificado en Turbo Intruder que transforma solicitudes H1 a H2 y aplica mapeos de caracteres útiles para exploits: ^ → \r, ~ → \n, ` → :. Incluso puedes sobrescribir pseudo-cabeceras declarándolas como cabeceras H1 ficticias y controlar así el downgrade en servidores vulnerables. Para pruebas con callbacks y detección avanzada de interacciones puedes usar Burp Collaborator en flujos automatizados.

Si el stack H2 minimalista no se lleva bien con algún objetivo, puedes invocar el stack nativo de Burp desde Turbo Intruder (Engine.BURP2), que es más tolerante con comportamientos raros. Burp Scanner y extensiones como HTTP Request Smuggler ya integran detecciones de estas variantes (incluida la de túnel con HEAD), y Param Miner ayuda a descubrir cabeceras internas por diferencias de respuesta.

En cuanto a estabilidad, vigila la reutilización de conexiones: algunos targets tratan la primera petición de forma distinta o se quedan con sockets corruptos. En Burp Repeater puedes desactivar la reutilización H2, y en Turbo Intruder ajustar requestsPerConnection para evitar que efectos residuales distorsionen tus pruebas.

En la interfaz actual de Burp (nuevos Inspectores), el control de la versión HTTP está en Request attributes arriba a la derecha. Cambiar el método dentro del cuerpo ya no tiene efecto como ocurría en versiones antiguas; ahora se maneja todo desde la vista del Inspector y la lógica de protocolo.

Ejercicio práctico con Burp: CRLF en nombres de cabecera y túnel a /admin

Empieza con un GET / en Repeater, sube a H2 en Request Attributes y añade una cabecera arbitraria. En el Nombre, inyecta un CRLF para colar un Host adicional, por ejemplo: foo: bar\r\nHost: abc y como Valor pon algo inocuo. Si la respuesta reacciona a tu Host inyectado, has confirmado una inyección de CRLF vía nombres de cabecera.

Localiza un endpoint que refleje parámetros (como un search). Cambia el método con clic derecho (Change request method) y confirma que la búsqueda funciona con POST enviando search en el cuerpo. Ahora, en la cabecera arbitraria, inyecta un Content-Length grande y un segundo parámetro search tras un doble CRLF, por ejemplo: foo: bar\r\nContent-Length: 500\r\n\r\nsearch=x.

Rellena el cuerpo principal con datos de relleno hasta superar el Content-Length smuggleado. Al enviar, la aplicación reflejará cabeceras añadidas por el front-end (cookies de sesión, flags SSL y, lo importante, una clave única de front-end) dentro de la respuesta.

Cambia el método visible a HEAD y en la cabecera maliciosa smugglea una petición GET al panel de administración con las cabeceras internas que has aprendido: \r\n\r\nGET /admin HTTP/1.1\r\nX-SSL-VERIFIED: 1\r\nX-SSL-CLIENT-CN: administrator\r\nX-FRONTEND-KEY: TU-CLAVE\r\n\r\n. Si recibes un error de bytes insuficientes, apunta a un recurso con cuerpo más corto (por ejemplo, /login) para que el front-end sobre-lea y te muestre el inicio de la segunda respuesta en el cuerpo H2.

En esa respuesta anidada podrás localizar la URL administrativa sensible (por ejemplo, /admin/delete?username=carlos) y actualizar la ruta de la petición smuggleada. Aunque la respuesta visible puede ser de error, la acción se ejecuta porque ha viajado por el túnel hasta el back-end con las credenciales internas correctas.

Este ejemplo agrupa varias ideas: CRLF en nombre de cabecera en H2, abuso de Content-Length en downgrade, confirmación con HEAD y uso de cabeceras internas inyectadas por el front para alcanzar un panel restringido.

La combinación de conocimientos de protocolo, Inspector de Burp para H2, y técnicas de desync te permite cubrir vectores que van desde el smuggling clásico reimaginado hasta la poisoning de caché persistente, pasando por fugas de PII y ejecución de JavaScript en sitios de alto perfil. Con ajustes bien medidos (protocolo por defecto, reutilización de conexiones, overrides de ALPN) y práctica con Repeater e Inspector, tendrás control real sobre cómo viajan tus peticiones y sobre cómo se rompen las asunciones entre capas cuando se enfrentan HTTP/2 y HTTP/1.