CSRF

CSRF (Cross-Site Request Forgery) è un attacco in cui un sito malevolo causa al browser di una vittima l’emissione di una richiesta autenticata contro un sito di destinazione, sfruttando i cookie che il browser allega automaticamente.

Esempio classico: si è connessi a bank.example.com. Si visita evil.example, che contiene <img src="https://bank.example.com/transfer?to=attacker&amount=1000" />. Il browser invia diligentemente la richiesta con i cookie della sessione bancaria. La banca, incapace di distinguere l’origine legittima, elabora il trasferimento.

Difese moderne:

• Attributo cookie SameSite (predefinito Lax nei browser moderni) — blocca i cookie dalle richieste POST cross-origin.
• Token CSRF — token casuali emessi dal server inclusi nei moduli, verificati all’invio. Standard del settore da decenni.
• Validazione dell’header Origin/Referer — difesa in profondità.
• Autenticazione con bearer token (negli header, non nei cookie) — immune a CSRF per impostazione predefinita.

I framework moderni (Django, Rails, Spring) hanno la protezione CSRF abilitata per impostazione predefinita. La modifica del cookie default-Lax del 2020 ha effettivamente eliminato CSRF per la maggior parte delle app moderne senza alcuna modifica al codice.

Esempio pratico

Una vulnerabilità del 2008 in molti router domestici illustra l’attacco classico. L’interfaccia di amministrazione del router era su http://192.168.1.1/, usava cookie di basic-auth ed esponeva un modulo come POST /apply.cgi?dns=... per cambiare il server DNS. Un attaccante controllava un sito web separato che includeva un modulo invisibile auto-inviante che puntava a quell’URL. Un utente connesso che visitava la pagina malevola avrebbe avuto il proprio browser a inviare silenziosamente il modulo al router, con i cookie di autenticazione allegati automaticamente, e il DNS sarebbe stato sostituito con quello dell’attaccante. Dal punto di vista del router ogni richiesta sembrava legittima. La correzione su cui si è stabilita l’industria: aggiungere un token CSRF per sessione al modulo, convalidarlo all’invio e rifiutare le richieste in cui il token è mancante o errato. Una seconda correzione è arrivata con i cookie SameSite=Lax in Chrome 80 (2020) — il browser smette di inviare cookie su POST cross-site, sconfiggendo l’attacco a livello di cookie indipendentemente dai controlli lato server.

Quando e perché è importante

CSRF è importante ogni volta che un’applicazione autentica gli utenti tramite cookie che vengono allegati automaticamente dal browser — che sono la maggior parte delle app web legacy e molte moderne. L’errore è presumere che “siamo un’API, CSRF non si applica”: se l’API usa cookie di sessione (anziché bearer token) e accetta POST form-encoded o JSON semplici senza preflight, è vulnerabile. Il secondo errore è fare affidamento esclusivamente sull’header Referer — molti proxy aziendali e strumenti per la privacy lo rimuovono, rompendo gli utenti legittimi. Il minimo moderno per un’app basata su cookie: impostare SameSite=Lax (o Strict per gli endpoint sensibili) su tutti i cookie di autenticazione, convalidare un token CSRF su ogni richiesta che modifica lo stato e rifiutare le richieste con header Origin non corrispondenti sugli endpoint JSON. Per le nuove API, passare completamente all’autenticazione con bearer token tramite l’header Authorization e la superficie di attacco scompare. Riferimento: OWASP — Cross-Site Request Forgery.

Il pattern double-submit cookie: quando un backend non può memorizzare lo stato per sessione, il token CSRF può essere emesso tramite un cookie e richiesto di apparire anche in un header di richiesta personalizzato. Il browser allega automaticamente il cookie su ogni richiesta, ma i siti cross-origin non possono leggerne il valore per copiarlo nell’header — la same-origin policy blocca la lettura. Il server confronta i due e rifiuta le discrepanze. Questa è la tecnica che la maggior parte dei framework per applicazioni a pagina singola moderni (Angular, la configurazione predefinita di Axios) usa per la difesa CSRF sulle API JSON.

Perché CSRF è sempre più irrilevante: la combinazione di default SameSite=Lax (Chrome 80, 2020), autenticazione con bearer token e preflight CORS su richieste non semplici ha ridotto la superficie di attacco pratica agli endpoint form-encoded legacy che si affidano ancora ai cookie. Per le nuove API costruite oggi, rinunciare completamente ai cookie e usare header Authorization: Bearer <token> elimina CSRF senza cerimonie. L’OWASP ha rimosso CSRF dalla lista Top 10 nel 2017 a causa della diffusione delle difese strutturali. Riferimento: OWASP CSRF Prevention Cheat Sheet.