Gli attacchi all'intestazione HTTP Host sono diventati una tecnica comune per gli hacker e presentano diverse varianti. Prima di approfondire gli attacco e ciò che consentono, iniziamo spiegando che cos'è un'intestazione host HTTP.
Cos'è l'intestazione Host HTTP?
L'intestazione HTTP Host fornisce informazioni su host e porta ed è destinata ad aiutare i server di origine a determinare quali risorse usare quando gestiscono richieste per più dominio.
Altre intestazioni host
A volte le applicazioni integrano l’intestazione Host con ulteriori intestazioni simili a Host, come “X-Forwarded-Host”, “X-Host” e altre varianti. Li useremo in alcune delle descrizioni degli attacchi riportate di seguito, poiché sono vulnerabili allo stesso modo dell'intestazione Host se usati in modo improprio.
I tipi di attacco dell'intestazione host HTTP
L'intestazione Host è una parte fondamentale dell'utilizzo di internet, ma le applicazioni si espongono a vulnerabilità quando l'intestazione Host viene considerata implicitamente attendibile, utilizzata per funzionalità aggiuntive o configurata in modo errato. Gli hacker possono exploit questo comportamento iniettando diversi tipi di contenuti nell’intestazione Host, il che può portare a vulnerabilità più gravi, tra cui:
Avvelenamento dell'intestazione host
Avvelenamento della cache web
Avvelenamento del ripristino della password
Server Side Request Forgery
A seconda di come un’applicazione utilizza i valori forniti dall’intestazione Host, potrebbe anche consentire altri attacco come cross-site scripting o SQL injection, proprio come qualsiasi altro input fornito dall’utente potrebbe fare se non viene elaborato in modo sicuro. Per ora, supponiamo che non stia usando l'intestazione Host nelle query SQL raw e occupiamoci degli attacco più diretti.
1. Avvelenamento dell'intestazione host
Nel caso più semplice, un'applicazione può usare il valore dell'intestazione Host per il reindirizzamento del traffico, ad esempio alla pagina di accesso dell'applicazione. Se l'applicazione usa l'intestazione Host per costruire il link di reindirizzamento, un hacker può inviare la seguente richiesta HTTP:
GET / HTTP/1.1
Host: www.attackers-domain.example.com
E genera una risposta che esegue il reindirizzamento al dominio sotto il loro controllo:
HTTP/1.1 302 Trovato
...
posizione: http://www.attackers-domain.example.com/login.php
Di per sé, questo attacco non è molto utile, poiché è difficile indurre un utente mirato a effettuare questa richiesta. Tuttavia, l'avvelenamento dell'intestazione host può essere combinato con altri attacco per aumentarne l'efficacia.
2. Avvelenamento della cache web
Il Web Cache Poisoning non è di per sé una vulnerabilità dell'intestazione Host, ma un meccanismo di distribuzione che rende sfruttabile il suddetto Host Header Poisoning. Supponiamo che un'applicazione non usi l'intestazione Host per costruire i suoi link di reindirizzamento (bene!), ma usi invece un'intestazione alternativa come X-Host per costruirli (male!). In questo scenario, un hacker può quindi inserire il proprio dominio in X-Host per compromettere il reindirizzamento; tuttavia, ha comunque bisogno di un modo per consegnare quel reindirizzamento all'utente.
È qui che entra in gioco il web cache poisoning. Le cache web utilizzano in genere parti di una richiesta HTTP come “chiavi” per sapere quando usare il cache content invece di inviare la richiesta all'origine. Questa chiave include in genere l’intestazione Host e può includere qualsiasi altra intestazione. Nel nostro esempio, se X-Host non fa parte della chiave della cache ma viene usato in modo non sicuro nella risposta (come nel nostro esempio di reindirizzamento), gli hacker possono usare la cache per consegnare ad altri utente il loro reindirizzamento dannoso. L'hacker trova quindi un modo per fare in modo che la sua richiesta venga messa in cache e servita ad altri utenti.
Diamo un’occhiata a un esempio di web cache poisoning. Per prima cosa, l'hacker fa memorizzare nella cache la seguente richiesta che include il proprio dominio dannoso nell'intestazione X-Host, che verrà usata in un reindirizzamento:
GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com
X-Host: www.attackers-domain.example.com
Un utente benigno decide quindi di visitare l'applicazione, inviando una richiesta normale:
GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com
X-Host: www.super-cool-fun-domain.example.com
Supponendo che la richiesta dell’hacker sia stata memorizzata nella cache in base al percorso e all’intestazione Host, l’utente legittimo riceve ora la risposta nella cache compromessa, che lo reindirizza alla pagina dell’hacker:
HTTP/1.1 302 Trovato
...
posizione: http://www.attackers-domain.example.com/login.php
Gli attacchi di web cache poisoning si basano sulla mancata corrispondenza tra le intestazioni usate come chiave della cache e le intestazioni usate dall'applicazione per formulare le risposte. Nell'esempio sopra riportato, l'intestazione X-Host ha fornito un modo per compromettere le risposte nella cache, reindirizzando gli utenti a un sito dannoso invece che all'applicazione effettiva.
3. Avvelenamento del ripristino della password
Il Password Reset Poisoning è molto simile al nostro precedente Host Header Poisoning, in quanto l'applicazione vulnerabile usa l'intestazione Host per costruire il link di reimpostazione della password che invia all'utente richiesto durante il flusso di lavoro di reimpostazione. Ad esempio, supponiamo che un hacker invii la seguente richiesta post per richiedere una reimpostazione della password per l'utente “alice”:
POST /password-reset HTTP/1.1
Host: www.attackers-domain.example.com
...
utente=alice
L'applicazione usa il valore dell'intestazione Host per costruire il link di reimpostazione e invia un'email all'utente alice con il link:
www.attackers-domain.example.com?reset_token=super-random-reset-token-value-12345
Se l'utente fa clic sul link, l'hacker acquisisce il token di reimpostazione e può reimpostare la password dell'utente con un valore scelto dall'hacker.
4. Server-Side Request Forgery
Server-Side Request Forgery (SSRF) è una vulnerabilità che consente a un hacker di indurre l'applicazione lato server a effettuare richieste verso una posizione arbitraria. In un SSRF dell’intestazione Host, l’hacker sfrutta il routing utilizzato dai sistemi che si trovano tra l’utente e l’applicazione lato server. Se questo middleware (ad es., un bilanciatore del carico) è vulnerabile a SSRF dell’intestazione Host, l’hacker può potenzialmente usarlo per interagire con sistemi interni a cui altrimenti non avrebbe accesso. Un modo comune per verificarlo consiste nell'inserire un dominio univoco e di controllo (ad esempio, Burp Collaborator di Portswigger o interactsh di ProjectDiscovery) nel valore dell'intestazione Host. Se quel dominio univoco riceve una ricerca DNS o un'altra richiesta da un sistema nel percorso di rete dell'applicazione di destinazione (ad es., il bilanciatore del carico) durante un attacco dell'intestazione Host, potrebbe essere vulnerabile a SSRF. Questi attacchi tendono a essere complessi nella pratica ma anche devastanti, come dimostrato in modo approfondito nella ricerca di James Kettle.
Esempi reali di attacco dell'intestazione host HTTP
Ora che hai compreso i tipi di attacco dell’intestazione Host, diamo un’occhiata ad alcuni esempi reali.
Common Vulnerability and Exposure-2022-29933: avvelenamento della reimpostazione della password in Craft sistema di gestione dei contenuti
SEC Consult ha rilevato che l'installazione predefinita di Craft CMS costruisce le email di reimpostazione della password utilizzando il valore dell'intestazione HTTP “X-Forwarded-Host”. In questo esempio, un hacker inserisce il dominio sotto il suo controllo nell'X-Forwarded-Host per compromettere il link di reimpostazione della password per l'utente alice come segue:
POST /index.php?p=admin/actions/users/send-password-reset-email HTTP/1.1
Host: <installation-domain>
X-Forwarded-Host: www.attackers-domain.example.com
...
cookie: CRAFT_CSRF_TOKEN=[...]
loginName=alice@example.com
Quando l’utente alice@example.com riceve l’email per la reimpostazione della password, contiene un link al dominio sotto il controllo dell’hacker:
http://www.attackers-domain.example.com/index.php?p=admin/set-password&code=<reset-code>&id=<uuid>
Se l'utente segue il link, l'hacker ha ora acquisito il codice di reimpostazione e può reimpostare la password per prendere il controllo dell'account.
SSRF cieco in Slack tramite iniezione di X-Forwarded-Host
Questo attacco aggira una convalida debole di X-Forwarded-Host per ottenere una SSRF blind su files.slack.com. Per prima cosa, files.slack.com tenta di convalidare l'intestazione Host e l'intestazione X-Forwarded-Host durante l'elaborazione, restituendo un codice di risposta HTTP 500 quando non sono files.slack.com. Tuttavia, la convalida di X-Forwarded-Host può essere aggirata aggiungendo un carattere @ alla fine del dominio. Quindi, l’hacker configura un dominio di callback per acquisire le richiesta (ad es. con Burp Collaborator, interactsh di ProjectDiscovery) e invia la seguente richiesta a slack.files.com:
GET /<URI> HTTP/1.1
Host: file.slack.com
...
X-Forwarded-Host: file.slack.com@www.unique-attackers-domain.example.com
Il files.slack.com nell'URL costruito dall'intestazione X-Forwarded-Host viene trattato come utente HTTP (HTTP BasicAuth), e www.unique-attackers-domain.example.com viene trattato come nome host. L'hacker riceve una richiesta da un sistema backend, a conferma dell'SSRF riuscito. Da qui, è possibile utilizzare diverse tecniche SSRF blind per tentare di far trapelare informazioni, interagire con i sistemi di backend e altro ancora.
Come prevenire gli attacchi di intestazione Host HTTP
Esistono diversi modi per prevenire gli attacchi all'intestazione Host HTTP, che variano in termini di efficacia e svantaggi. Di seguito troverai soluzioni pratiche per prevenire questo tipo di attacco.
Evita di usare il valore dell'intestazione Host e le sue varianti nel codice dell'applicazione
Il modo più semplice per prevenire gli attacco dell'intestazione Host è evitare di usare il valore dell'intestazione Host nel codice della tua applicazione. Inoltre, l'uso di configurazioni lato server o di URL relativi impedirà completamente gli attacchi all'intestazione Host.
Esegui una convalida rigorosa dei valori dell'intestazione host
Se devi usare il valore dell'intestazione Host, è opportuno utilizzare le seguenti tecniche per prevenire gli attacco all'intestazione Host:
Verifica che l'intestazione Host sia in un elenco di valori consentiti. Ad esempio, se la tua applicazione usa solo tre domini, assicurati che l'intestazione Host sia solo uno di questi tre valori.
Verifica che sia presente una sola intestazione Host. Le intestazioni Host duplicate possono talvolta essere usate per aggirare la convalida se la convalida e l'uso dell'intestazione finiscono per estrarre valori diversi dalla richiesta.
Evita di usare alternative e override dell'intestazione Host come X-Host o X-Forwarded-Host e, se devi farlo, segui le stesse raccomandazioni fornite per l'intestazione Host.
Come Fastly aiuta a prevenire gli attacchi all'intestazione Host HTTP
Segui la guida di Fastly sulla prevenzione del cache poisoning per assicurarti che siano attive protezioni aggiuntive.
Se utilizzi il Firewall per applicazioni web next-gen di Fastly, puoi aggiungere ulteriori protezioni contro gli attacco all'intestazione host HTTP per bloccare tutte le richieste con intestazione host non valide (ad es., quelle non presenti nell'elenco dei domini consentiti).
Riepilogo
L'intestazione Host è una parte vitale di internet (e di Fastly), ma quando l'intestazione Host è considerata implicitamente attendibile, usata per funzionalità aggiuntive o configurata in modo errato, gli hacker possono sfruttare questo comportamento iniettandovi diversi tipi di contenuti dannosi. Questo può consentire più tipi di attacco, tra cui avvelenamento dell'intestazione host, avvelenamento della cache web, avvelenamento del ripristino della password e server-side request forgery (SSRF). Utilizzando le soluzioni che abbiamo descritto, insieme alle indicazioni di Fastly per prevenire il cache poisoning, le applicazioni possono prevenire le varianti di attacco dell'intestazione host.