Cache Poisoning

Voci di Glossario Sicurezza Informatica
Indice dei contenuti

    Il cache poisoning è una classe di attacchi in cui un avversario manipola la cache di un sistema intermedio — CDN, reverse proxy, server DNS, cache del browser — in modo che le successive richieste legittime ricevano contenuto falsificato, malevolo o controllato dall’attaccante. Il payload viene depositato una sola volta; la cache lo distribuisce automaticamente a tutti i successivi richiedenti per tutta la durata del TTL.

    Esistono due varianti principali con meccanismi distinti: Web Cache Poisoning e DNS Cache Poisoning.

    Web Cache Poisoning

    I server di cache (CDN, Varnish, Nginx) memorizzano le risposte HTTP e le riservono a richieste successive con la stessa cache key. La cache key include tipicamente metodo HTTP, host e path — ma non tutti gli header della richiesta.

    Header non-keyed

    Alcuni header influenzano la risposta del back-end senza fare parte della cache key. Se il back-end riflette il valore di un header non-keyed nella risposta (es. X-Forwarded-Host, X-Forwarded-For, X-Original-URL), un attaccante può:

    1. Inviare una richiesta con un header non-keyed malevolo: X-Forwarded-Host: evil.it.
    2. Il back-end genera una risposta che include quel valore — es. un URL assoluto, un redirect, o un tag <script src="https://evil.it/script.js">.
    3. La CDN mette in cache la risposta usando la cache key standard (senza l’header malevolo).
    4. Le successive richieste legittime — senza l’header — ricevono la risposta avvelenata.

    La tecnica fu sistematizzata da James Kettle (PortSwigger) nel paper Practical Web Cache Poisoning (2018).

    Impatti del web cache poisoning

    • XSS persistente: iniettare script malevoli nella risposta cachata, distribuiti a tutti gli utenti che visitano la pagina.
    • Redirect hijacking: far sì che la cache serva redirect verso siti di phishing per URL legittime.
    • Denial of Service: avvelenare la cache con risposte di errore (es. 404) per URL valide.
    • Cookie injection: in alcuni scenari, iniettare header Set-Cookie nella risposta cachata.

    Parametri GET non-keyed

    Alcune implementazioni non includono tutti i parametri query nella cache key. Un parametro ignorato dalla cache ma riflesso nella risposta è sfruttabile per poisoning:

    GET /pagina?q=ricerca&utm_source=<script>alert(1)</script> HTTP/1.1

    Se utm_source non è nella cache key ma il suo valore appare nella risposta (es. nei meta analytics), la risposta avvelenata viene cachata per /pagina?q=ricerca — qualsiasi utente che visiti quella URL riceve l’XSS.

    DNS Cache Poisoning

    Il DNS cache poisoning (o DNS spoofing) avvelena la cache di un resolver DNS, associando un nome di dominio a un indirizzo IP controllato dall’attaccante. Tutte le macchine che usano quel resolver vengono indirizzate al server malevolo per tutta la durata del TTL del record.

    Meccanismo classico (pre-DNSSEC)

    Il resolver DNS invia una query a un nameserver autorevole e attende la risposta. L’attaccante, se riesce a rispondere prima del nameserver legittimo con un pacchetto UDP che ha i parametri corretti (indirizzo sorgente del nameserver + port corretta + Query ID corretto), può inserire un record falsificato nella cache.

    L’attacco di Kaminsky (2008) dimostrò che il Query ID a 16 bit (65.536 valori possibili) poteva essere forzato in tempi pratici inondando il resolver con risposte falsificate prima che arrivasse quella legittima.

    DNSSEC

    DNSSEC firma crittograficamente i record DNS, permettendo ai resolver di verificarne l’autenticità. Elimina il DNS cache poisoning tradizionale ma non è ancora universalmente adottato — molti TLD e domini non lo implementano.

    La voce dedicata DNS Security approfondisce DNSSEC, DoH e DoT.

    Contromisure per il Web Cache Poisoning

    Normalizzazione degli header nel front-end: il proxy deve normalizzare o rimuovere gli header non-keyed prima di inoltrarli al back-end, oppure includerli nella cache key.

    Evitare la riflessione di header nella risposta: il back-end non dovrebbe riflettere header arbitrari della richiesta nelle risposte — in particolare in URL, redirect e nel DOM.

    Cache key estesa: configurare la cache per includere nella cache key tutti gli header e parametri che influenzano la risposta.

    Vary header corretto: l’header Vary indica quali header della richiesta fanno parte della cache key — deve includere tutti gli header che il back-end usa per generare risposte diverse.

    Fat GET → POST: convertire endpoint che accettano parametri sensibili in POST (non cachati per default) piuttosto che GET.

    Relazione con altri argomenti

    Ultimo aggiornamento: