Request Smuggling in HTTP/2 Downgrades

Reading time: 6 minutes

HTTP/2 est généralement considéré comme immunisé contre le request-smuggling classique car la longueur de chaque trame DATA est explicite. Cette protection disparaît dès qu'un proxy frontal “downgrade” la requête en HTTP/1.x avant de l'envoyer à un back-end. Au moment où deux parseurs différents (le front-end HTTP/2 et le back-end HTTP/1) essaient de s'accorder sur l'endroit où une requête se termine et où la suivante commence, tous les anciens trucs de désynchronisation reviennent – plus quelques nouveaux.

Pourquoi les downgrades se produisent

1. Les navigateurs parlent déjà HTTP/2, mais une grande partie de l'infrastructure d'origine héritée ne comprend encore que HTTP/1.1.
2. Les reverse-proxies (CDNs, WAFs, load-balancers) terminent donc TLS + HTTP/2 à la périphérie et réécrivent chaque requête en HTTP/1.1 pour l'origine.
3. L'étape de traduction doit créer à la fois des en-têtes Content-Length et/ou Transfer-Encoding: chunked afin que l'origine puisse déterminer la longueur du corps.

Chaque fois que le front-end fait confiance à la longueur de la trame HTTP/2 mais que le back-end fait confiance à CL ou TE, un attaquant peut les forcer à ne pas être d'accord.

Deux classes primitives dominantes

Celles-ci sont identiques en esprit aux classiques TE.CL / CL.TE, juste avec HTTP/2 remplaçant l'un des parseurs.

Identification d'une chaîne de downgrade

1. Utilisez ALPN dans une poignée de main TLS (openssl s_client -alpn h2 -connect host:443) ou curl :

curl -v --http2 https://target

Si * Using HTTP2 apparaît, la périphérie parle H2. 2. Envoyez une requête CL/TE délibérément malformée sur HTTP/2 (Burp Repeater a maintenant un menu déroulant pour forcer HTTP/2). Si la réponse est une erreur HTTP/1.1 telle que 400 Bad chunk, vous avez la preuve que la périphérie a converti le trafic pour un parseur HTTP/1 en aval.

Workflow d'exploitation (exemple H2.TE)

:method: POST
:path: /login
:scheme: https
:authority: example.com
content-length: 13      # ignored by the edge
transfer-encoding: chunked

5;ext=1\r\nHELLO\r\n
0\r\n\r\nGET /admin HTTP/1.1\r\nHost: internal\r\nX: X

1. Le front-end lit exactement 13 octets (HELLO\r\n0\r\n\r\nGE), pense que la requête est terminée et transmet cette quantité à l'origine.
2. Le back-end fait confiance à l'en-tête TE, continue de lire jusqu'à ce qu'il voit le deuxième 0\r\n\r\n, consommant ainsi le préfixe de la deuxième requête de l'attaquant (GET /admin …).
3. Le reste (GET /admin …) est traité comme une nouvelle requête mise en file d'attente derrière celle de la victime.

Remplacez la requête dissimulée par :

• POST /api/logout pour forcer la fixation de session
• GET /users/1234 pour voler une ressource spécifique à la victime

h2c smuggling (mises à niveau en texte clair)

Une étude de 2023 a montré que si un front-end passe l'en-tête HTTP/1.1 Upgrade: h2c à un back-end qui prend en charge HTTP/2 en texte clair, un attaquant peut tunneliser des trames HTTP/2 brutes à travers un edge qui ne validait que HTTP/1.1. Cela contourne la normalisation des en-têtes, les règles WAF et même la terminaison TLS.

Exigences clés :

• L'edge transmet à la fois Connection: Upgrade et Upgrade: h2c sans changement.
• L'origine passe à HTTP/2 et conserve la sémantique de réutilisation de connexion qui permet la mise en file d'attente des requêtes.

L'atténuation est simple : supprimer ou coder en dur l'en-tête Upgrade à l'edge sauf pour les WebSockets.

CVEs notables dans le monde réel (2022-2025)

• CVE-2023-25690 – Les règles de réécriture mod_proxy d'Apache HTTP Server pourraient être enchaînées pour le fractionnement et le smuggling de requêtes. (corrigé dans 2.4.56)
• CVE-2023-25950 – Smuggling de requêtes/réponses HAProxy 2.7/2.6 lorsque le parseur HTX gérait mal les requêtes en pipeline.
• CVE-2022-41721 – Le MaxBytesHandler de Go a causé des octets de corps restants à être analysés comme des trames HTTP/2, permettant le smuggling inter-protocoles.

Outils

• Burp Request Smuggler – depuis v1.26, il teste automatiquement H2.TE/H2.CL et le support ALPN caché. Activez "HTTP/2 probing" dans les options de l'extension.
• h2cSmuggler – PoC Python par Bishop Fox pour automatiser l'attaque de mise à niveau en texte clair :

python3 h2csmuggler.py -u https://target -x 'GET /admin HTTP/1.1\r\nHost: target\r\n\r\n'

• curl/hyper – création de charges utiles manuelles : curl --http2-prior-knowledge -X POST --data-binary @payload.raw https://target.

Mesures défensives

1. HTTP/2 de bout en bout – éliminer complètement la traduction de rétrogradation.
2. Source unique de vérité sur la longueur – lors de la rétrogradation, générez toujours un Content-Length valide et supprimez tous les en-têtes Content-Length/Transfer-Encoding fournis par l'utilisateur.
3. Normaliser avant le routage – appliquer la sanitation des en-têtes avant la logique de routage/réécriture.
4. Isolation de connexion – ne pas réutiliser les connexions TCP back-end entre les utilisateurs ; "une requête par connexion" contrecarrerait les exploits basés sur la file d'attente.
5. Supprimer Upgrade sauf WebSocket – empêche le tunneling h2c.

Références

• PortSwigger Research – “HTTP/2: The Sequel is Always Worse” https://portswigger.net/research/http2
• Bishop Fox – “h2c Smuggling: request smuggling via HTTP/2 clear-text” https://bishopfox.com/blog/h2c-smuggling-request