HTTP Request Smuggling

Voci di Glossario Sicurezza Informatica
Indice dei contenuti

    L’HTTP Request Smuggling è una tecnica di attacco che sfrutta l’ambiguità nell’interpretazione dei confini delle richieste HTTP tra un server front-end (proxy, load balancer, CDN) e un server back-end. Quando i due sistemi non concordano su dove finisce una richiesta e dove comincia la successiva, un attaccante può inserire (smuggle) una richiesta parziale all’interno del corpo di una richiesta legittima, facendo sì che il back-end la elabori come una richiesta indipendente — potenzialmente per conto di un altro utente.

    La vulnerabilità fu sistematizzata da James Kettle (PortSwigger) nel 2019, che dimostrò come fosse sfruttabile contro siti di alto profilo tra cui Google, Netflix, Akamai.

    Il punto di ambiguità: Content-Length vs Transfer-Encoding

    HTTP/1.1 definisce due meccanismi per indicare la lunghezza del corpo di una richiesta:

    • Content-Length: specifica la lunghezza in byte del corpo.
    • Transfer-Encoding: chunked: il corpo è inviato in chunk, ciascuno preceduto dalla propria lunghezza in esadecimale; la sequenza termina con un chunk di lunghezza 0.

    Lo standard (RFC 7230) stabilisce che Transfer-Encoding ha priorità su Content-Length quando entrambi sono presenti. Ma proxy e server implementano questo in modo non uniforme, e alcuni ignorano o trattano diversamente header malformati.

    Varianti principali

    CL.TE — Front-end usa Content-Length, Back-end usa Transfer-Encoding

    POST / HTTP/1.1
Host: esempio.it
Content-Length: 13
Transfer-Encoding: chunked

0

RICHIESTA-NASCOSTA

    Il front-end legge Content-Length: 13 e invia i 13 byte dopo gli header (0\r\n\r\nRICHI). Il back-end usa chunked: vede il chunk 0 (fine), considera la richiesta terminata, e tratta i byte rimanenti (ESTA-NASCOSTA) come inizio della richiesta successiva.

    TE.CL — Front-end usa Transfer-Encoding, Back-end usa Content-Length

    POST / HTTP/1.1
Host: esempio.it
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

    Il front-end usa chunked e invia tutto. Il back-end usa Content-Length: 3 e considera terminata la richiesta dopo 3 byte (8\r\n), lasciando il resto nel buffer come inizio della richiesta successiva.

    TE.TE — Entrambi usano Transfer-Encoding, ma uno viene ingannato con offuscamento

    Transfer-Encoding: chunked
Transfer-Encoding: identity

    oppure:

    Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding[tab]: chunked

    Uno dei due server ignora l’header offuscato e usa l’altro meccanismo, creando disallineamento.

    Impatti

    Bypass dei controlli di sicurezza del front-end: le policy di accesso, i filtri IP e i controlli di autenticazione implementati nel proxy vengono applicati alla richiesta “esterna” — la richiesta contrabbandato bypassa questi controlli perché il back-end la riceve senza passare per il front-end.

    Cattura delle richieste di altri utenti: la richiesta nascosta rimane nel buffer del back-end e viene preposta alla richiesta successiva di un altro utente, facendo sì che i dati di quell’utente (incluse le sue credenziali o token) vengano inviati all’attaccante come parte della risposta.

    Cross-Site Scripting riflesso: contrabbandare una richiesta che provoca una risposta con XSS, consegnata a un altro utente.

    Cache poisoning: in combinazione con cache HTTP, inserire nel cache una risposta malevola associata a un URL legittimo.

    Escalation di SSRF: il back-end può accettare richieste a endpoint interni che il front-end bloccherebbe.

    Contromisure

    HTTP/2 end-to-end: HTTP/2 definisce i confini delle richieste con frame binari a lunghezza esplicita, eliminando l’ambiguità CL/TE. Usare HTTP/2 sull’intera catena (non solo front-to-client ma anche front-to-back) risolve alla radice il problema.

    Normalizzazione nel front-end: il proxy dovrebbe rifiutare o normalizzare richieste con header Content-Length e Transfer-Encoding presenti contemporaneamente, non inoltrarle al back-end.

    Connessioni back-end non riutilizzate: se il front-end usa una connessione dedicata per ogni richiesta verso il back-end (no keep-alive), il smuggling perde effetto perché non c’è buffer condiviso tra richieste diverse.

    Timeout aggressivi: configurare timeout brevi sul back-end per le richieste incomplete riduce la finestra di sfruttamento.

    Test con Burp Suite: il modulo HTTP Request Smuggler di PortSwigger è lo strumento standard per testare questa vulnerabilità.

    Relazione con altri argomenti

    • SSRF — spesso combinato con request smuggling per raggiungere servizi interni.
    • Cross-Site Scripting (XSS) — il smuggling può essere usato per consegnare XSS a utenti ignari.
    • Security Headers HTTP — il request smuggling bypassa spesso i controlli implementati a livello di header nel front-end.
    • OWASP Top 10 — A05 Security Misconfiguration (misconfiguration della catena proxy-backend).

    Ultimo aggiornamento: