Alla scoperta dell’HTTP Request Smuggling: cos’è e come difendersi

Immaginiamo una metropolitana notturna in cui le richieste sono vagoni che scorrono uno dopo l’altro. Il front end fa da bigliettaio e smista i vagoni, il back end è il deposito che li riceve e li lavora. Se il bigliettaio e il deposito non sono d’accordo su dove finisce un vagone e inizia quello successivo, si apre una fessura che qualcuno può sfruttare per infilare un vagone nascosto. Quel vagone nascosto è il contrabbando di richieste HTTP.

Nel mondo reale la cosa prende forma quando componenti diversi della catena di comunicazione interpretano in modo diverso la lunghezza del corpo di una richiesta. In HTTP versione uno ci sono due modi per dichiarare la lunghezza del corpo, uno è il content length e l’altro è la transfer encoding in modalità chunked. Quando i nodi intermedi o i server finali non concordano su quale metodo utilizzare, la stessa sequenza di byte può essere letta da un elemento come parte della richiesta corrente e da un altro come l’inizio della richiesta successiva.

Questo disaccordo non è una sottigliezza teorica ma una vera leva d’attacco. Le varianti che si incontrano più spesso sono quelle in cui il front end prende come riferimento il valore di lunghezza mentre il back end interpreta la codifica a blocchi, oppure il contrario, oppure ancora situazioni in cui entrambi supportano la codifica a blocchi ma uno dei due ignora l’intestazione perché leggermente deformata con spazi, tabulazioni o formattazioni non standard. In tutti i casi il risultato effettivo è lo stesso, una parte di dati che si ritrova dove non doveva essere e che può alterare il comportamento di richieste legittime successive.

Le conseguenze pratiche possono diventare molto serie. Una richiesta prepended può cambiare il contesto di una transazione e far credere al server che una chiamata autenticata appartenga a un utente diverso. Si possono rubare sessioni, bypassare filtri, avvelenare cache o inserire comandi nella sequenza di richieste che colpisce utenti successivi sulla stessa connessione. In ambienti moderni il rischio aumenta quando c’è il downgrade da HTTP due a HTTP uno perché la riscrittura o la traduzione dei messaggi introduce ulteriori punti di ambiguità, e quando le connessioni backend vengono riutilizzate per inviare più richieste una dopo l’altra perché il riuso moltiplica le possibilità che dati residui vengano interpretati come nuova richiesta.

Per capire dove guardare basta osservare i comportamenti divergenti tra front end e back end, le intestazioni duplicate o non conformi che emergono nei log e i casi in cui i log mostrano mismatch tra la lunghezza dichiarata e il contenuto reale. Questi segnali non sono la prova definitiva di una vulnerabilità ma sono la traccia che indica che la catena di elaborazione non è allineata e che vale la pena investigare. Dal punto di vista di chi progetta e mantiene l’infrastruttura la soluzione più robusta è eliminare l’ambiguità alla fonte.

La comunicazione end to end su HTTP due risolve il problema alla radice perché quel protocollo fornisce un unico, solido meccanismo per definire le dimensioni delle richieste. Quando non è possibile mantenere HTTP due su tutta la filiera la fase di traduzione verso HTTP uno deve essere trattata come un punto critico: la richiesta riscritta va verificata rispetto alla specifica e gli elementi della catena non devono tollerare deviazioni formattative che possano essere interpretate in modo diverso. Nei pezzi dell’infrastruttura che si occupano di accettare e inoltrare traffico è utile normalizzare le richieste e rilevare le ambiguità invece di tentare di correggerle in modo silente. Il back end, di norma, dovrebbe chiudere la connessione quando non è possibile risolvere un’ambiguità in modo certo, perché mantenere aperte connessioni impure è ciò che permette al contrabbando di propagarsi.

Limitare o controllare il riutilizzo delle connessioni backend riduce la finestra d’attacco anche se non la elimina del tutto. È importante anche uniformare la gestione delle intestazioni che determinano la lunghezza del corpo e non accettare varianti non standard che possono essere sfruttate per mascherare la codifica. A complemento di queste scelte architetturali, test specifici che replicano scenari di desincronizzazione e monitoraggio attento dei log aiutano a individuare regressioni e incidenti reali.

Da ultimo, vale la pena ricordare che le tecniche che permettono di generare desincronizzazione sono potenti e pericolose se usate senza autorizzazione, quindi la loro esplorazione va sempre confinata ad ambienti controllati e autorizzati e qualsiasi scoperta in sistemi di terzi va gestita con responsabilità e disclosure appropriata. Capire il meccanismo del contrabbando di richieste significa riconoscere che non stiamo parlando di bug isolati ma di disallineamenti di protocollo che emergono nelle catene complesse di servizi, ed è proprio per questo che la difesa efficace nasce dall’allineamento dei protocolli, dalla standardizzazione dei comportamenti e dalla capacità di osservare e reagire quando le cose non tornano.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

Diego Bentivoglio

Appassionato di hacking e cyber security, esperto in penetration testing, ho collaborato con realtà come Leonardo CAE AJT. AWS solution architect e nella top 100 hackers BMW 2024 su HackerOne, unisco competenze su infrastrutture e applicazioni web con una forte passione per la sicurezza.