CSRF (Cross-Site Request Forgery)

Il Cross-Site Request Forgery (CSRF, pronunciato «sea-surf») è una vulnerabilità web che sfrutta la fiducia che un’applicazione ripone nel browser dell’utente autenticato. L’attaccante costruisce una richiesta HTTP verso l’applicazione vittima e induce il browser dell’utente — già autenticato — a inviarla a sua insaputa. Poiché il browser allega automaticamente i cookie di sessione a ogni richiesta verso il dominio corrispondente, l’applicazione non è in grado di distinguere la richiesta legittima dell’utente dalla richiesta forgiata dall’attaccante.

Meccanismo

Il vettore classico è una pagina web controllata dall’attaccante che contiene una richiesta verso l’applicazione vittima:

<!-- Su pagina controllata dall'attaccante -->
<img src="https://banca.esempio.it/trasferisci?importo=1000&destinatario=attaccante">

Quando la vittima carica la pagina dell’attaccante mentre è autenticata su banca.esempio.it, il browser invia automaticamente la richiesta GET — con il cookie di sessione allegato. Per richieste POST, l’attaccante usa un form con autosubmit:

<form action="https://banca.esempio.it/trasferisci" method="POST" id="f">
  <input name="importo" value="1000">
  <input name="destinatario" value="attaccante">
</form>
<script>document.getElementById('f').submit()</script>

La vittima non vede nulla — il submit avviene invisibilmente.

Condizioni necessarie

Tre condizioni devono essere soddisfatte contemporaneamente:

1. L’utente è autenticato sull’applicazione target (sessione cookie attiva)
2. L’azione che l’attaccante vuole eseguire è raggiungibile con una richiesta HTTP prevedibile
3. L’applicazione non implementa difese CSRF

Se l’azione richiede la conoscenza di un valore segreto che l’attaccante non possiede (es. la password corrente per cambiare email), il CSRF non è sfruttabile anche senza difese esplicite.

CSRF vs. XSS

Spesso confusi, sono vulnerabilità distinte:

	CSRF	XSS
Cosa sfrutta	La fiducia dell’app nel browser dell’utente	La fiducia dell’utente nel contenuto del sito
Cosa fa	Invia richieste indesiderate	Esegue script nel browser della vittima
Richiede JS?	No (può usare <img>, <form>)	Sì
Cookie HttpOnly?	Non aiuta	Protegge i cookie da JS

Difese

CSRF token (Synchronizer Token Pattern): l’applicazione genera un valore segreto casuale per ogni sessione (o per ogni form), lo include nel form come campo nascosto e lo verifica lato server a ogni richiesta che modifica stato. L’attaccante non può conoscere il token — non può leggerlo dalla pagina dell’utente per via della Same-Origin Policy.

Double Submit Cookie: il token è impostato come cookie e come parametro del form. Il server verifica che coincidano. Più semplice da implementare in architetture distribuite, ma meno sicuro se il sito ha sottodomini vulnerabili a cookie injection.

SameSite cookie attribute: attributo del cookie che controlla quando il browser lo invia in richieste cross-site:

• SameSite=Strict: il cookie non viene mai inviato in richieste cross-site
• SameSite=Lax: inviato solo per navigazione top-level (click su link), non per richieste embed (<img>, <iframe>, form POST)
• SameSite=None: comportamento precedente (inviato sempre), richiede Secure

SameSite=Lax è il default moderno nei browser principali e mitiga la maggior parte degli attacchi CSRF senza configurazione esplicita — ma non tutti (la navigazione top-level con GET è ancora permessa).

Verifica dell’Origin/Referer header: controllare che la richiesta provenga dalla stessa origine. Meno affidabile dei token (alcuni browser e proxy rimuovono i header), usato come difesa aggiuntiva.