HTTP Request Smuggling / HTTP Desync Attack
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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 (bilanciamento del carico/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.
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.
Content-Length
L'intestazione dell'entità Content-Length indica la dimensione del corpo dell'entità, in byte, inviato al destinatario.
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.
Il Front-End (un bilanciatore di carico / 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 provenisse dal prossimo client e la vera richiesta di quel client sarà parte della richiesta iniettata.
Ricorda che in HTTP un carattere di nuova riga è 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, non è necessaria una nuova riga 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.
Quando si cerca di sfruttare questo con Burp Suite disabilitare Update Content-Length e Normalize HTTP/1 line endings nel ripetitore perché alcuni gadget abusano delle nuove righe, dei ritorni a capo e dei content-length malformati.
Gli attacchi di HTTP request smuggling sono creati inviando richieste ambigue che sfruttano le discrepanze nel modo in cui i server front-end e back-end interpretano 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 dai server che elaborano la stessa richiesta in modi diversi, portando a risultati imprevisti e potenzialmente dannosi.
Alla tabella precedente dovresti aggiungere la tecnica TE.0, come la tecnica CL.0 ma utilizzando Transfer Encoding.
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:
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.
Esempio:
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:
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.
Esempio:
Server: Entrambi supportano Transfer-Encoding, ma uno può essere ingannato a ignorarlo tramite offuscamento.
Scenario di attacco:
L'attaccante invia una richiesta con intestazioni Transfer-Encoding offuscate.
A seconda di quale server (front-end o back-end) non riesce a riconoscere l'offuscamento, può essere sfruttata una vulnerabilità CL.TE o TE.CL.
La parte non elaborata della richiesta, come vista da uno dei server, diventa parte di una richiesta successiva, portando a smuggling.
Esempio:
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.
Esempio:
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.
Esempio:
Come il precedente ma utilizzando TE
Tecnica riportata qui
Esempio:
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.
Ad esempio, come spiegato in questo writeup, in Werkzeug era possibile inviare alcuni caratteri Unicode e questo farà 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.
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.
Per maggiori informazioni sugli header hop-by-hop visita:
hop-by-hop headersIdentificare le vulnerabilità di HTTP request smuggling può spesso essere realizzato utilizzando tecniche di temporizzazione, 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à:
Metodo:
Invia una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end attenda dati aggiuntivi.
Esempio:
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.
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.
Metodo:
Invia una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end attenda dati aggiuntivi.
Esempio:
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 dati aggiuntivi che non arrivano mai, causando un ritardo.
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:
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.
Dopo aver confermato l'efficacia delle tecniche di temporizzazione, è fondamentale verificare se le richieste del client possono essere manipolate. Un metodo semplice è tentare di avvelenare le tue richieste, ad esempio, facendo in modo che una richiesta a / restituisca una risposta 404. Gli esempi CL.TE e TE.CL precedentemente discussi in Esempi di Base dimostrano come avvelenare una richiesta del client per ottenere una risposta 404, nonostante il client miri ad accedere a una risorsa diversa.
Considerazioni Chiave
Quando testi le vulnerabilità di request smuggling interferendo con altre richieste, tieni a mente:
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.
Temporizzazione 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.
A volte, i proxy front-end applicano misure di sicurezza, esaminando le richieste in arrivo. Tuttavia, queste misure possono essere eluse sfruttando l'HTTP Request Smuggling, consentendo l'accesso non autorizzato a endpoint riservati. Ad esempio, l'accesso a /admin potrebbe essere vietato esternamente, con il proxy front-end che blocca attivamente tali tentativi. Tuttavia, questo proxy potrebbe trascurare di ispezionare le richieste incorporate all'interno di una richiesta HTTP contrabbandata, lasciando un'opportunità per bypassare queste restrizioni.
Considera i seguenti esempi che illustrano come l'HTTP Request Smuggling può essere utilizzato per eludere i controlli di sicurezza del front-end, mirando specificamente al percorso /admin che è tipicamente protetto dal proxy front-end:
Esempio CL.TE
Nell'attacco CL.TE, l'intestazione Content-Length viene sfruttata per la richiesta iniziale, mentre la successiva richiesta incorporata utilizza l'intestazione Transfer-Encoding: chunked. Il proxy front-end elabora la richiesta POST iniziale ma non riesce a ispezionare la richiesta incorporata GET /admin, consentendo l'accesso non autorizzato al percorso /admin.
TE.CL Esempio
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.
Le applicazioni spesso impiegano un server front-end per modificare le richieste in arrivo prima di passarle al server back-end. Una modifica tipica comporta l'aggiunta di intestazioni, come X-Forwarded-For: <IP del client>, per trasmettere l'IP del client al back-end. Comprendere queste modifiche può essere cruciale, poiché potrebbe rivelare modi per bypassare le protezioni o scoprire informazioni o endpoint nascosti.
Per indagare su come un proxy altera una richiesta, individua un parametro POST che il back-end restituisce nella risposta. Quindi, crea una richiesta, utilizzando questo parametro per ultimo, simile al seguente:
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.
È importante allineare l'intestazione Content-Length della richiesta annidata con la lunghezza effettiva del contenuto. È consigliabile iniziare con un valore basso e aumentare gradualmente, poiché un valore troppo basso truncherà i dati riflessi, mentre un valore troppo alto può causare un errore 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 di ricerca.
Questo metodo serve principalmente a comprendere le modifiche alla richiesta effettuate dal proxy front-end, eseguendo essenzialmente un'indagine autodiretta.
È 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:
Aggiungendo la seguente richiesta come valore di un parametro, puoi memorizzare la richiesta del cliente successivo:
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.
Tuttavia, questa tecnica ha delle limitazioni. In generale, cattura i dati solo fino al delimitatore del parametro utilizzato nella richiesta smuggled. Per le sottomissioni di moduli codificati in URL, questo delimitatore è il carattere &. Ciò significa che il contenuto catturato dalla richiesta dell'utente vittima si fermerà al primo &, che potrebbe anche far parte della stringa di query.
Inoltre, vale la pena notare che questo approccio è anche valido con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe concludersi con search=\r\n0. Indipendentemente dai caratteri di nuova riga, i valori saranno aggiunti al parametro di ricerca.
L'HTTP Request Smuggling può essere sfruttato per attaccare pagine web vulnerabili a XSS Riflesso, offrendo vantaggi significativi:
L'interazione con gli utenti target è non necessaria.
Consente di sfruttare l'XSS in parti della richiesta che sono normalmente inaccessibili, come le intestazioni delle richieste HTTP.
In scenari in cui un sito web è suscettibile a XSS Riflesso attraverso l'intestazione User-Agent, il seguente payload dimostra come sfruttare questa vulnerabilità:
Questo payload è strutturato per sfruttare la vulnerabilità tramite:
Iniziare una richiesta POST, apparentemente tipica, con un'intestazione Transfer-Encoding: chunked per indicare l'inizio dello smuggling.
Seguire con un 0, che segna la fine del corpo del messaggio chunked.
Poi, viene introdotta una richiesta GET smuggled, dove l'intestazione User-Agent è iniettata con uno script, <script>alert(1)</script>, attivando l'XSS quando il server elabora questa richiesta successiva.
Manipolando il User-Agent tramite smuggling, il payload elude i normali vincoli delle richieste, sfruttando così la vulnerabilità XSS Riflessa in modo non standard ma efficace.
Nel caso in cui il contenuto dell'utente venga riflesso in una risposta con un Content-type come text/plain, impedendo l'esecuzione dell'XSS. Se il server supporta HTTP/0.9 potrebbe essere possibile eludere questo!
La versione HTTP/0.9 era precedente alla 1.0 e utilizza solo verbi GET e non risponde con intestazioni, solo il corpo.
In questo writeup, questo è stato abusato con uno smuggling di richieste e un endpoint vulnerabile che risponderà con l'input dell'utente per smuggler una richiesta con HTTP/0.9. Il parametro che verrà riflesso nella risposta conteneva una falsa risposta HTTP/1.1 (con intestazioni e corpo) quindi la risposta conterrà codice JS eseguibile valido con un Content-Type di text/html.
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:
Risultati in:
Sebbene apparentemente innocuo, questo comportamento può essere manipolato utilizzando HTTP request smuggling per reindirizzare gli utenti a un sito esterno. Ad esempio:
Questa richiesta di contrabbando potrebbe causare la successiva richiesta dell'utente elaborata di essere reindirizzata a un sito web controllato dall'attaccante:
Risultati in:
In questo scenario, la richiesta di un file JavaScript da parte di un utente viene dirottata. L'attaccante può potenzialmente compromettere l'utente servendo JavaScript malevolo in risposta.
Il web cache poisoning può essere eseguito se qualsiasi componente dell'infrastruttura front-end memorizza nella cache i contenuti, tipicamente per migliorare le prestazioni. Manipolando la risposta del server, è possibile avvelenare la cache.
In precedenza, abbiamo osservato come le risposte del server potessero essere modificate per restituire un errore 404 (fare riferimento a Esempi di Base). Allo stesso modo, è possibile ingannare il server per consegnare il contenuto di /index.html in risposta a una richiesta per /static/include.js. Di conseguenza, il contenuto di /static/include.js viene sostituito nella cache con quello di /index.html, rendendo /static/include.js inaccessibile agli utenti, potenzialmente portando a un Denial of Service (DoS).
Questa tecnica diventa particolarmente potente se viene scoperta una vulnerabilità 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.
Di seguito è riportata un'illustrazione di sfruttare l'avvelenamento della cache combinato con un reindirizzamento in loco a un open redirect. L'obiettivo è modificare il contenuto della cache di /static/include.js per servire codice JavaScript controllato dall'attaccante:
Nota la richiesta incorporata che mira a /post/next?postId=3. Questa richiesta verrà reindirizzata a /post?postId=4, utilizzando il valore dell'intestazione Host per determinare il dominio. Alterando l'intestazione Host, l'attaccante può reindirizzare la richiesta al proprio dominio (reindirizzamento in loco a reindirizzamento aperto).
Dopo un avvelenamento del socket riuscito, dovrebbe essere avviata una richiesta GET per /static/include.js. Questa richiesta sarà contaminata dalla precedente richiesta di reindirizzamento in loco a reindirizzamento aperto e recupererà il contenuto dello script controllato dall'attaccante.
Successivamente, qualsiasi richiesta per /static/include.js servirà il contenuto memorizzato nella cache dello script dell'attaccante, lanciando efficacemente un ampio attacco XSS.
Qual è la differenza tra avvelenamento della cache web e deception della cache web?
Nell'avvelenamento della cache web, l'attaccante costringe l'applicazione a memorizzare contenuti dannosi nella cache, e questo contenuto viene servito dalla cache ad altri utenti dell'applicazione.
Nella deception della cache web, l'attaccante costringe l'applicazione a memorizzare contenuti sensibili appartenenti a un altro utente nella cache, e l'attaccante poi recupera questo contenuto dalla cache.
L'attaccante crea una richiesta di contrabbando che recupera contenuti sensibili specifici per l'utente. Considera il seguente esempio:
Se questa richiesta di contrabbando 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.
In questo post 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:
Invierà una risposta come:
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 sarà riflettente 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.
Continuare seguendo questo post è suggerito un altro modo per abusare del metodo TRACE. Come commentato, smuggler una richiesta HEAD e una richiesta TRACE è possibile controllare alcuni dati riflessi nella risposta alla richiesta HEAD. La lunghezza del corpo della richiesta HEAD è fondamentalmente indicata nell'intestazione Content-Length ed è formata dalla risposta alla richiesta TRACE.
Pertanto, la nuova idea sarebbe che, conoscendo questo Content-Length e i dati forniti nella risposta TRACE, è possibile far sì che la risposta TRACE contenga una risposta HTTP valida dopo l'ultimo byte del Content-Length, consentendo a un attaccante di controllare completamente la richiesta alla risposta successiva (che potrebbe essere utilizzata per eseguire un cache poisoning).
Esempio:
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 valida risposta HTTP viene smugglerata):
Hai trovato una vulnerabilità di HTTP Request Smuggling e non sai come sfruttarla. Prova questi altri metodi di sfruttamento:
HTTP Response Smuggling / DesyncHTTP Request Smuggling del Browser (Lato Client)
Request Smuggling nei Downgrade HTTP/2
Da https://hipotermia.pw/bb/http-desync-idor
Da: https://hipotermia.pw/bb/http-desync-account-takeover
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Questo strumento è un Fuzzer HTTP basato su grammatica utile per trovare strane discrepanze nel request smuggling.
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)
