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

Inicio » 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 funciona Burp 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 Repetidor, oyentes 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 errores imposibles de detectar si te limita 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 campo 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 Repetidor (zona superior derecha) y Solicitar atributos en el inspector. En contextos no editables, es informativo; en Proxy/Repetidor, puedes alternar la versión y reenviar.

También puedes cambiar el 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, active Permitir anulación de HTTP/2 ALPN en el menú de Repetidor 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 compensaciones definidas, así que los delimitadores pierden significadoEsto abre la puerta a un metro 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 especificar.

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. Eructar de forma sencilla no te muestra los marcos por separado; te ofrece una vista unificada para trabajar cómodo sin perder la fidelidad del contenido.

La longitud del mensaje en H2 es específica: 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. Aún 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 línea de solicitud y la línea de estado: :method, :path, :authority, :scheme y :status (esta última solo en respuestas). Según RFC, deben ir antes que las cabeceras normales, y Burp las envía en orden fija a menos que lo cambies en el Inspector.

Ojo con la compatibilidad: los nombres de cabecera en H2 deben ir en minúsculas. Es técnicamente posible usar mayúsculas, pero algunos servidores Rechazan la petición por incumplir la especificacion. Por eso, la normalización de Burp evita que se conviertan 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 solicitudes 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 aplicación.

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 cargas útiles H2 exclusivos.: inyectar dos puntos en nombres de cabecera, espacios o saltos de línea en método y path,el 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 + Retorno para abrir \r\n.

Al hacer ediciones que no se pueden representar en H1 sin perder información, Burp marca la solicitud como hervidor. 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 Configuración > Red > 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 Repetidor junto al host de destino, y en el Inspector > Atributos de solicitud. En contextos editables, ese selector te permite actualizar o degradar la solicitud al vuelo.

Si quieres probar soporte H2 no anunciado (HTTP/2 oculto), activa en Repetidor Permitir la anulación de ALPN de HTTP/2Con esto, podrás forzar HTTP/2 incluso cuando el servidor no lo público por ALPN y descubrir superficies de ataque escondidas.

En escenarios raros en los que el cliente que navega a través del Proxy tiene problemas con su implementación H2, puedes desactivar HTTP/2 en un oyente del Proxy: Configuración > Herramientas > Proxy > Oyentes de proxy > Editar > 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 produce hervidor cuando introduce 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 :esquema, 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 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 hervidor en más herramientas, con especial foco en que Intruder pueda manejarlas de forma nativa.

Opciones y ajustes HTTP/2 en Burp

El repetidor 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 hostsTambié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 Repetidor: por defecto Burp eliminar la cabecera Conexión en solicitudes H2, porque muchos servidores H2 las rechazan. Si te apetece experimentar, puedes cambiar esta conducta y enviar Conexión igualmente. Y, como ya hemos visto, Permitir la anulación de ALPN de HTTP/2 te permite forzar H2 aun sin anuncio ALPN.

Más allá de H2, Burp permite configurar tipos de redirección permitidos (3xx con Ubicación, Actualizar encabezado, meta actualización, JavaScript, cualquier estado con Ubicación), 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 realRepetidor 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 Estado 100, Burp puede entender 100-Continuar (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, aplica solo al proyecto actual.

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

Es habitual encontrar servidores que soportaron H2 pero no lo anuncian por ALPN. Esto oculta la superficie de ataque y puede derivar en Solicitud de contrabando por degradaciónLa receta es sencilla: ignora ALPN y prueba a mandar H2. Con Burp (ALPN override en Repetidor) o con utilidades como curl usando conocimientos previos, puedes detectar este patrón rápidamente.

En cuanto a defensa, si quieres usar H2, negalo bienY si no lo necesitas, desactívalo del todo para no exponer superficies innecesarias. 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 Longitud del contenido/Codificación de transferencia. Ese desacuerdo reintroduce desincronizaciones con nuevas variantes: H2.CL (el frente 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 Error en la longitud del contenido y una carga útil diseñada, 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 Transferencia-Codificación: fragmentada en el downgrade y lo priorizaron frente a un Content-Length inyectado por el front-end. Resultado: colapsas el cuerpo antes y cuuelas 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 uso CRLF dentro del valor de una cabecera H2. En ciertos CDN, esto permitiría introducir Transferencia-Codificación: fragmentada al volcán a H1 y activar H2.TE con envenenamiento de caché persistente, logrando control de páginas servidas desde la caché.

La variante División de solicitudes H2.X aparece cuando, al degradar, el front-end inserta el \r\n\r\n de cierre de cabeceras y divide tu prefijo en una petición completa. Se observará un efecto dominó: cada usuario recibirá 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: confirmar y explotar

Hay front-ends que no reutilizan conexiones al back-end o aplica 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-aliveCon H2, si ves cabeceras HTTP/1 incrustadas en el cuerpo de la respuesta H2, tienes la prueba del algodón. Un problema adicional: algunas interfaces leen solo tantos bytes como indica el Content-Length de la primera respuesta, ocultando la segunda.

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

Para explotar de verdad, céntrate en cabeceras internas que el front-end inyecta (identidad del usuario, claves internas, enrutamiento). Con solicitud de tunelización 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 frente cree que parte de tu carga útil es cabecera, insertará sus internas en medio; la espalda puede tratarlas como parte de tu parámetro y te esos valores. Esta técnica es útil incluso cuando el túnel está ciego y solo recupera una respuesta.

En condiciones favorables, el túnel permite un envenenamiento de caché: usando HEAD, mezclas cabeceras de una respuesta con Ubicación 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 aceptar :ruta y usan uno u otro de forma inconsistente, abriendo vías de desvío de ruta. También existe la coexistencia de :autoridad y Host; al poder faltar uno u otro, emerge ataques de encabezado de host cambiando cómo una capa u otra resuelve el destino.

La pseudo-cabecera :esquema merece atención. Algunos sistemas la usan para construir URLs de forma ingenua; si puedes escribir bytes arbitrarios, inyectas prefijos de URL, cambias caminos y en ocasiones envenenas cachés o provoca SSRF si se utiliza para ruedar 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 :método (observado en combinaciones con mod_proxy) para saltarte bloqueos de rutas.

Por último, hay back-ends que aún soportan plegado de línea es 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 ID de solicitud reflejado terminaba mostrando datos insertados mediante una cabecera con espacio.

Herramientas, flujo de trabajo y trucos de productividad.

Para automatizar, existe un pila HTTP/2 simplificada en Turbo Intruder que transforma solicitudes H1 a H2 y aplicaciones mapeos de caracteres útiles para exploits: ^ → \r, ~ → \n, ` → :Incluso puedes sobrerizada pseudo-cabeceras declarándolas como cabeceras H1 ficticias y controlar así el downgrade en servidores vulnerables. Para pruebas con devoluciones de llamada 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 Contrabandista de solicitudes HTTP ya integran detecciones de estas variantes (incluida la de túnel con CABEZAL), y Param Miner ayuda a descubrir cabeceras internas por diferencias de respuesta.

En cuanto a estabilidad, vigila la reutilización de conexiones: algunos objetivos tratan la primera petición de forma distinta o se quedan con enchufes corruptos. En Burp Repetidor puedes desactivar la reutilización H2, y en Turbo Intruder ajustar solicitudesPorConexión 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 Solicitar atributos arriba a la derecha. Cambiar el método dentro del cuerpo ya no tiene efecto como ocurrirí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 Atributos de solicitud y añade una cabecera arbitraria. En el Nombre, inyecta un CRLF para colar un Maestro adicional, por ejemplo: foo: bar\r\nHost: abc Y Como valor Pon algo inocuo. Si la respuesta reacciona a tu Host inyectado, ha confirmado una inyección de CRLF vía nombres de cabecera.

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

Rellene el cuerpo principal con datos de relleno hasta superar el contrabando de longitud de contenido. 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 Director de escuela y en la cabecera maliciosa smugglea una petición GET al panel de administración con las cabeceras internas que ha 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\nSi 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 contrabandada. 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 Director de escuela y uso de cabeceras internas inyectadas por el frente 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 contrabando clásico reimaginado hasta la envenenamiento de caché persistente, por pasar fugas de PII y ejecución de JavaScript en sitios de alto perfil. Con ajustes bien medidos (protocolo por defecto, reutilización de conexiones, anulaciones de ALPN) y práctica con Repetidor e Inspector, tendrás control real sobre cómo viajan tus peticiones y sobre cómo se rompen las asunciones entre capas cuando se enfrenta HTTP/2 y HTTP/1.