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

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

@@ -25,7 +25,7 @@ Questo consente a un utente di **modificare la prossima richiesta che arriva al
 ### Realtà
 
 Il **Front-End** (un load-balance / Reverse Proxy) **elabora** l'intestazione _**content-length**_ o l'intestazione _**transfer-encoding**_ e il server **Back-end** **elabora l'altra**, provocando una **desincronizzazione** tra i 2 sistemi.\
-Questo potrebbe essere molto critico poiché **un attaccante sarà in grado di inviare una richiesta** al reverse proxy che sarà **interpretata** dal server **back-end** **come 2 richieste diverse**. Il **pericolo** di questa tecnica risiede nel fatto che il server **back-end** **interpreta** la **2ª richiesta iniettata** come se **venisse dal prossimo client** e la **vera richiesta** di quel client sarà **parte** della **richiesta iniettata**.
+Questo potrebbe essere molto critico poiché **un attaccante sarà in grado di inviare una richiesta** al reverse proxy che sarà **interpretata** dal server **back-end** **come 2 richieste diverse**. Il **pericolo** di questa tecnica risiede nel fatto che il server **back-end** **interpreta** la **2ª richiesta iniettata** come se **provenisse dal prossimo client** e la **vera richiesta** di quel client sarà **parte** della **richiesta iniettata**.
 
 ### Particolarità
 
@@ -256,28 +256,28 @@ X
 
 - **Analisi delle Risposte Differenziali:**
 - Invia versioni leggermente variate di una richiesta e osserva se le risposte del server differiscono in modo inaspettato, indicando una discrepanza di parsing.
-- **Utilizzo di Strumenti Automatizzati:**
+- **Utilizzo di Strumenti Automatici:**
 - Strumenti come l'estensione 'HTTP Request Smuggler' di Burp Suite possono testare automaticamente queste vulnerabilità inviando varie forme di richieste ambigue e analizzando le risposte.
-- **Test di Variazione del Content-Length:**
+- **Test di Variazione di Content-Length:**
 - Invia richieste con valori di `Content-Length` variabili che non sono allineati con la lunghezza effettiva del contenuto e osserva come il server gestisce tali discrepanze.
-- **Test di Variazione del Transfer-Encoding:**
+- **Test di Variazione di Transfer-Encoding:**
 - Invia richieste con header `Transfer-Encoding` offuscati o malformati e monitora come i server front-end e back-end rispondono in modo diverso a tali manipolazioni.
 
 ### Test di Vulnerabilità di HTTP Request Smuggling
 
-Dopo aver confermato l'efficacia delle tecniche di timing, è fondamentale verificare se le richieste del client possono essere manipolate. Un metodo semplice è tentare di avvelenare le tue richieste, ad esempio, facendo in modo che una richiesta a `/` restituisca una risposta 404. Gli esempi `CL.TE` e `TE.CL` precedentemente discussi in [Esempi di Base](#basic-examples) dimostrano come avvelenare una richiesta del client per ottenere una risposta 404, nonostante il client stia cercando di accedere a una risorsa diversa.
+Dopo aver confermato l'efficacia delle tecniche di timing, è fondamentale verificare se le richieste del client possono essere manipolate. Un metodo semplice è tentare di avvelenare le tue richieste, ad esempio, facendo in modo che una richiesta a `/` restituisca una risposta 404. Gli esempi `CL.TE` e `TE.CL` precedentemente discussi in [Esempi di Base](#basic-examples) dimostrano come avvelenare una richiesta del client per ottenere una risposta 404, nonostante il client miri ad accedere a una risorsa diversa.
 
 **Considerazioni Chiave**
 
-Quando testi le vulnerabilità di request smuggling interferendo con altre richieste, tieni a mente:
+Quando testi per vulnerabilità di request smuggling interferendo con altre richieste, tieni a mente:
 
 - **Connessioni di Rete Distinte:** Le richieste "attacco" e "normali" dovrebbero essere inviate su connessioni di rete separate. Utilizzare la stessa connessione per entrambe non convalida la presenza della vulnerabilità.
 - **URL e Parametri Coerenti:** Cerca di utilizzare URL e nomi di parametri identici per entrambe le richieste. Le applicazioni moderne spesso instradano le richieste a server back-end specifici in base a URL e parametri. Allineare questi aumenta la probabilità che entrambe le richieste siano elaborate dallo stesso server, un prerequisito per un attacco riuscito.
-- **Timing e Condizioni di Gara:** La richiesta "normale", destinata a rilevare interferenze dalla richiesta "attacco", compete con altre richieste dell'applicazione concorrenti. Pertanto, invia la richiesta "normale" immediatamente dopo la richiesta "attacco". Applicazioni occupate potrebbero richiedere più tentativi per una conferma conclusiva della vulnerabilità.
+- **Timing e Condizioni di Gara:** La richiesta "normale", destinata a rilevare interferenze dalla richiesta "attacco", compete con altre richieste concorrenti dell'applicazione. Pertanto, invia la richiesta "normale" immediatamente dopo la richiesta "attacco". Applicazioni occupate potrebbero richiedere più tentativi per una conferma conclusiva della vulnerabilità.
 - **Sfide di Bilanciamento del Carico:** I server front-end che fungono da bilanciatori di carico possono distribuire le richieste su vari sistemi back-end. Se le richieste "attacco" e "normali" finiscono su sistemi diversi, l'attacco non avrà successo. Questo aspetto del bilanciamento del carico potrebbe richiedere diversi tentativi per confermare una vulnerabilità.
 - **Impatto Utente Non Intenzionale:** Se il tuo attacco influisce involontariamente sulla richiesta di un altro utente (non la richiesta "normale" che hai inviato per la rilevazione), questo indica che il tuo attacco ha influenzato un altro utente dell'applicazione. Test continui potrebbero interrompere altri utenti, richiedendo un approccio cauto.
 
-## Distinguere gli artefatti di pipelining HTTP/1.1 da veri request smuggling
+## Distinguere gli artefatti di pipelining HTTP/1.1 da un vero request smuggling
 
 Il riutilizzo delle connessioni (keep-alive) e il pipelining possono facilmente produrre illusioni di "smuggling" negli strumenti di test che inviano più richieste sullo stesso socket. Impara a separare artefatti innocui lato client da veri desync lato server.
 
@@ -320,7 +320,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impatto: nessuno. Hai semplicemente desincronizzato il tuo client dal framing del server.
+Impact: nessuno. Hai semplicemente desincronizzato il tuo client dal framing del server.
 
 > [!TIP]
 > Moduli Burp che dipendono da riutilizzo/pipelining: Turbo Intruder con `requestsPerConnection>1`, Intruder con "HTTP/1 connection reuse", Repeater "Invia gruppo in sequenza (connessione singola)" o "Abilita riutilizzo della connessione".
@@ -330,7 +330,7 @@ Impatto: nessuno. Hai semplicemente desincronizzato il tuo client dal framing de
 1. Disabilita il riutilizzo e ripeti il test
 - In Burp Intruder/Repeater, disattiva il riutilizzo HTTP/1 e evita "Invia gruppo in sequenza".
 - In Turbo Intruder, imposta `requestsPerConnection=1` e `pipeline=False`.
-- Se il comportamento scompare, era probabilmente un pipelining lato client, a meno che tu non stia trattando con obiettivi bloccati dalla connessione/stateless o desincronizzazione lato client.
+- Se il comportamento scompare, era probabilmente un pipelining lato client, a meno che tu non stia trattando con obiettivi bloccati dalla connessione/statali o desincronizzazione lato client.
 2. Controllo della risposta annidata HTTP/2
 - Invia una richiesta HTTP/2. Se il corpo della risposta contiene una risposta HTTP/1 annidata completa, hai dimostrato un bug di parsing/desincronizzazione del backend invece di un puro artefatto client.
 3. Prova di richieste parziali per front-end bloccati dalla connessione
@@ -338,16 +338,16 @@ Impatto: nessuno. Hai semplicemente desincronizzato il tuo client dal framing de
 - Vedi PortSwigger "Browser‑Powered Desync Attacks" per la tecnica bloccata dalla connessione.
 4. Prove di stato
 - Cerca differenze tra la prima richiesta e le richieste successive sulla stessa connessione TCP (routing/validazione della prima richiesta).
-- Burp "HTTP Request Smuggler" include una prova di stato della connessione che automatizza questo.
+- Burp "HTTP Request Smuggler" include una sonda di stato della connessione che automatizza questo.
 5. Visualizza il wire
 - Usa l'estensione Burp "HTTP Hacker" per ispezionare la concatenazione e il framing dei messaggi direttamente mentre sperimenti con il riutilizzo e le richieste parziali.
 
-### Smuggling di richieste bloccate dalla connessione (riutilizzo richiesto)
+### Smuggling di richieste bloccato dalla connessione (riutilizzo richiesto)
 
 Alcuni front-end riutilizzano solo la connessione upstream quando il client riutilizza la propria. Esiste un vero smuggling ma è condizionato al riutilizzo lato client. Per distinguere e dimostrare l'impatto:
 - Prova il bug lato server
 - Usa il controllo della risposta annidata HTTP/2, oppure
-- Usa richieste parziali per mostrare che il FE riutilizza solo upstream quando lo fa il client.
+- Usa richieste parziali per mostrare che il FE riutilizza solo l'upstream quando lo fa il client.
 - Mostra un impatto reale anche se l'abuso diretto del socket cross-user è bloccato:
 - Avvelenamento della cache: avvelena le cache condivise tramite la desincronizzazione in modo che le risposte influenzino altri utenti.
 - Divulgazione di intestazioni interne: riflette le intestazioni iniettate dal FE (ad es., intestazioni di autenticazione/fiducia) e passa al bypass dell'autenticazione.
@@ -365,12 +365,12 @@ Alcuni front-end riutilizzano solo la connessione upstream quando il client riut
 
 ### Vincoli di desincronizzazione lato client
 
-Se stai mirando a desincronizzazione lato client/Browser-powered, la richiesta malevola deve essere inviabile da un browser cross-origin. I trucchi di offuscamento delle intestazioni non funzioneranno. Concentrati su primitive raggiungibili tramite navigazione/fetch, e poi passa all'avvelenamento della cache, divulgazione delle intestazioni o bypass dei controlli del front-end dove i componenti downstream riflettono o memorizzano le risposte.
+Se stai mirando a desincronizzazione lato client/da browser, la richiesta malevola deve essere inviabile da un browser cross-origin. I trucchi di offuscamento delle intestazioni non funzioneranno. Concentrati su primitive raggiungibili tramite navigazione/fetch, e poi passa all'avvelenamento della cache, divulgazione delle intestazioni o bypass dei controlli del front-end dove i componenti downstream riflettono o memorizzano le risposte.
 
 Per background e flussi di lavoro end-to-end:
 
 {{#ref}}
--browser-http-request-smuggling.md
+browser-http-request-smuggling.md
 {{#endref}}
 
 ### Strumenti per aiutare a decidere
@@ -378,10 +378,10 @@ Per background e flussi di lavoro end-to-end:
 - HTTP Hacker (Burp BApp Store): espone il comportamento HTTP a basso livello e la concatenazione dei socket.
 - "Smuggling o pipelining?" Azione personalizzata Burp Repeater: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
 - Turbo Intruder: controllo preciso sul riutilizzo della connessione tramite `requestsPerConnection`.
-- Burp HTTP Request Smuggler: include una prova di stato della connessione per individuare il routing/validazione della prima richiesta.
+- Burp HTTP Request Smuggler: include una sonda di stato della connessione per individuare il routing/validazione della prima richiesta.
 
 > [!NOTE]
-> Tratta gli effetti di solo riutilizzo come non problematici a meno che tu non possa dimostrare la desincronizzazione lato server e allegare un impatto concreto (artefatto di cache avvelenato, intestazione interna trapelata che consente il bypass dei privilegi, controllo del FE bypassato, ecc.).
+> Tratta gli effetti di solo riutilizzo come non problemi a meno che tu non possa dimostrare la desincronizzazione lato server e allegare un impatto concreto (artefatto di cache avvelenato, intestazione interna trapelata che consente il bypass dei privilegi, controllo del FE bypassato, ecc.).
 
 ## Abusare dello Smuggling di Richieste HTTP
 
@@ -389,7 +389,7 @@ Per background e flussi di lavoro end-to-end:
 
 A volte, i proxy del front-end applicano misure di sicurezza, esaminando le richieste in arrivo. Tuttavia, queste misure possono essere eluse sfruttando lo Smuggling di Richieste HTTP, consentendo l'accesso non autorizzato a endpoint riservati. Ad esempio, l'accesso a `/admin` potrebbe essere vietato esternamente, con il proxy del front-end che blocca attivamente tali tentativi. Tuttavia, questo proxy potrebbe trascurare di ispezionare le richieste incorporate all'interno di una richiesta HTTP smuggled, lasciando una scappatoia per bypassare queste restrizioni.
 
-Considera i seguenti esempi che illustrano come lo Smuggling di Richieste HTTP possa essere utilizzato per eludere i controlli di sicurezza del front-end, mirati specificamente al percorso `/admin` che è tipicamente protetto dal proxy del front-end:
+Considera i seguenti esempi che illustrano come lo Smuggling di Richieste HTTP può essere utilizzato per eludere i controlli di sicurezza del front-end, specificamente prendendo di mira il percorso `/admin` che è tipicamente protetto dal proxy del front-end:
 
 **Esempio CL.TE**
 ```
@@ -408,9 +408,9 @@ Content-Length: 10
 
 x=
 ```
-Nell'attacco CL.TE, l'intestazione `Content-Length` viene sfruttata per la richiesta iniziale, mentre la successiva richiesta incorporata utilizza l'intestazione `Transfer-Encoding: chunked`. Il proxy front-end elabora la richiesta `POST` iniziale ma non riesce a ispezionare la richiesta incorporata `GET /admin`, consentendo l'accesso non autorizzato al percorso `/admin`.
+Nell'attacco CL.TE, l'intestazione `Content-Length` viene sfruttata per la richiesta iniziale, mentre la successiva richiesta incorporata utilizza l'intestazione `Transfer-Encoding: chunked`. Il proxy front-end elabora la richiesta `POST` iniziale ma non riesce a ispezionare la richiesta `GET /admin` incorporata, consentendo l'accesso non autorizzato al percorso `/admin`.
 
-**Esempio TE.CL**
+**TE.CL Esempio**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@@ -428,11 +428,11 @@ a=x
 ```
 Al contrario, nell'attacco TE.CL, la richiesta iniziale `POST` utilizza `Transfer-Encoding: chunked`, e la successiva richiesta incorporata viene elaborata in base all'intestazione `Content-Length`. Simile all'attacco CL.TE, il proxy front-end ignora la richiesta `GET /admin` contrabbandata, concedendo involontariamente accesso al percorso riservato `/admin`.
 
-### Rivelazione della riscrittura delle richieste front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Rivelare la riscrittura delle richieste front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
 
 Le applicazioni spesso impiegano un **server front-end** per modificare le richieste in arrivo prima di passarle al server back-end. Una modifica tipica comporta l'aggiunta di intestazioni, come `X-Forwarded-For: <IP del client>`, per trasmettere l'IP del client al back-end. Comprendere queste modifiche può essere cruciale, poiché potrebbe rivelare modi per **bypassare le protezioni** o **scoprire informazioni o endpoint nascosti**.
 
-Per indagare su come un proxy altera una richiesta, individua un parametro POST che il back-end restituisce nella risposta. Quindi, crea una richiesta, utilizzando questo parametro per ultimo, simile al seguente:
+Per indagare su come un proxy altera una richiesta, trova un parametro POST che il back-end restituisce nella risposta. Quindi, crea una richiesta, utilizzando questo parametro per ultimo, simile al seguente:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -455,7 +455,7 @@ In questa struttura, i componenti della richiesta successiva vengono aggiunti do
 
 Questa tecnica è applicabile anche nel contesto di una vulnerabilità TE.CL, ma la richiesta dovrebbe terminare con `search=\r\n0`. Indipendentemente dai caratteri di nuova riga, i valori verranno aggiunti al parametro di ricerca.
 
-Questo metodo serve principalmente a comprendere le modifiche alla richiesta effettuate dal proxy front-end, eseguendo essenzialmente un'indagine autodiretta.
+Questo metodo serve principalmente a comprendere le modifiche alla richiesta effettuate dal proxy front-end, eseguendo essenzialmente un'indagine autonoma.
 
 ### Catturare le richieste di altri utenti <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
 
@@ -485,7 +485,7 @@ In questo scenario, il **parametro commento** è destinato a memorizzare i conte
 
 Tuttavia, questa tecnica ha delle limitazioni. In generale, cattura i dati solo fino al delimitatore del parametro utilizzato nella richiesta smuggled. Per le sottomissioni di moduli codificati in URL, questo delimitatore è il carattere `&`. Ciò significa che il contenuto catturato dalla richiesta dell'utente vittima si fermerà al primo `&`, che potrebbe anche far parte della stringa di query.
 
-Inoltre, vale la pena notare che questo approccio è anche valido con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe concludersi con `search=\r\n0`. Indipendentemente dai caratteri di nuova linea, i valori verranno aggiunti al parametro di ricerca.
+Inoltre, vale la pena notare che questo approccio è anche valido con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe concludersi con `search=\r\n0`. Indipendentemente dai caratteri di nuova riga, i valori verranno aggiunti al parametro di ricerca.
 
 ### Utilizzare l'HTTP request smuggling per sfruttare il XSS riflesso
 
@@ -598,11 +598,11 @@ Content-Length: 10
 
 x=1
 ```
-Nota la richiesta incorporata che mira a `/post/next?postId=3`. Questa richiesta verrà reindirizzata a `/post?postId=4`, utilizzando il **valore dell'intestazione Host** per determinare il dominio. Alterando l'**intestazione Host**, l'attaccante può reindirizzare la richiesta al proprio dominio (**reindirizzamento in loco a reindirizzamento aperto**).
+Nota la richiesta incorporata che mira a `/post/next?postId=3`. Questa richiesta verrà reindirizzata a `/post?postId=4`, utilizzando il **valore dell'intestazione Host** per determinare il dominio. Alterando il **valore dell'intestazione Host**, l'attaccante può reindirizzare la richiesta al proprio dominio (**reindirizzamento in loco a reindirizzamento aperto**).
 
 Dopo un **avvelenamento del socket** riuscito, dovrebbe essere avviata una **richiesta GET** per `/static/include.js`. Questa richiesta sarà contaminata dalla precedente richiesta di **reindirizzamento in loco a reindirizzamento aperto** e recupererà il contenuto dello script controllato dall'attaccante.
 
-Successivamente, qualsiasi richiesta per `/static/include.js` servirà il contenuto memorizzato nella cache dello script dell'attaccante, avviando efficacemente un ampio attacco XSS.
+Successivamente, qualsiasi richiesta per `/static/include.js` servirà il contenuto memorizzato nella cache dello script dell'attaccante, lanciando efficacemente un ampio attacco XSS.
 
 ### Utilizzare l'HTTP request smuggling per eseguire la web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
 
@@ -611,7 +611,7 @@ Successivamente, qualsiasi richiesta per `/static/include.js` servirà il conten
 > - Nell'**avvelenamento della cache web**, l'attaccante costringe l'applicazione a memorizzare del contenuto malevolo nella cache, e questo contenuto viene servito dalla cache ad altri utenti dell'applicazione.
 > - Nell'**inganno della cache web**, l'attaccante costringe l'applicazione a memorizzare del contenuto sensibile appartenente a un altro utente nella cache, e l'attaccante poi recupera questo contenuto dalla cache.
 
-L'attaccante crea una richiesta smuggled che recupera contenuti sensibili specifici per l'utente. Considera il seguente esempio:
+L'attaccante crea una richiesta di contrabbando che recupera contenuti sensibili specifici per l'utente. Considera il seguente esempio:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@@ -645,7 +645,7 @@ X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
 Un esempio su come abusare di questo comportamento sarebbe **smuggler prima una richiesta HEAD**. Questa richiesta verrà risposta solo con le **intestazioni** di una richiesta GET (**`Content-Type`** tra esse). E smuggler **immediatamente dopo la HEAD una richiesta TRACE**, che rifletterà i dati inviati.\
 Poiché la risposta HEAD conterrà un'intestazione `Content-Length`, la **risposta della richiesta TRACE sarà trattata come il corpo della risposta HEAD, riflettendo quindi dati arbitrari** nella risposta.\
-Questa risposta sarà inviata alla richiesta successiva attraverso la connessione, quindi potrebbe essere **utilizzata in un file JS memorizzato nella cache, ad esempio, per iniettare codice JS arbitrario**.
+Questa risposta sarà inviata alla richiesta successiva attraverso la connessione, quindi potrebbe essere **utilizzata in un file JS memorizzato nella cache, ad esempio per iniettare codice JS arbitrario**.
 
 ### Abusare di TRACE tramite HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
@@ -824,7 +824,7 @@ table.add(req)
 - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
 - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
 - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
-- Fai attenzione al falso positivo: come distinguere l'HTTP pipelining dal request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- Attenzione al falso positivo: come distinguere l'HTTP pipelining dal request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
 - [https://http1mustdie.com/](https://http1mustdie.com/)
 - Attacchi Desync alimentati dal browser – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
 - PortSwigger Academy – desync lato client – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)