mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-connection-request-smuggling.md'] t
This commit is contained in:
Translator
parent
bae025e3d7
commit
38121ead24
@ -2,33 +2,82 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
**Questo è un riepilogo del post** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)
|
||||
**Questa pagina riassume, estende e aggiorna** la ricerca fondamentale di PortSwigger su [Browser-Powered Desync Attacks](https://portswigger.net/research/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.
|
||||
|
||||
## Attacchi allo Stato della Connessione <a href="#state" id="state"></a>
|
||||
## Connection-State Attacks <a href="#state" id="state"></a>
|
||||
|
||||
### Validazione della Prima Richiesta
|
||||
### First-request Validation
|
||||
|
||||
Quando si instradano le richieste, i proxy inversi potrebbero dipendere dall'**intestazione Host** 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 alcuni proxy in cui la lista bianca è applicata solo alla richiesta iniziale in una connessione. Di conseguenza, gli attaccanti potrebbero sfruttare questo facendo prima una richiesta a un host consentito e poi richiedendo un sito interno attraverso la stessa connessione:
|
||||
```
|
||||
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]
|
||||
Host: allowed-external-host.example
|
||||
|
||||
GET / HTTP/1.1
|
||||
Host: [internal-host]
|
||||
GET /admin HTTP/1.1
|
||||
Host: internal-only.example
|
||||
```
|
||||
### First-request Routing
|
||||
|
||||
In alcune configurazioni, un server front-end può utilizzare il **Host header della prima richiesta** per determinare il routing back-end per quella richiesta e poi instradare in modo persistente tutte le richieste successive dallo stesso client sulla stessa connessione back-end. Questo può essere dimostrato come:
|
||||
```
|
||||
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](https://portswigger.net/web-security/host-header) come il poisoning del reset della password o [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning) per ottenere accesso simile a SSRF ad altri host virtuali:
|
||||
```http
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
Host: public.example
|
||||
|
||||
POST /pwreset HTTP/1.1
|
||||
Host: psres.net
|
||||
Host: private.internal
|
||||
```
|
||||
Questo problema può essere potenzialmente combinato con [Host header attacks](https://portswigger.net/web-security/host-header), come il poisoning del reset della password o [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning), per sfruttare altre vulnerabilità o ottenere accesso non autorizzato a ulteriori host virtuali.
|
||||
> [!TIP]
|
||||
> In Burp Suite Professional ≥2022.10 puoi abilitare **HTTP Request Smuggler → Connection-state probe** per rilevare automaticamente queste vulnerabilità.
|
||||
|
||||
> [!NOTE]
|
||||
> Per identificare queste vulnerabilità, è possibile utilizzare la funzione 'connection-state probe' in HTTP Request Smuggler.
|
||||
---
|
||||
|
||||
## 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)
|
||||
|
||||
| Anno | Componente | CVE | Note |
|
||||
|------|-----------|-----|-------|
|
||||
| 2022 | AWS Application Load Balancer | – | L'intestazione Host è stata convalidata solo sulla prima richiesta; risolto patchando il motore di regole (rivelato da SecurityLabs). |
|
||||
| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | Ha consentito lo smuggling delle richieste tramite il riutilizzo della connessione HTTP/2 quando `CONFIG proxy.config.http.parent_proxy_routing_enable` era impostato. |
|
||||
| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | Convalida 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à
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user