Il CSRF: l'azione forzata a sua insaputa

L'attaccante comincia individuando una richiesta che modifica qualcosa su un servizio, poi costruisce un indirizzo o uno script che la riproduce con i propri valori. OWASP porta l'esempio di una banca fittizia: la richiesta legittima trasferisce 100 dollari a un beneficiario, e l'attaccante sostituisce il beneficiario con sé stesso aumentando l'importo¹.

Resta da far caricare questa richiesta alla vittima mentre è connessa. Si citano due metodi: un'e-mail non richiesta con contenuto HTML, oppure una trappola collocata su pagine che la vittima è probabile visiti mentre usa il suo servizio online¹.

L'attacco può anche essere memorizzato sul sito vulnerabile stesso, per esempio in un campo che accetta HTML. Diventa allora più probabile: la vittima consulta più volentieri una pagina del sito che una pagina qualunque di Internet, e vi è necessariamente già connessa¹.

Spesso, niente. Il link trappola può essere mascherato da link ordinario, con un testo del tipo «guarda le mie foto». Può anche assumere la forma di una falsa immagine di dimensione zero: se compare in un'e-mail, la vittima non vede nulla, ma il browser invia comunque la richiesta, senza alcun segno visivo che l'operazione sia avvenuta¹.

Illustrazione neutralizzata, non un indirizzo reale.
Link mascherato: testo visualizzato «Guarda le mie foto», indirizzo nascosto
hxxp://banque[.]exemple[.]invalid/virement?dest=[conto dell'attaccante]&montant=[elevato]
Variante: immagine invisibile in un'e-mail, caricata senza clic.

Se il servizio si aspetta una richiesta di tipo POST, l'attaccante può ospitare sul proprio sito un modulo con campi nascosti. La vittima crede che faccia altro e clicca, oppure uno script lo invia automaticamente al caricamento della pagina¹. In entrambi i casi la pagina visualizzata è banale e l'azione si svolge altrove.

Il meccanismo dipende da un comportamento normale dei browser. Essi memorizzano i cookie emessi da un'applicazione, compresi i cookie di sessione degli utenti autenticati, e inviano tutti i cookie di un dominio a ogni richiesta, qualunque sia il modo in cui quella richiesta è nata nel browser². I cookie non sono gli unici coinvolti: anche le autenticazioni di tipo Basic e Digest sono vulnerabili, perché il browser rinvia automaticamente le credenziali fino alla fine della sessione².

Secondo OWASP, diverse idee di difesa non funzionano¹:

• un cookie segreto, poiché tutti i cookie vengono inviati con ogni richiesta;
• accettare solo richieste POST, poiché basta un modulo nascosto per contraffarne una;
• le transazioni in più passaggi, finché l'attaccante può prevedere ogni passaggio;
• la sola verifica dell'intestazione Referer, perché può essere falsificata ed è talvolta assente per ragioni di riservatezza.

Le protezioni raccomandate, lato applicazione, sono le seguenti.

• Verificare prima se il framework offre già una protezione CSRF, e usarla. In mancanza, aggiungere token anti-CSRF a tutte le richieste che modificano lo stato e validarli lato server³. Senza token, l'attaccante non può costruire una richiesta valida³.
• Per i software senza stato, usare un cookie a doppio invio, preferibilmente firmato³.
• Impostare l'attributo SameSite sui cookie di sessione³. Con il valore strict, il browser non invia il cookie nelle richieste tra siti diversi, nemmeno seguendo un link ordinario. Con lax, lo invia per un link seguito da un altro sito ma lo trattiene sui metodi esposti al CSRF come POST⁴. Con none, non è offerta alcuna protezione⁴.
• Controllare l'origine con le intestazioni standard, in particolare Sec-Fetch-Site, supportata da tutti i principali browser da marzo 2023³.
• Non usare richieste GET per operazioni che modificano lo stato³.

Queste misure hanno dei limiti. SameSite=Lax lascia passare le richieste GET di navigazione di primo livello: un punto di accesso che modifica lo stato tramite GET resta vulnerabile². I browser meno recenti possono non applicare SameSite². E una falla XSS può aggirare tutte le protezioni anti-CSRF; il worm Samy, per esempio, ha usato una XMLHttpRequest per ottenere il token CSRF e contraffare richieste¹³. Il comportamento predefinito di SameSite varia: a dicembre 2024, lax era il valore predefinito di Chrome, Edge e Opera, ma di nessuna versione di Firefox né di Safari, da cui il consiglio di impostarlo esplicitamente⁴.

2008: l'exploit uTorrent

OWASP cita, come esempio reale di attacco CSRF contro un'applicazione che funziona tramite richieste GET, un exploit rivolto a uTorrent risalente al 2008. È stato usato su larga scala per scaricare software dannoso¹. La fonte non dice altro: né il numero delle vittime, né il modo di diffusione.

Falle catalogate dal CWE (identificativi dal 2004 al 2009)

Il CWE-352 fornisce un elenco scelto di esempi osservati, che non è esaustivo⁵. Diversi si basano su un semplice URL in un tag img: CVE-2004-1703 e CVE-2004-1995 permettono di aggiungere account utente, CVE-2004-1842 di ottenere privilegi di amministratore⁵. Altri riguardano la gestione stessa: CVE-2009-3520 permette di modificare la password dell'amministratore, e CVE-2009-3759 di cambiare password o di arrestare una macchina virtuale da un'interfaccia web⁵.