Immagina di essere collegato al pannello amministrativo del tuo sito web. Hai effettuato il login, il browser conserva la tua sessione e puoi gestire utenti, modificare impostazioni o aggiornare contenuti.
Mentre lavori, apri un'altra scheda e visiti una pagina apparentemente innocua.
Quello che non sai è che quella pagina potrebbe tentare di inviare una richiesta a un servizio sul quale sei già autenticato, sfruttando il fatto che il browser può allegare automaticamente i cookie di sessione.
È proprio questo il principio alla base del CSRF, acronimo di Cross-Site Request Forgery.
Si tratta di una vulnerabilità conosciuta da molti anni, ma ancora importante perché riguarda una delle componenti fondamentali delle applicazioni web: il rapporto tra browser, sessioni e autorizzazioni.
Vediamo come funziona, quando rappresenta un rischio concreto e quali misure permettono di prevenirla.
Che cos'è un attacco CSRF?
Il Cross-Site Request Forgery è una tecnica con cui un attaccante cerca di indurre il browser di un utente autenticato a effettuare un'operazione indesiderata su un'applicazione web.
Il punto fondamentale è che la richiesta viene eseguita nel contesto della sessione della vittima, non necessariamente utilizzando credenziali conosciute dall'attaccante.
Supponiamo che un'applicazione consenta di modificare l'indirizzo email associato a un account.
L'utente ha già effettuato l'accesso e il browser possiede un cookie di sessione valido.
Se l'applicazione accetta una richiesta di modifica senza verificare adeguatamente la sua origine, una pagina esterna potrebbe tentare di provocare quell'operazione.
Il server potrebbe interpretare la richiesta come legittima perché riconosce la sessione autenticata.
In realtà, però, l'utente non ha autorizzato consapevolmente quella modifica.
Come funziona un CSRF nella pratica?
Per comprendere il meccanismo, consideriamo un'applicazione che permette di modificare alcune preferenze attraverso una richiesta HTTP.
Il flusso normale è semplice:
- L'utente effettua il login.
- Il server crea una sessione autenticata.
- Il browser conserva il cookie associato alla sessione.
- L'utente modifica un'impostazione attraverso un modulo.
- Il browser invia la richiesta al server.
Fin qui tutto regolare.
Il problema emerge quando il server considera sufficiente la presenza del cookie per stabilire che una determinata operazione sia stata effettivamente richiesta dall'utente.
Un sito esterno potrebbe tentare di far partire una richiesta verso l'applicazione vulnerabile.
Se il browser include le credenziali di sessione e non esistono controlli adeguati, l'operazione potrebbe essere accettata.
Naturalmente, il successo dell'attacco dipende da diversi fattori, tra cui il metodo HTTP utilizzato, le impostazioni dei cookie e le protezioni implementate dall'applicazione.
Perché il browser può contribuire al problema?
I cookie sono fondamentali per il funzionamento di moltissimi siti web.
Quando effettui il login, il server può assegnarti un identificatore di sessione che il browser conserva e invia nelle richieste successive.
Questo evita di dover inserire continuamente nome utente e password.
Tuttavia, i cookie vengono gestiti automaticamente dal browser secondo le regole previste per dominio, percorso e attributi di sicurezza.
Un'applicazione non dovrebbe quindi interpretare la sola presenza del cookie come prova che ogni richiesta sia stata avviata intenzionalmente dall'utente.
È proprio questa distinzione a rendere necessarie le protezioni contro il CSRF.
CSRF e XSS: qual è la differenza?
CSRF e Cross-Site Scripting vengono spesso confusi perché entrambi coinvolgono il browser.
In realtà, funzionano in modo diverso.
Nel caso di un XSS, l'attaccante riesce a far eseguire codice JavaScript non attendibile nel contesto di un sito vulnerabile.
Nel caso di un CSRF, invece, l'obiettivo è indurre il browser a inviare una richiesta non desiderata verso un'applicazione nella quale l'utente è autenticato.
Un attacco CSRF non richiede necessariamente l'esecuzione di JavaScript sul sito bersaglio.
Esiste però una relazione importante: una vulnerabilità XSS può spesso compromettere anche le protezioni CSRF dell'applicazione.
Per questo motivo, i due problemi devono essere affrontati come parti di una strategia di sicurezza complessiva.
Quali operazioni possono essere coinvolte?
Un attacco CSRF può interessare diverse funzionalità, soprattutto quelle che modificano dati o configurazioni.
Alcuni esempi sono:
- Modifica dell'indirizzo email.
- Aggiornamento delle preferenze di sicurezza.
- Creazione o eliminazione di risorse.
- Modifica delle autorizzazioni.
- Esecuzione di operazioni amministrative.
- Invio di richieste che producono conseguenze economiche.
Il rischio aumenta quando l'operazione è particolarmente sensibile e non richiede ulteriori verifiche.
📌 Un principio importante è che le richieste GET non dovrebbero modificare lo stato dell'applicazione.
Se un'operazione critica viene eseguita semplicemente visitando un URL, la superficie di rischio può aumentare.
Utilizzare POST, PUT o DELETE per le modifiche è una buona pratica, ma da solo non elimina il CSRF.
Come prevenire il CSRF con i token
Una delle difese più consolidate consiste nell'utilizzo di un token CSRF.
Il server genera un valore imprevedibile e lo associa alla sessione dell'utente.
Quando viene mostrato un modulo che esegue un'operazione sensibile, il token viene incluso nella richiesta.
Il server verifica che il valore ricevuto corrisponda a quello atteso.
Se manca oppure non è valido, l'operazione viene rifiutata.
Esempio di protezione CSRF in PHP
Consideriamo una semplice applicazione PHP che utilizza le sessioni.
Prima di mostrare il modulo, possiamo generare un token:
<?php
session_start();
if (empty($_SESSION['csrf_token'])) {
$_SESSION['csrf_token'] =
bin2hex(random_bytes(32));
}
$token = $_SESSION['csrf_token'];
Il token viene poi inserito nel modulo:
<form method="POST" action="/account/update.php">
<input
type="hidden"
name="csrf_token"
value="<?= htmlspecialchars(
$token,
ENT_QUOTES,
'UTF-8'
) ?>"
>
<button type="submit">
Salva modifiche
</button>
</form>
Quando il server riceve la richiesta, verifica il token:
<?php
session_start();
$receivedToken = $_POST['csrf_token'] ?? '';
$expectedToken = $_SESSION['csrf_token'] ?? '';
if (
!is_string($receivedToken) ||
!is_string($expectedToken) ||
$expectedToken === '' ||
!hash_equals($expectedToken, $receivedToken)
) {
http_response_code(403);
exit('Richiesta non autorizzata');
}
// Proseguire con autenticazione,
// autorizzazione e validazione dei dati.
L'esempio illustra il principio del Synchronizer Token Pattern.
In un'applicazione reale, il controllo deve essere integrato con la gestione delle sessioni, la verifica dei permessi e la validazione degli input.
Il token non dovrebbe essere trasmesso attraverso URL che potrebbero finire nella cronologia del browser o nei log.
Il ruolo dei cookie SameSite 🍪
Un'altra misura importante è rappresentata dall'attributo SameSite dei cookie.
Questo attributo influenza le condizioni nelle quali il browser invia un cookie durante richieste che coinvolgono siti differenti.
Le principali modalità sono:
SameSite=Strict
Offre una protezione restrittiva, limitando l'invio del cookie nelle richieste provenienti da contesti cross-site.
SameSite=Lax
Consente alcuni utilizzi cross-site, per esempio determinate navigazioni di primo livello, ma limita altre richieste.
SameSite=None
Consente l'utilizzo del cookie anche in contesti cross-site. Nei browser moderni richiede l'attributo Secure.
Per un'applicazione PHP, una configurazione potrebbe essere:
<?php
session_set_cookie_params([
'lifetime' => 0,
'path' => '/',
'secure' => true,
'httponly' => true,
'samesite' => 'Lax',
]);
session_start();
Questa configurazione presuppone che il sito utilizzi HTTPS.
È importante sottolineare che SameSite costituisce una difesa aggiuntiva e non dovrebbe essere considerato un sostituto universale dei token CSRF.
Controllare Origin e Referer
Le applicazioni possono utilizzare anche gli header HTTP Origin e, in determinati casi, Referer per verificare la provenienza delle richieste.
Per esempio, se un'operazione amministrativa dovrebbe essere eseguita soltanto dal dominio dell'applicazione, il server può verificare che l'origine corrisponda a quella prevista.
Questo controllo richiede attenzione.
Gli header potrebbero non essere presenti in tutte le situazioni e la verifica deve confrontare correttamente schema, hostname e porta.
È preferibile applicare una politica esplicita e coerente, evitando confronti superficiali tra stringhe.
Le API sono vulnerabili al CSRF?
Dipende da come viene gestita l'autenticazione.
Un'API che utilizza cookie di sessione inviati automaticamente dal browser può essere esposta a rischi CSRF.
Un'API che richiede un token Bearer inserito esplicitamente in un header Authorization presenta invece un modello differente.
In quest'ultimo caso, una pagina esterna non può normalmente obbligare il browser ad allegare automaticamente quel token.
Questo non significa che l'API sia sicura per definizione: rimangono importanti la protezione dei token, le regole CORS, l'autorizzazione e la prevenzione dell'XSS.
Come verificare la presenza di vulnerabilità CSRF
Durante una revisione di sicurezza è utile controllare le operazioni che modificano lo stato dell'applicazione.
Bisogna verificare se:
- Le richieste sensibili utilizzano token CSRF o altre protezioni adeguate.
- I token vengono effettivamente verificati dal server.
- Le operazioni GET producono modifiche non previste.
- I cookie di sessione utilizzano attributi appropriati.
- I controlli di origine sono coerenti.
- Le operazioni particolarmente delicate richiedono eventualmente una nuova autenticazione.
I test devono essere eseguiti esclusivamente su applicazioni proprie o per le quali si dispone di autorizzazione.
Conclusione
Il CSRF è un esempio interessante di come un'applicazione possa essere vulnerabile anche quando il sistema di login funziona correttamente.
Il problema non è necessariamente l'identificazione dell'utente, ma la capacità di distinguere una richiesta realmente autorizzata da un'operazione indotta da un sito esterno.
Token CSRF, cookie configurati correttamente, controlli sull'origine e gestione rigorosa delle operazioni sensibili permettono di ridurre significativamente il rischio.
Per approfondire le tecniche di prevenzione puoi consultare la guida OWASP dedicata al CSRF.
Con MiHakero puoi affiancare a queste verifiche applicative il controllo delle esposizioni esterne e delle configurazioni di sicurezza dei tuoi servizi pubblici, ottenendo una visione più completa degli aspetti da proteggere.
SEO Meta Title: CSRF: cos'è, come funziona e come prevenirlo
SEO Meta Description: Scopri cos'è un attacco CSRF, come sfrutta le sessioni web e quali protezioni utilizzare in PHP e nelle applicazioni moderne.