HTTP Connection Request Smuggling

Reading time: 5 minutes

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Questa pagina riassume, estende e aggiorna la ricerca fondamentale di PortSwigger su Browser-Powered Desync Attacks e il lavoro successivo sull'abuso dello stato di connessione HTTP/2. Si concentra sulle vulnerabilità in cui un'origine è determinata solo una volta per connessione TCP/TLS, consentendo a un attaccante di "smuggler" richieste a un diverso host interno una volta stabilito il canale.

Connection-State Attacks

First-request Validation

Quando si instradano le richieste, i proxy inversi potrebbero dipendere dall'intestazione Host (o :authority in HTTP/2) per determinare il server back-end di destinazione, spesso facendo affidamento su una lista bianca di host che sono autorizzati ad accedere. Tuttavia, esiste una vulnerabilità in un certo numero di proxy in cui la lista bianca è applicata solo alla prima richiesta in una connessione. Di conseguenza, gli attaccanti possono accedere a host virtuali interni inviando prima una richiesta consentita e poi riutilizzando la stessa connessione sottostante:

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

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

First-request Routing

Molti proxy inversi HTTP/1.1 mappano una connessione in uscita a un pool di back-end basandosi esclusivamente sulla prima richiesta che inoltrano. Tutte le richieste successive inviate attraverso lo stesso socket front-end vengono riutilizzate silenziosamente, indipendentemente dal loro header Host. Questo può essere combinato con attacchi classici Host header come il poisoning del reset della password o web cache poisoning per ottenere accesso simile a SSRF ad altri host virtuali:

http
GET / HTTP/1.1
Host: public.example

POST /pwreset HTTP/1.1
Host: private.internal

tip

In Burp Suite Professional ≥2022.10 puoi abilitare HTTP Request Smuggler → Connection-state probe per rilevare automaticamente queste vulnerabilità.

NUOVO nel 2023-2025 – Abuso di Coalescenza delle Connessioni HTTP/2/3

I browser moderni coalescono regolarmente le richieste HTTP/2 e HTTP/3 su una singola connessione TLS quando il certificato, il protocollo ALPN e l'indirizzo IP corrispondono. Se un front-end autorizza solo la prima richiesta, ogni successiva richiesta coalescita eredita quella autorizzazione – anche se il Host/:authority cambia.

Scenario di sfruttamento

  1. L'attaccante controlla evil.com che si risolve nello stesso nodo edge CDN del target internal.company.
  2. Il browser della vittima ha già una connessione HTTP/2 aperta a evil.com.
  3. L'attaccante incorpora un <img src="https://internal.company/…"> nascosto nella propria pagina.
  4. Poiché i parametri di connessione corrispondono, il browser riutilizza la connessione TLS esistente e multiplexa la richiesta per internal.company.
  5. Se il CDN/router ha convalidato solo la prima richiesta, l'host interno è esposto.

PoCs per Chrome/Edge/Firefox sono disponibili nel talk di James Kettle “HTTP/2: The Sequel is Always Worse” (Black Hat USA 2023).

Strumenti

  • Burp Suite 2023.12 ha introdotto un punto di inserimento sperimentale HTTP/2 Smuggler che tenta automaticamente la coalescenza e le tecniche TE/CL.
  • smuggleFuzz (https://github.com/microsoft/smugglefuzz) – Un framework Python rilasciato nel 2024 per forzare vettori di desync front-end/back-end su HTTP/2 e HTTP/3, inclusi le permutazioni dello stato della connessione.

Mitigazioni

  • Sempre ri-convalidare Host/:authority su ogni richiesta, non solo alla creazione della connessione.
  • Disabilitare o limitare rigorosamente la coalescenza dell'origine sui livelli CDN/balancer (ad es. http2_origin_cn disattivato in NGINX).
  • Distribuire certificati o indirizzi IP separati per nomi host interni ed esterni in modo che il browser non possa coalescerli legalmente.
  • Preferire connection: close o proxy_next_upstream dopo ogni richiesta dove pratico.

Casi Reali (2022-2025)

AnnoComponenteCVENote
2022AWS Application Load Balancer–L'intestazione Host è stata convalidata solo sulla prima richiesta; risolto patchando il motore di regole (rivelato da SecurityLabs).
2023Apache Traffic Server < 9.2.2CVE-2023-39852Ha consentito lo smuggling delle richieste tramite il riutilizzo della connessione HTTP/2 quando CONFIG proxy.config.http.parent_proxy_routing_enable era impostato.
2024Envoy Proxy < 1.29.0CVE-2024-2470Convalida impropria di :authority dopo il primo stream ha abilitato lo smuggling delle richieste cross-tenant in mesh condivisi.

Scheda di Rilevamento

  1. Invia due richieste nella stessa connessione TCP/TLS con intestazioni Host o :authority diverse.
  2. Osserva se la seconda risposta proviene dal primo host (sicuro) o dal secondo host (vulnerabile).
  3. In Burp: Repeat → keep-alive → Send → Follow.
  4. Quando testi HTTP/2, apri uno stream dedicato (ID 1) per un host benigno, quindi multiplexa un secondo stream (ID 3) a un host interno e cerca una risposta.

Riferimenti

  • PortSwigger Research – HTTP/2: The Sequel is Always Worse (Black Hat USA 2023)
  • Envoy Security Advisory CVE-2024-2470 – Convalida impropria dell'autorità

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks