HTTP Connection Request Smuggling

Reading time: 6 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Cette page résume, étend et met à jour la recherche fondamentale de PortSwigger sur Browser-Powered Desync Attacks et les travaux ultérieurs sur l'abus de l'état de connexion HTTP/2. Elle se concentre sur les vulnérabilités où une origine est déterminée uniquement une fois par connexion TCP/TLS, permettant à un attaquant de « faire passer » des requêtes vers un autre hôte interne une fois le canal établi.

Attaques sur l'état de connexion

Validation de la première requête

Lors du routage des requêtes, les proxys inverses peuvent dépendre de l'en-tête Host (ou :authority dans HTTP/2) pour déterminer le serveur back-end de destination, s'appuyant souvent sur une liste blanche d'hôtes autorisés. Cependant, une vulnérabilité existe dans un certain nombre de proxys où la liste blanche est uniquement appliquée à la toute première requête dans une connexion. Par conséquent, les attaquants peuvent accéder à des hôtes virtuels internes en envoyant d'abord une requête autorisée, puis en réutilisant la même connexion sous-jacente :

http
GET / HTTP/1.1
Host: allowed-external-host.example

GET /admin HTTP/1.1
Host: internal-only.example

Routage de la première requête

De nombreux proxies inverses HTTP/1.1 associent une connexion sortante à un pool de back-end basé exclusivement sur la première requête qu'ils transmettent. Toutes les requêtes suivantes envoyées via le même socket frontal sont silencieusement réutilisées, indépendamment de leur en-tête Host. Cela peut être combiné avec des attaques classiques sur l'en-tête Host telles que le poisoning de réinitialisation de mot de passe ou le poisoning de cache web pour obtenir un accès semblable à SSRF à d'autres hôtes virtuels :

http
GET / HTTP/1.1
Host: public.example

POST /pwreset HTTP/1.1
Host: private.internal

tip

Dans Burp Suite Professional ≥2022.10, vous pouvez activer HTTP Request Smuggler → Connection-state probe pour détecter automatiquement ces faiblesses.

NOUVEAU en 2023-2025 – Abus de la coalescence de connexion HTTP/2/3

Les navigateurs modernes coalescent régulièrement les requêtes HTTP/2 et HTTP/3 sur une seule connexion TLS lorsque le certificat, le protocole ALPN et l'adresse IP correspondent. Si un front-end n'autorise que la première requête, chaque requête coalescée suivante hérite de cette autorisation – même si le Host/:authority change.

Scénario d'exploitation

  1. L'attaquant contrôle evil.com qui résout le même nœud de bord CDN que la cible internal.company.
  2. Le navigateur de la victime a déjà une connexion HTTP/2 ouverte vers evil.com.
  3. L'attaquant intègre une <img src="https://internal.company/…"> cachée dans sa page.
  4. Comme les paramètres de connexion correspondent, le navigateur réutilise la connexion TLS existante et multiplexe la requête pour internal.company.
  5. Si le CDN/le routeur a seulement validé la première requête, l'hôte interne est exposé.

Des PoCs pour Chrome/Edge/Firefox sont disponibles dans la présentation de James Kettle “HTTP/2: The Sequel is Always Worse” (Black Hat USA 2023).

Outils

  • Burp Suite 2023.12 a introduit un point d'insertion HTTP/2 Smuggler expérimental qui tente automatiquement la coalescence et les techniques TE/CL.
  • smuggleFuzz (https://github.com/microsoft/smugglefuzz) – Un framework Python publié en 2024 pour forcer les vecteurs de désynchronisation front-end/back-end sur HTTP/2 et HTTP/3, y compris les permutations d'état de connexion.

Atténuations

  • Toujours re-valider Host/:authority à chaque requête, pas seulement lors de la création de la connexion.
  • Désactiver ou restreindre strictement la coalescence d'origine sur les couches CDN/équilibreur de charge (par exemple, http2_origin_cn désactivé dans NGINX).
  • Déployer des certificats ou des adresses IP séparés pour les noms d'hôtes internes et externes afin que le navigateur ne puisse pas les coalescer légalement.
  • Préférer connection: close ou proxy_next_upstream après chaque requête lorsque cela est pratique.

Cas réels (2022-2025)

AnnéeComposantCVERemarques
2022AWS Application Load Balancer–L'en-tête Host n'a été validé que sur la première requête ; corrigé par le patch du moteur de règles (divulgué par SecurityLabs).
2023Apache Traffic Server < 9.2.2CVE-2023-39852A permis le request smuggling via la réutilisation de connexion HTTP/2 lorsque CONFIG proxy.config.http.parent_proxy_routing_enable était activé.
2024Envoy Proxy < 1.29.0CVE-2024-2470Validation incorrecte de :authority après le premier flux a permis le request smuggling inter-locataires dans des mailles partagées.

Feuille de triche de détection

  1. Envoyer deux requêtes dans la même connexion TCP/TLS avec des en-têtes Host ou :authority différents.
  2. Observer si la deuxième réponse provient du premier hôte (sûr) ou du deuxième hôte (vulnérable).
  3. Dans Burp : Repeat → keep-alive → Send → Follow.
  4. Lors de tests HTTP/2, ouvrir un flux dédié (ID 1) pour un hôte bénin, puis multiplexe un deuxième flux (ID 3) vers un hôte interne et rechercher une réponse.

Références

  • PortSwigger Research – HTTP/2: The Sequel is Always Worse (Black Hat USA 2023)
  • Avis de sécurité Envoy CVE-2024-2470 – Validation incorrecte de l'autorité

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks