L'HTTP request smuggling è una vulnerabilità che deriva da incongruenze nell'analisi delle richieste HTTP tra più dispositivo. Queste vulnerabilità si verificano quando un dispositivo front end (ad es., Rete di distribuzione dei contenuti, bilanciatore del carico, web application firewall) e un dispositivo di back-end (ad es., server web) interpretano in modo diverso la fine della richiesta HTTP, a causa della presenza di diverse intestazioni HTTP (ovvero, Transfer-Encoding, Content-Length). Questo può portare a un aggiramento dei controlli di sicurezza, alla possibilità di lanciare attacchi (ad es., XSS) contro altri utenti, cache poisoning, Denial of Service o altri attacchi a seconda dell'applicazione. L'HTTP richiesta smuggling può anche essere indicato come CWE-444, HTTP risposta smuggling o HTTP smuggling.

Esistono molti tipi di vulnerabilità di HTTP request smuggling, a seconda della versione del protocollo, dell'ordine delle intestazioni e dell'ambiente. Analizzeremo ciascuna di queste nella sezione seguente.

Cosa tratteremo:

1. Quali sono i diversi tipi di richiesta smuggling HTTP?

2. Richiesta smuggling HTTP/1.1

3. Smuggling di richieste HTTP/2

4. Impatto della richiesta smuggling HTTP

5. Come Fastly previene l'HTTP request smuggling

6. Come prevenire il richiesta smuggling HTTP

7. Riepilogo

Quali sono i diversi tipi di richiesta smuggling HTTP?

Richiesta smuggling HTTP/1.1

Le richieste HTTP che usano la versione 1.1 possono specificare la fine della loro richiesta usando l'intestazione Content-Length o Transfer-Encoding. Quando i dispositivi front end e back end non usano la stessa di queste due intestazioni per determinare la fine della richiesta, potrebbero analizzare la fine della richiesta in modo diverso, causando una vulnerabilità di HTTP request smuggling. 

Per i seguenti esempi, dimostreremo l'impatto del request smuggling tramite un bypass dell'autorizzazione. In questo scenario, il server front end impedisce l'accesso alla pagina /admin, ma non è presente alcuna convalida aggiuntiva sul back-end. Poiché il back-end non esegue nemmeno la convalida, il request smuggling può consentirci di aggirare questo controllo di autorizzazione. 

Vulnerabilità CL.TE

Una vulnerabilità CL.TE si riferisce a un attacco di HTTP request smuggling in cui il front end usa l'intestazione Content-Length, ma il back-end usa l'intestazione Transfer-Encoding. 

Nell’esempio seguente, il front end usa l’intestazione Content-Length, leggendo l’intero contenuto come un’unica richiesta e inoltrandolo al back-end. Tuttavia, il server di back-end usa l’intestazione Transfer-Encoding e interpreta la fine della richiesta in corrispondenza di 0\r\n\r\n (due nuove righe dopo un blocco 0 che Transfer-Encoding usa per indicare la fine di una richiesta). Il back-end interpreta quindi questo come due richiesta.

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 46
Transfer-Encoding: chunked

1
q=smuggling

0

GET /admin HTTP/1.1
Example: x

Ora, quando attraverso la connessione arrivano più dati (ad esempio, inviamo di nuovo la richiesta), il server back-end li antepone a questa seconda richiesta smuggled perché non è stata terminata. Questo fa sì che il server back-end veda quanto segue come seconda richiesta:

GET /admin HTTP/1.1
Example: xPOST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

Content-Length: 46
Transfer-Encoding: chunked

1
q=smuggling

Il server di back-end interpreta questo come una richiesta GET per /admin, che è stata fatta passare di nascosto oltre il server di front end, che ha interpretato solo le due richieste POST. Questa vulnerabilità di request smuggling ora consente all’hacker di bypassare il controllo di autorizzazione da parte del front end. 

Vulnerabilità TE.CL

Una vulnerabilità TE.CL si riferisce a un attacco di HTTP request smuggling in cui il front end usa l'intestazione Transfer-Encoding ma il back-end usa l'intestazione Content-Length. 

Nell’esempio seguente, il front end usa l’intestazione Transfer-Encoding, legge l’intero contenuto come un’unica richiesta e lo inoltra al back-end. Il back-end usa l’intestazione Content-Length e quindi interpreta questo come due richiesta.

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

k0
GET /admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 150

x
0

Mentre il server front end ha terminato la sua richiesta, il server back-end è ancora in attesa di contenuti aggiuntivi dal lungo Content-Length nella richiesta smuggled. Quando attraverso la connessione arrivano più dati (ad esempio, inviamo di nuovo la richiesta), il server back-end li antepone a questa seconda richiesta smuggled perché non è stata terminata. Ciò fa sì che il server back-end veda quanto segue come seconda richiesta:

GET /admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 141

x
0

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

k0

Il server di back-end interpreta questo come una richiesta GET per /admin, che è stata fatta passare di nascosto oltre il server di front end, che ha interpretato solo le due richieste POST. Questa vulnerabilità di request smuggling ora consente all’hacker di bypassare il controllo di autorizzazione da parte del front end. 

Offuscamento & smuggling delle intestazioni

È possibile che alcuni dispositivo ignorino le intestazione Transfer-Encoding non corrette, mentre altri potrebbero elaborarle anche in presenza di lievi errori (es. spazi aggiuntivi, intestazioni duplicate, ecc.) Se così fosse, potrebbe essere più facile exploit una delle suddette vulnerabilità CL.TE o TE.CL perché un dispositivo elabora l'intestazione malformata mentre l'altro la ignora.

Smuggling di richieste HTTP/2

Sebbene il classico HTTP request smuggling debba essere mitigato tramite HTTP/2, esistono ancora modi per eseguire lo smuggling di richieste usando HTTP/2, in particolare quando i server backend supportano solo HTTP/1.1. 

HTTP/2 è un protocollo binario inviato in frame, con ogni frame preceduto dalla lunghezza del frame. Un'intestazione Content-Length non è obbligatoria e l'intestazione Transfer-Encoding non è supportata. Per maggiore leggibilità, mostreremo queste richiesta come apparirebbero in HTTP/1.1, ma tieni presente che i dati effettivamente inviati hanno un aspetto diverso in HTTP/2.

Downgrade di HTTP/2

Quando i dispositivi back-end (ad es., server web) supportano solo HTTP/1.1, ma i dispositivi front end (ad es., Rete di distribuzione dei contenuti) e i client utilizzano HTTP/2, i dispositivi front end riscriveranno la richiesta HTTP/2 ricevuta in HTTP/1.1 prima di inviarla al back-end. Questo è definito come downgrading di HTTP/2, ed è tramite l’exploit degli errori nella riscrittura che sorgono le vulnerabilità di request smuggling.

Vulnerabilità H2.CL

HTTP/2 non richiede un'intestazione Content-Length e, se ne viene fornita una, deve essere convalidata rispetto alla lunghezza calcolata del messaggio. Quando un dispositivo riscrive una richiesta in HTTP/1.1, deve usare la lunghezza calcolata per l'intestazione Content-Length tradotta. Tuttavia, alcuni dispositivo front end possono invece usare l’intestazione Content-Length fornita durante l’esecuzione del downgrade. Se ciò accade, il back-end utilizzerà un Content-Length diverso dal front end, con conseguente vulnerabilità di smuggling.

Vulnerabilità H2.TE

L'intestazione Transfer-Encoding non viene utilizzata in HTTP/2 ed è consigliabile rimuovere l'intestazione o rifiutare le richiesta HTTP/2 che includono un'intestazione Transfer-Encoding. Se il dispositivo front end non lo fa e poi riscrive la richiesta con l’intestazione Transfer-Encoding, è possibile far passare l’intestazione al back-end. Per eseguire l’exploit di questo, il back-end dovrebbe supportare Transfer-Encoding invece di Content-Length, ma sarebbe quindi uguale a un exploit CL.TE HTTP/1.1.

Impatto della richiesta smuggling HTTP

L'HTTP request smuggling ha un'ampia gamma di impatti a seconda dell'applicazione perché interferisce con il confine di più richieste. I nostri esempi precedenti riguardavano un bypass dell’autorizzazione e ne esamineremo un altro che interessa altri utenti, ma ce ne sono molti altri trattati più nel dettaglio dagli esperti di Portswigger, che conducono ricerche approfondite sull’HTTP request smuggling.

Esempio reale: exploit con XSS riflesso

In questo esempio, supponiamo che il server front end determini la lunghezza della richiesta in base a Content-Length e che il server back-end la determini in base a Transfer-Encoding. Supponiamo anche che il server web sia vulnerabile al cross-site scripting (XSS) riflesso quando un payload si trova nell'intestazione Referrer. Normalmente, un XSS riflesso nell'intestazione Referer è difficile da exploitare, perché non può essere sfruttato con un semplice link come potrebbe avvenire in un parametro di query. In questo scenario, un hacker invia la seguente richiesta:

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 111
Transfer-Encoding: chunked

1
q=smuggling
0

GET /vulnerable-page HTTP/1.1
Referrer: ”><script>print(1)</script>
Example: x

Il front end utilizza l'intestazione Content-Length e la interpreta come una singola richiesta, inoltrandola al back-end. Il back-end usa Transfer-Encoding e lo interpreta come due richiesta, con la prima evidenziata in rosso e la seconda in blu. La seconda richiesta è incompleta, quindi il back-end attende altri dati. Quando un altro utente invia successivamente una richiesta a /home, la risposta del server web proviene dalla richiesta smuggled dell'hacker, portando alla distribuzione del payload XSS riflesso nella risposta all'utente vittima. In questo scenario, il back-end interpreta la richiesta dell'utente vittima come segue:

GET /vulnerable-page HTTP/1.1
Referrer: "><script>print(1)</script>
Example: xGET /home HTTP/1.1
Host: example.com
...rest of victim user's request...

L’utente vittima ha inviato una richiesta a /home, ma ha invece ricevuto la risposta a /vulnerable-page con il payload XSS riflesso. In pratica, a causa del volume di richiesta, del riutilizzo della connessione, ecc., saranno necessarie molte richiesta perché un utente riceva la risposta XSS in coda, ma questo può rapidamente interessare un’ampia gamma di utente inviando rapidamente richieste di smuggling per avvelenare le connessioni con payload XSS. 

Come Fastly previene l'HTTP request smuggling

Fastly impedisce il contrabbando di richieste HTTP analizzando le richieste in modo rigoroso e conforme. Questo avviene in diversi modi:

• Analisi rigorosa del protocollo: Fastly analizza tutte le richiesta HTTP con un elevato grado di rigore, nel rispetto degli Standard. Questo elimina l'ambiguità che gli hacker usano per sfruttare le vulnerabilità di request smuggling.

• Normalizzazione delle richieste: Fastly rifiuta o normalizza le richieste ambigue ai bordi della rete. Ad esempio, una richiesta contenente sia un'intestazione Content-Length sia un'intestazione Transfer-Encoding verrà gestita in modo da impedirne il raggiungimento dell'origine in uno stato sfruttabile.

• Rifiuto delle richieste non valide: Fastly nega le richieste GET e HEAD che contengono un corpo. Quando ciò si verifica, Fastly invia una risposta 400 Bad Request, impedendo alla richiesta di raggiungere l'origine. Se configurate per consentirlo, le richiesta GET e HEAD pass trasmetteranno i corpi della richiesta all'origine. Se hai l'esigenza specifica di abilitare i body per queste richiesta, devi contattare il nostro team di supporto.

Come prevenire il richiesta smuggling HTTP

• Normalizza le richieste ambigue

  • I server front end che ricevono sia le intestazioni CL sia TE devono normalizzare le richieste a un singolo meccanismo per determinare la lunghezza di una richiesta e rimuovere le intestazioni superflue per impedire alle origini di ricevere richieste ambigue.

• Rifiuta le richiesta non valide (sia HTTP/2 che HTTP/1.1)

  • Rifiutare le richieste con intestazioni non valide, intestazioni duplicate, ecc. aiuterà a prevenire vulnerabilità che potrebbero dipendere dall'accettazione da parte dei server di intestazioni non valide. Impedirà inoltre le vulnerabilità di downgrade HTTP/2 CL e TE che si basano sull’inoltro al back-end di intestazioni aggiuntive non necessarie.

• Convalida nel downgrade HTTP/1.1

  • I server front end che eseguono il downgrade a HTTP/1.1 devono verificare che le richiesta riscritte non siano malformate o ambigue. Ad esempio, dopo la riscrittura, un server front end deve eseguire la stessa normalizzazione che eseguirebbe su una normale richiesta HTTP/1.1.

• Valuta la possibilità di disabilitare il riutilizzo delle connessioni di back-end

  • Molti attacco di richiesta di tipo smuggling sfruttano il riutilizzo delle connessioni da parte del front end e del back-end. L’esempio di XSS fa questo, dove più utenti che inviano richieste condividono una connessione dal front end al back end e lo smuggling fa sì che le risposta si mescolino. La disattivazione del riutilizzo della connessione impedisce questo tipo di attacco, ma non impedisce tutti gli attacchi di smuggling e non impedisce tecniche avanzate come il tunneling delle richieste. Questo può anche influire sulle prestazioni ed è solo una mitigazione partial.

• Usa HTTP/2 end-to-end, se possibile

  • HTTP/2 è intrinsecamente protetto contro il request smuggling quando il downgrade è disabilitato. Quando possibile, usarlo è la mitigazione migliore.

Riepilogo

L'HTTP Request smuggling è una vulnerabilità che deriva da incoerenze nell'analisi delle richieste HTTP tra più dispositivi e può causare impatti devastanti, come il bypass dell'autorizzazione, la capacità di lanciare attacco (ad es., XSS) su altri utente, il cache poisoning, il Denial of Service e altro ancora. Sebbene HTTP/2 e la disattivazione del downgrading impediscano il request smuggling, le organizzazioni dovrebbero anche prendere in considerazione il rifiuto delle richieste malformate, la normalizzazione delle richieste ambigue e la convalida dello schema HTTP per limitare ulteriormente la superficie di attacco se il downgrading deve essere supportato.

Scopri di più sulle offerte di sicurezza di Fastly che possono aiutarti a proteggerti dagli attacchi di HTTP request smuggling e altro ancora.