Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/

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

@@ -20,11 +20,11 @@ Questo consente a un utente di **modificare la prossima richiesta che arriva al
 **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 grandi dati vengono inviati in una serie di chunk.
+> Chunked significa che i dati di grandi dimensioni vengono inviati in una serie di chunk.
 
 ### Realtà
 
-Il **Front-End** (un load-balance / Reverse Proxy) **elabora** l'header _**content-length**_ o l'header _**transfer-encoding**_ e il server **Back-end** **elabora l'altro**, provocando una **desincronizzazione** tra i 2 sistemi.\
+Il **Front-End** (un load-balance / 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.\
 Questo potrebbe essere molto critico poiché **un attaccante sarà in grado di inviare una richiesta** al reverse proxy che sarà **interpretata** dal server **back-end** **come 2 richieste diverse**. Il **pericolo** di questa tecnica risiede nel fatto che il server **back-end** **interpreta** la **2ª richiesta iniettata** come se **venisse dal prossimo client** e la **vera richiesta** di quel client sarà **parte** della **richiesta iniettata**.
 
 ### Particolarità
@@ -38,22 +38,22 @@ Ricorda che in HTTP **un carattere di nuova riga è composto da 2 byte:**
 ## Esempi di Base
 
 > [!TIP]
-> Quando si cerca di sfruttare questo con Burp Suite **disabilitare `Update Content-Length` e `Normalize HTTP/1 line endings`** nel ripetitore perché alcuni gadget abusano di nuove righe, ritorni a capo e content-length malformati.
+> Quando si cerca di sfruttare questo con Burp Suite **disabilitare `Update Content-Length` e `Normalize HTTP/1 line endings`** nel ripetitore perché alcuni gadget abusano delle nuove righe, dei ritorni a capo e dei content-length malformati.
 
-Gli attacchi di HTTP request smuggling sono creati inviando richieste ambigue che sfruttano le discrepanze nel modo in cui i server 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 i server front-end e back-end danno priorità a questi header. Le vulnerabilità sorgono dal fatto che i server elaborano la stessa richiesta in modi diversi, portando a risultati inaspettati e potenzialmente dannosi.
+Gli attacchi di HTTP request smuggling sono creati inviando richieste ambigue che sfruttano le discrepanze nel modo in cui i server front-end e back-end interpretano le intestazioni `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 i server front-end e back-end danno priorità a queste intestazioni. Le vulnerabilità sorgono dal fatto che i server elaborano la stessa richiesta in modi diversi, portando a risultati imprevisti 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](../../images/EKi5edAUUAAIPIK.jpg)
 
-> [!NOTE]
+> [!TIP]
 > Alla tabella precedente dovresti aggiungere la tecnica TE.0, come la tecnica CL.0 ma utilizzando Transfer Encoding.
 
 #### Vulnerabilità CL.TE (Content-Length utilizzato dal Front-End, Transfer-Encoding utilizzato 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:**
+- **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, basandosi sul valore di `Content-Length`.
@@ -77,7 +77,7 @@ Foo: x
 
 - **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:**
+- **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.
@@ -105,10 +105,10 @@ x=
 #### Vulnerabilità TE.TE (Transfer-Encoding utilizzato da entrambi, con offuscamento)
 
 - **Server:** Entrambi supportano `Transfer-Encoding`, ma uno può essere ingannato a ignorarlo tramite offuscamento.
-- **Scenario di attacco:**
+- **Scenario di Attacco:**
 
 - L'attaccante invia una richiesta con intestazioni `Transfer-Encoding` offuscate.
-- A seconda di quale server (front-end o back-end) non riesce a riconoscere l'offuscamento, può essere sfruttata una vulnerabilità CL.TE o TE.CL.
+- A seconda di quale server (front-end o back-end) non riesce a riconoscere l'offuscamento, 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 a smuggling.
 - **Esempio:**
 
@@ -161,9 +161,9 @@ Non-Empty Body
 
 #### Scenario TE.0
 
-- Come il precedente ma utilizzando TE.
+- Come il precedente ma utilizzando TE
 - Tecnica [riportata qui](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
-- **Esempio:**
+- **Esempio**:
 ```
 OPTIONS / HTTP/1.1
 Host: {HOST}
@@ -273,17 +273,123 @@ Quando testi le vulnerabilità di request smuggling interferendo con altre richi
 
 - **Connessioni di Rete Distinte:** Le richieste "attacco" e "normali" 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 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 a URL e parametri. Allineare questi aumenta la probabilità che entrambe le richieste siano elaborate dallo stesso server, un prerequisito per un attacco riuscito.
-- **Timing e Condizioni di Gara:** La richiesta "normale", destinata a rilevare interferenze dalla richiesta "attacco", compete con altre richieste concorrenti dell'applicazione. Pertanto, invia la richiesta "normale" immediatamente dopo la richiesta "attacco". Applicazioni occupate potrebbero richiedere più tentativi per una conferma conclusiva della vulnerabilità.
+- **Timing 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 occupate potrebbero richiedere più tentativi per una conferma conclusiva della vulnerabilità.
 - **Sfide di Bilanciamento del Carico:** I server front-end che fungono da bilanciatori di carico possono distribuire le richieste su vari sistemi back-end. Se le richieste "attacco" e "normali" finiscono su sistemi diversi, l'attacco non avrà successo. Questo aspetto del bilanciamento del carico potrebbe richiedere diversi tentativi per confermare una vulnerabilità.
 - **Impatto Utente Non Intenzionale:** Se il tuo attacco influisce involontariamente sulla richiesta di un altro utente (non la richiesta "normale" che hai inviato per la rilevazione), questo indica che il tuo attacco ha influenzato un altro utente dell'applicazione. Test continui potrebbero interrompere altri utenti, richiedendo un approccio cauto.
 
-## Abusare di HTTP Request Smuggling
+## Distinguere gli artefatti di pipelining HTTP/1.1 da veri request smuggling
 
-### Eludere la Sicurezza Front-End tramite HTTP Request Smuggling
+Il riutilizzo delle connessioni (keep-alive) e il pipelining possono facilmente produrre illusioni di "smuggling" negli strumenti di test che inviano più richieste sullo stesso socket. Impara a separare artefatti innocui lato client da veri desync lato server.
 
-A volte, i proxy front-end applicano misure di sicurezza, esaminando le richieste in arrivo. Tuttavia, queste misure possono essere eluse sfruttando l'HTTP Request Smuggling, consentendo l'accesso non autorizzato a endpoint riservati. Ad esempio, l'accesso a `/admin` potrebbe essere vietato 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 contrabbandata, lasciando un'opportunità per bypassare queste restrizioni.
+### Perché il pipelining crea falsi positivi classici
 
-Considera i seguenti esempi che illustrano come l'HTTP Request Smuggling può essere utilizzato per eludere i controlli di sicurezza front-end, mirando specificamente al percorso `/admin` che è tipicamente protetto dal proxy front-end:
+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 è inviare due volte un payload malformato in stile CL.0 su una singola connessione:
+```
+POST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: Y
+```
+Le risposte possono apparire come:
+```
+HTTP/1.1 200 OK
+Content-Type: text/html
+
+```
+
+```
+HTTP/1.1 200 OK
+Content-Type: text/plain
+
+User-agent: *
+Disallow: /settings
+```
+Se il server ha ignorato il `Content_Length` malformato, non c'è desync FE↔BE. Con il riutilizzo, il tuo client ha effettivamente inviato questo byte-stream, che il server ha interpretato come due richieste indipendenti:
+```
+POST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: YPOST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: Y
+```
+Impatto: nessuno. Hai semplicemente desincronizzato il tuo client dal framing del server.
+
+> [!TIP]
+> Moduli Burp che dipendono da riutilizzo/pipelining: Turbo Intruder con `requestsPerConnection>1`, Intruder con "HTTP/1 connection reuse", Repeater "Invia gruppo in sequenza (connessione singola)" o "Abilita riutilizzo della connessione".
+
+### Test di litmus: pipelining o vera desincronizzazione?
+
+1. Disabilita il riutilizzo e ripeti il test
+- In Burp Intruder/Repeater, disattiva il riutilizzo HTTP/1 e evita "Invia gruppo in sequenza".
+- In Turbo Intruder, imposta `requestsPerConnection=1` e `pipeline=False`.
+- Se il comportamento scompare, era probabilmente un pipelining lato client, a meno che tu non stia trattando con obiettivi bloccati dalla connessione/stateless o desincronizzazione lato client.
+2. Controllo della risposta annidata HTTP/2
+- Invia una richiesta HTTP/2. Se il corpo della risposta contiene una risposta HTTP/1 annidata completa, hai dimostrato un bug di parsing/desincronizzazione del backend invece di un puro artefatto client.
+3. Prova di richieste parziali per front-end bloccati dalla connessione
+- Alcuni FE riutilizzano solo la connessione BE upstream se il client ha riutilizzato la propria. Usa richieste parziali per rilevare il comportamento del FE che rispecchia il riutilizzo del client.
+- Vedi PortSwigger "Browser‑Powered Desync Attacks" per la tecnica bloccata dalla connessione.
+4. Prove di stato
+- Cerca differenze tra la prima richiesta e le richieste successive sulla stessa connessione TCP (routing/validazione della prima richiesta).
+- Burp "HTTP Request Smuggler" include una prova di stato della connessione che automatizza questo.
+5. Visualizza il wire
+- Usa l'estensione Burp "HTTP Hacker" per ispezionare la concatenazione e il framing dei messaggi direttamente mentre sperimenti con il riutilizzo e le richieste parziali.
+
+### Smuggling di richieste bloccate dalla connessione (riutilizzo richiesto)
+
+Alcuni front-end riutilizzano solo la connessione upstream quando il client riutilizza la propria. Esiste un vero smuggling ma è condizionato al riutilizzo lato client. Per distinguere e dimostrare l'impatto:
+- Prova il bug lato server
+- Usa il controllo della risposta annidata HTTP/2, oppure
+- Usa richieste parziali per mostrare che il FE riutilizza solo upstream quando lo fa il client.
+- Mostra un impatto reale anche se l'abuso diretto del socket cross-user è bloccato:
+- Avvelenamento della cache: avvelena le cache condivise tramite la desincronizzazione in modo che le risposte influenzino altri utenti.
+- Divulgazione di intestazioni interne: riflette le intestazioni iniettate dal FE (ad es., intestazioni di autenticazione/fiducia) e passa al bypass dell'autenticazione.
+- Bypass dei controlli del FE: smuggla percorsi/metodi riservati oltre il front-end.
+- Abuso dell'intestazione host: combina con stranezze di routing dell'host per passare a vhosts interni.
+- Flusso di lavoro dell'operatore
+- Riproduci con riutilizzo controllato (Turbo Intruder `requestsPerConnection=2`, o gruppo della scheda Burp Repeater → "Invia gruppo in sequenza (connessione singola)").
+- Quindi collega a primitive di avvelenamento della cache/intestazione-leak/bypass-controllo e dimostra l'impatto cross-user o di autorizzazione.
+
+> Vedi anche attacchi di stato della connessione, che sono strettamente correlati ma non tecnicamente smuggling:
+>
+>{{#ref}}
+>../http-connection-request-smuggling.md
+>{{#endref}}
+
+### Vincoli di desincronizzazione lato client
+
+Se stai mirando a desincronizzazione lato client/Browser-powered, la richiesta malevola deve essere inviabile da un browser cross-origin. I trucchi di offuscamento delle intestazioni non funzioneranno. Concentrati su primitive raggiungibili tramite navigazione/fetch, e poi passa all'avvelenamento della cache, divulgazione delle intestazioni o bypass dei controlli del front-end dove i componenti downstream riflettono o memorizzano le risposte.
+
+Per background e flussi di lavoro end-to-end:
+
+{{#ref}}
+-browser-http-request-smuggling.md
+{{#endref}}
+
+### Strumenti per aiutare a decidere
+
+- HTTP Hacker (Burp BApp Store): espone il comportamento HTTP a basso livello e la concatenazione dei socket.
+- "Smuggling o pipelining?" Azione personalizzata Burp Repeater: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
+- Turbo Intruder: controllo preciso sul riutilizzo della connessione tramite `requestsPerConnection`.
+- Burp HTTP Request Smuggler: include una prova di stato della connessione per individuare il routing/validazione della prima richiesta.
+
+> [!NOTE]
+> Tratta gli effetti di solo riutilizzo come non problematici a meno che tu non possa dimostrare la desincronizzazione lato server e allegare un impatto concreto (artefatto di cache avvelenato, intestazione interna trapelata che consente il bypass dei privilegi, controllo del FE bypassato, ecc.).
+
+## Abusare dello Smuggling di Richieste HTTP
+
+### Eludere la Sicurezza del Front-End tramite Smuggling di Richieste HTTP
+
+A volte, i proxy del front-end applicano misure di sicurezza, esaminando le richieste in arrivo. Tuttavia, queste misure possono essere eluse sfruttando lo Smuggling di Richieste HTTP, consentendo l'accesso non autorizzato a endpoint riservati. Ad esempio, l'accesso a `/admin` potrebbe essere vietato esternamente, con il proxy del 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 scappatoia per bypassare queste restrizioni.
+
+Considera i seguenti esempi che illustrano come lo Smuggling di Richieste HTTP possa essere utilizzato per eludere i controlli di sicurezza del front-end, mirati specificamente al percorso `/admin` che è tipicamente protetto dal proxy del front-end:
 
 **Esempio CL.TE**
 ```
@@ -302,7 +408,7 @@ 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 riesce a ispezionare la richiesta incorporata `GET /admin`, consentendo l'accesso non autorizzato al percorso `/admin`.
+Nell'attacco CL.TE, l'intestazione `Content-Length` viene sfruttata per la richiesta iniziale, mentre la successiva richiesta incorporata utilizza l'intestazione `Transfer-Encoding: chunked`. Il proxy front-end elabora la richiesta `POST` iniziale ma non riesce a ispezionare la richiesta incorporata `GET /admin`, consentendo l'accesso non autorizzato al percorso `/admin`.
 
 **Esempio TE.CL**
 ```
@@ -322,11 +428,11 @@ a=x
 ```
 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`. Simile all'attacco CL.TE, il proxy front-end ignora la richiesta `GET /admin` contrabbandata, concedendo involontariamente accesso al percorso riservato `/admin`.
 
-### Rivelare la riscrittura delle richieste front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Rivelazione della riscrittura delle richieste 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 arrivo prima di passarle al server back-end. Una modifica tipica comporta 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 **bypassare le protezioni** o **scoprire informazioni o endpoint nascosti**.
 
-Per indagare su come un proxy altera una richiesta, trova un parametro POST che il back-end restituisce nella risposta. Quindi, crea una richiesta, utilizzando questo parametro per ultimo, simile al seguente:
+Per indagare su come un proxy altera una richiesta, individua un parametro POST che il back-end restituisce nella risposta. Quindi, crea una richiesta, utilizzando questo parametro per ultimo, simile al seguente:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -379,7 +485,7 @@ In questo scenario, il **parametro commento** è destinato a memorizzare i conte
 
 Tuttavia, questa tecnica ha delle limitazioni. In generale, cattura i dati solo fino al delimitatore del parametro utilizzato nella richiesta smuggled. 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, vale la pena notare che questo approccio è anche valido 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.
+Inoltre, vale la pena notare che questo approccio è anche valido con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe concludersi con `search=\r\n0`. Indipendentemente dai caratteri di nuova linea, i valori verranno aggiunti al parametro di ricerca.
 
 ### Utilizzare l'HTTP request smuggling per sfruttare il XSS riflesso
 
@@ -415,16 +521,16 @@ Questo payload è strutturato per sfruttare la vulnerabilità tramite:
 2. Seguire con un `0`, che segna la fine del corpo del messaggio chunked.
 3. Poi, viene introdotta una richiesta `GET` smuggled, dove l'intestazione `User-Agent` è iniettata con uno script, `<script>alert(1)</script>`, attivando l'XSS quando il server elabora questa richiesta successiva.
 
-Manipolando il `User-Agent` tramite smuggling, il payload elude 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 bypassa i normali vincoli delle richieste, sfruttando così la vulnerabilità XSS Riflessa in modo non standard ma efficace.
 
 #### HTTP/0.9
 
 > [!CAUTION]
-> Nel caso in cui il contenuto dell'utente venga riflesso in una risposta con un **`Content-type`** come **`text/plain`**, impedendo l'esecuzione dell'XSS. Se il server supporta **HTTP/0.9 potrebbe essere possibile eludere questo**!
+> Nel caso in cui il contenuto dell'utente venga riflesso in una risposta con un **`Content-type`** come **`text/plain`**, impedendo l'esecuzione dell'XSS. Se il server supporta **HTTP/0.9 potrebbe essere possibile bypassare questo**!
 
 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 writeup**](https://mizu.re/post/twisty-python), questo è stato abusato con uno smuggling di richieste e un **endpoint vulnerabile che risponderà con l'input dell'utente** per smuggler 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`.
+In [**questo writeup**](https://mizu.re/post/twisty-python), questo è stato abusato con uno smuggling di richieste e un **endpoint vulnerabile che risponderà con l'input dell'utente** per smuggler una richiesta con HTTP/0.9. Il parametro che verrà riflesso nella risposta conteneva una **falsa risposta HTTP/1.1 (con intestazioni e corpo)** in modo che la risposta contenga codice JS eseguibile valido con un `Content-Type` di `text/html`.
 
 ### Sfruttare i reindirizzamenti in loco con HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
 
@@ -452,7 +558,7 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Questa richiesta di smuggling potrebbe causare la reindirizzazione della prossima richiesta dell'utente elaborata a un sito web controllato dall'attaccante:
+Questa richiesta di smuggling potrebbe causare la reindirizzazione della prossima richiesta utente elaborata a un sito web controllato dall'attaccante:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
@@ -470,7 +576,7 @@ In questo scenario, la richiesta di un utente per un file JavaScript viene dirot
 
 Il web cache poisoning può essere eseguito se 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**.
 
-In precedenza, abbiamo osservato come le risposte del server potessero essere modificate per restituire un errore 404 (fare riferimento a [Esempi di Base](#basic-examples)). Allo stesso modo, è possibile ingannare il server per 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, potenzialmente portando a un Denial of Service (DoS).
+In precedenza, abbiamo osservato come le risposte del server potessero essere modificate per restituire un errore 404 (fare riferimento a [Basic Examples](#basic-examples)). Allo stesso modo, è possibile ingannare il server per 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, potenzialmente portando a un Denial of Service (DoS).
 
 Questa tecnica diventa particolarmente potente se viene scoperta una **vulnerabilità di Open Redirect** o se c'è un **reindirizzamento in loco a un 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, abilitando essenzialmente un attacco Cross-Site Scripting (XSS) diffuso contro tutti i client che richiedono il `/static/include.js` aggiornato.
 
@@ -496,14 +602,14 @@ Nota la richiesta incorporata che mira a `/post/next?postId=3`. Questa richiesta
 
 Dopo un **avvelenamento del socket** riuscito, dovrebbe essere avviata una **richiesta GET** per `/static/include.js`. Questa richiesta sarà contaminata dalla precedente richiesta di **reindirizzamento in loco a reindirizzamento aperto** e recupererà il contenuto dello script controllato dall'attaccante.
 
-Successivamente, qualsiasi richiesta per `/static/include.js` servirà 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, avviando efficacemente un ampio attacco XSS.
 
-### Utilizzare l'HTTP request smuggling per eseguire la deception 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>
+### Utilizzare l'HTTP request smuggling per eseguire la 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 avvelenamento della cache web e deception della cache web?**
+> **Qual è la differenza tra avvelenamento della cache web e inganno della cache web?**
 >
-> - Nell'**avvelenamento della cache web**, l'attaccante costringe l'applicazione a memorizzare del contenuto dannoso nella cache, e questo contenuto viene servito dalla cache ad altri utenti dell'applicazione.
-> - Nella **deception della cache web**, l'attaccante costringe l'applicazione a memorizzare del contenuto sensibile appartenente a un altro utente nella cache, e l'attaccante poi recupera questo contenuto dalla cache.
+> - Nell'**avvelenamento della cache web**, l'attaccante costringe l'applicazione a memorizzare del contenuto malevolo nella cache, e questo contenuto viene servito dalla cache ad altri utenti dell'applicazione.
+> - Nell'**inganno della cache web**, l'attaccante costringe l'applicazione a memorizzare del contenuto sensibile appartenente a un altro utente nella cache, e l'attaccante poi recupera questo contenuto dalla cache.
 
 L'attaccante crea una richiesta smuggled che recupera contenuti sensibili specifici per l'utente. Considera il seguente esempio:
 ```markdown
@@ -539,11 +645,11 @@ X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
 Un esempio su come abusare di questo comportamento sarebbe **smuggler prima una richiesta HEAD**. Questa richiesta verrà risposta solo con le **intestazioni** di una richiesta GET (**`Content-Type`** tra esse). E smuggler **immediatamente dopo la HEAD una richiesta TRACE**, che rifletterà i dati inviati.\
 Poiché la risposta HEAD conterrà un'intestazione `Content-Length`, la **risposta della richiesta TRACE sarà trattata come il corpo della risposta HEAD, riflettendo quindi dati arbitrari** nella risposta.\
-Questa risposta sarà inviata alla richiesta successiva sulla connessione, quindi potrebbe essere **utilizzata in un file JS memorizzato nella cache, ad esempio, per iniettare codice JS arbitrario**.
+Questa risposta sarà inviata alla richiesta successiva attraverso la connessione, quindi potrebbe essere **utilizzata in un file JS memorizzato nella cache, ad esempio, per iniettare codice JS arbitrario**.
 
 ### Abusare di TRACE tramite HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-Continuare seguendo [**questo post**](https://portswigger.net/research/trace-desync-attack) è suggerito un altro modo per abusare del metodo TRACE. Come commentato, smuggler una richiesta HEAD e una richiesta TRACE rende possibile **controllare alcuni dati riflessi** nella risposta alla richiesta HEAD. La lunghezza del corpo della richiesta HEAD è fondamentalmente indicata nell'intestazione Content-Length ed è formata dalla risposta alla richiesta TRACE.
+Continuare seguendo [**questo post**](https://portswigger.net/research/trace-desync-attack) è suggerito un altro modo per abusare del metodo TRACE. Come commentato, smuggler una richiesta HEAD e una richiesta TRACE è possibile **controllare alcuni dati riflessi** nella risposta alla richiesta HEAD. La lunghezza del corpo della richiesta HEAD è fondamentalmente indicata nell'intestazione Content-Length ed è formata dalla risposta alla richiesta TRACE.
 
 Pertanto, la nuova idea sarebbe che, conoscendo questo Content-Length e i dati forniti nella risposta TRACE, è possibile far sì che la risposta TRACE contenga una risposta HTTP valida dopo l'ultimo byte del Content-Length, consentendo a un attaccante di controllare completamente la richiesta alla risposta successiva (che potrebbe essere utilizzata per eseguire un avvelenamento della cache).
 
@@ -566,7 +672,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 corpo HEAD e una volta che il Content-Length HEAD termina, una risposta HTTP valida viene smugglerata):
+Genererà queste risposte (nota come la risposta HEAD ha un Content-Length che rende la risposta TRACE parte del corpo HEAD e una volta che il Content-Length HEAD termina, una risposta HTTP valida viene nascosta):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -698,6 +804,8 @@ table.add(req)
 ```
 ## Strumenti
 
+- HTTP Hacker (Burp BApp Store) – visualizza la concatenazione/framing e il comportamento HTTP a basso livello
+- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Azione personalizzata Burp Repeater "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)
@@ -716,6 +824,10 @@ 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/)
+- Fai attenzione al falso positivo: come distinguere l'HTTP pipelining dal 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/)
+- Attacchi Desync alimentati dal browser – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- PortSwigger Academy – desync lato client – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
 
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md

@@ -2,6 +2,22 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-**Controlla il post [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
+Il desync alimentato dal browser (noto anche come client-side request smuggling) sfrutta il browser della vittima per accodare una richiesta malformata su una connessione condivisa in modo che le richieste successive vengano analizzate in modo non sincronizzato da un componente a valle. A differenza dello smuggling classico FE↔BE, i payload sono limitati da ciò che un browser può legalmente inviare cross-origin.
+
+Key constraints and tips
+- Utilizzare solo intestazioni e sintassi che un browser può emettere tramite navigazione, fetch o invio di moduli. Le offuscazioni delle intestazioni (trucchi LWS, TE duplicati, CL non validi) generalmente non verranno inviate.
+- Target endpoints and intermediaries that reflect inputs or cache responses. Gli impatti utili includono il poisoning della cache, la fuga di intestazioni iniettate nel front-end o il bypass dei controlli di percorso/metodo del front-end.
+- Reuse matters: allineare la richiesta creata in modo che condivida la stessa connessione HTTP/1.1 o H2 di una richiesta di vittima ad alto valore. I comportamenti bloccati dalla connessione/statali amplificano l'impatto.
+- Preferire primitive che non richiedono intestazioni personalizzate: confusione del percorso, iniezione di query-string e modellamento del corpo tramite POST codificati in modulo.
+- Validare il vero desync lato server rispetto ai semplici artefatti di pipelining ripetendo il test senza riutilizzo o utilizzando il controllo della risposta annidata HTTP/2.
+
+For end-to-end techniques and PoCs see:
+- PortSwigger Research – Browser‑Powered Desync Attacks: https://portswigger.net/research/browser-powered-desync-attacks
+- PortSwigger Academy – client‑side desync: https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
+
+## References
+- [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
+- Distinguishing pipelining vs smuggling (background on reuse false-positives): https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
 
 {{#include ../../banners/hacktricks-training.md}}