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.
 Christmas Sale -40% 𝗖𝗵𝗿𝗶𝘀𝘁𝗺𝗮𝘀 𝗦𝗮𝗹𝗲! Sconto del 𝟰𝟬% 𝘀𝘂𝗹 𝗽𝗿𝗲𝘇𝘇𝗼 𝗱𝗶 𝗰𝗼𝗽𝗲𝗿𝘁𝗶𝗻𝗮 del Corso "Dark Web & Cyber Threat Intelligence" in modalità E-Learning sulla nostra Academy!🚀
Fino al 𝟯𝟭 𝗱𝗶 𝗗𝗶𝗰𝗲𝗺𝗯𝗿𝗲, prezzi pazzi alla Red Hot Cyber Academy. 𝗧𝘂𝘁𝘁𝗶 𝗶 𝗰𝗼𝗿𝘀𝗶 𝘀𝗰𝗼𝗻𝘁𝗮𝘁𝗶 𝗱𝗲𝗹 𝟰𝟬% 𝘀𝘂𝗹 𝗽𝗿𝗲𝘇𝘇𝗼 𝗱𝗶 𝗰𝗼𝗽𝗲𝗿𝘁𝗶𝗻𝗮.
Per beneficiare della promo sconto Christmas Sale, scrivici ad [email protected] o contattaci su Whatsapp al numero di telefono: 379 163 8765.
Se ti piacciono le novità e gli articoli riportati su di Red Hot Cyber, iscriviti immediatamente alla newsletter settimanale per non perdere nessun articolo. La newsletter generalmente viene inviata ai nostri lettori ad inizio settimana, indicativamente di lunedì. |
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.
Seguici su Google News, LinkedIn, Facebook e Instagram per ricevere aggiornamenti quotidiani sulla sicurezza informatica. Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.
