Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Cerca

Hack tutorial: Cosa è l’HTTP request smuggling?

Redazione RHC : 31 Maggio 2021 08:00

Autore: Damiano Capo

Data Pubblicazione: 26/05/2021


PARTE LA PROMO ESTATE -40%

RedHotCyber Academy lancia una promozione esclusiva e a tempo limitato per chi vuole investire nella propria crescita professionale nel mondo della tecnologia e della cybersecurity!

Approfitta del 40% di sconto sull’acquisto congiunto di 3 corsi da te scelti dalla nostra Academy. Ad esempio potresti fare un percorso formativo includendo Cyber Threat intelligence + NIS2 + Criptovalute con lo sconto del 40%. Tutto questo lo potrai fruire, dove e quando vuoi e con la massima flessibilità, grazie a lezioni di massimo 30 minuti ciascuna.

Contattaci tramite WhatsApp al 375 593 1011 per richiedere ulteriori informazioni oppure scriviti alla casella di posta [email protected]



Supporta RHC attraverso:


Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.


L’Http request Smuggling è una tecnica per interferire con un sito Web che elabora le sequenze di richieste HTTP ricevute da uno o più utenti. Questa tipologia di vulnerabilità è estremamente pericolosa perché consente ad un utente malintenzionato di aggirare i controlli di sicurezza, ottenere l’accesso non autorizzato a dati sensibili e compromettere direttamente altri fruitori dell’applicazione.

Benché non molto conosciuta, questa è stata scoperta per la prima volta nel lontano 2005.

Le applicazioni web odierne utilizzano spesso catene di server HTTP tra gli utenti e la logica applicativa definitiva. Gli utenti inviano le richieste a un server front-end (a volte chiamato load-balancer o reverse proxy) e questo le inoltra a uno o più server di back-end. Questa tipologia di architettura è sempre più comune, e in alcuni casi inevitabile, nelle moderne applicazioni basate su cloud. Quando il server di front-end inoltra le richieste HTTP a un server di back-end, in genere invia diverse richieste sulla stessa connessione di rete di back-end, perché è molto più efficiente e performante.

Il protocollo è molto semplice: le richieste HTTP vengono inviate una dopo l’altra e il server ricevente analizza le intestazioni delle richieste HTTP per determinare dove finisce una richiesta e inizia quella successiva, come viene mostrato nella figura in calce:

In questa situazione, è fondamentale che i sistemi front-end e back-end siano concordi nelle richieste. In caso contrario, un utente malintenzionato potrebbe essere in grado di inviare una richiesta ambigua che viene interpretata in modo diverso dai sistemi di front-end e di back-end: Nello scenario appena descritto l’attaccante potrebbe fare in modo che la richiesta del front-end venga interpretata dal server di back-end come l’inizio della richiesta successiva.

Se l’attaccante riuscisse a concretizzare quanto descritto, l’esito sarebbe devastante.

Da dove scaturisce la vulnerabilità

Essa si verifica perché ci sono due modi diversi per specificare il punto in cui termina una richiesta: l’intestazione Content-Length e l’intestazione Transfer-Encoding. L’intestazione Content-Length è semplice: specifica la lunghezza del corpo del messaggio in byte. Per esempio:

Content-Length: POST /search HTTP/1.1Host: normal-website.comContent-Type: application/x-www-form-urlencodedContent-Length: 11

L’intestazione Transfer-Encoding può essere utilizzata per specificare che il corpo del messaggio utilizza la codifica in blocchi. Ciò significa che il corpo del messaggio contiene uno o più blocchi di dati. Ogni blocco è costituito dalla dimensione del blocco in byte (espressa in esadecimale), seguita da una nuova riga, seguita dal contenuto del blocco.

Il messaggio viene terminato con un blocco di dimensione zero. Per esempio:

content-type POST /search HTTP/1.1Host: normal-website.comContent-Type: application/x-www-form-urlencodedTransfer-Encoding: chunked

Visto che vi sono diversi metodi per specificare la lunghezza dei messaggi HTTP, è possibile che un singolo messaggio utilizzi entrambi i metodi contemporaneamente, in modo che entrino in conflitto tra loro.

La specifica HTTP tenta di prevenire questo problema affermando che se sono presenti entrambe le intestazioni Content-Length e Transfer-Encoding, l’intestazione Content-Length deve essere ignorata. Ciò potrebbe essere sufficiente per evitare ambiguità quando è in gioco un solo server, ma non quando due o più server stanno lavorando assieme. In questa situazione, possono sorgere problemi per due motivi:

  • Alcuni server non supportano l’intestazione Transfer-Encoding nelle richieste.
  • Alcuni server che supportano l’intestazione Transfer-Encoding possono essere indotti a non elaborarla se l’intestazione è offuscata in qualche modo.

Se i server front-end e back-end si comportano in modo diverso in relazione all’intestazione la Transfer-Encoding (eventualmente offuscata), potrebbero non essere d’accordo sui confini delle richieste successive, portando a vulnerabilità di request smuggling.

Contromisure:

Disabilitare il riutilizzo delle connessioni back-end, in modo che ogni richiesta back-end venga inviata tramite una connessione di rete separata. Usare HTTP/2 per le connessioni back-end, poiché questo protocollo previene l’ambiguità sulle richieste. Utilizzare esattamente lo stesso software per server Web per i server front-end e back-end, in modo che concordino sui confini tra le richieste.

In alcuni casi, le vulnerabilità possono essere evitate facendo in modo che il server front-end normalizzi le richieste ambigue o facendo in modo che il server back-end rifiuti le richieste ambigue e chiuda la connessione di rete. Tuttavia, questi approcci sono potenzialmente più soggetti a errori rispetto alle mitigazioni generiche identificate sopra.

Fonti:

Https://portswigger.net

https://cobalt.io/

https://www.infosecurity-magazine.com/

https://www.infosecinstitute.com/

Redazione
La redazione di Red Hot Cyber è composta da un insieme di persone fisiche e fonti anonime che collaborano attivamente fornendo informazioni in anteprima e news sulla sicurezza informatica e sull'informatica in generale.

Lista degli articoli

Articoli in evidenza

Arriva 123 Stealer! 120 dollari al mese in abbonamento, per rubare qualsiasi dato riservato

Un nuovo infostealer emerge dalle underground criminali e il suo nome è “123 | Stealer”. L’autore di questo software è un hacker che si nasconde sotto lo pseudonimo di k...

Ha 13 anni e ha hackerato Microsoft Teams! La storia di Dylan, uno tra i più giovani bug hunter

A soli 13 anni, Dylan è diventato il più giovane ricercatore di sicurezza a collaborare con il Microsoft Security Response Center (MSRC), dimostrando come la curiosità e la perseveranza...

Truffe e Schiavitù Digitali: La Cambogia è la Capitale Mondiale della Frode Online

Secondo un nuovo rapporto del gruppo per i diritti umani Amnesty International, pubblicato dopo quasi due anni di ricerche sulla situazione, la Cambogia resta un punto caldo sulla mappa mondiale della...

Dopo aver criptato mezzo mondo, Hunters International chiude! Distribuito gratuitamente il Decryptor

Hunters International, il gruppo responsabile di uno dei più grandi attacchi ransomware degli ultimi anni, ha annunciato ufficialmente la cessazione delle sue attività. In una dichiarazione ...

Da AI white ad AI black il passo è breve. Nuovi strumenti per Script Kiddies bussano alle porte

I ricercatori di Okta  hanno notato che aggressori sconosciuti stanno utilizzando lo strumento di intelligenza artificiale generativa v0 di Vercel per creare pagine false che imitano qu...