Immagina che qualcuno convinca un visitatore a cliccare su un link mentre è collegato al conto della sua banca. Il link porta a un modulo nascosto che, all'insaputa del visitatore, invia alla banca la richiesta di fare un bonifico. La banca vede una richiesta legittima da un utente autenticato e la esegue. Chi attacca ha spostato denaro usando il conto della vittima senza mai conoscere la sua password.
Questo è il CSRF (Cross-Site Request Forgery): un attacco in cui qualcuno induce una vittima a inviare, senza saperlo, un modulo o una richiesta a un altro sito in cui la vittima ha già effettuato l'accesso.
Che cosa imparerai: che cosa sono gli attacchi CSRF e come funzionano, perché sono così pericolosi anche quando ci sono altre misure di sicurezza, come i token CSRF li prevengono e come proteggere i tuoi moduli.
Che cos'è il CSRF?
CSRF (si legge "si-surf") sta per Cross-Site Request Forgery. È un attacco che sfrutta un fatto: se hai effettuato l'accesso a un sito, il tuo browser si fida automaticamente della tua sessione e la include in ogni richiesta che fai a quel sito, anche se la richiesta arriva da un altro sito.
L'attacco funziona inducendo un visitatore connesso a inviare, senza saperlo, un modulo a un sito in cui ha un account. Chi attacca non può vedere la password della vittima. Non gli serve. Gli basta che la vittima sia già connessa, e poi la induce a fare una richiesta (come inviare un modulo nascosto) che fa ciò che vuole l'attaccante.
Il CSRF è diverso dagli altri attacchi perché non richiede di rubare credenziali o di rompere la crittografia. Sfrutta la fiducia della vittima nel sito. La vittima è già autenticata, quindi il sito si fida delle richieste che sembrano arrivare da lei.
Come funzionano gli attacchi CSRF
Un attacco CSRF avviene in tre passaggi.
Passaggio 1: la vittima è connessa al tuo sito
Qualcuno visita il tuo sito e accede al suo account. Il suo browser ora ha un cookie di sessione attivo che dimostra che è autenticato. La sessione resta attiva finché continua a usare il sito.
Passaggio 2: chi attacca lo induce a visitare una pagina malevola
Mentre è ancora connessa al tuo sito, la vittima visita una pagina controllata dall'attaccante (magari un link sui social, una pubblicità ingannevole o un sito dall'aspetto legittimo). Su quella pagina c'è un codice nascosto che invia un modulo al tuo sito.
Passaggio 3: il modulo si invia da solo usando la sessione della vittima
Il modulo nascosto viene inviato al tuo sito. Poiché la vittima è già connessa, il suo browser include automaticamente il cookie di sessione nella richiesta. Dal punto di vista del tuo modulo, è una richiesta legittima di un utente autenticato. Il modulo la elabora come se la vittima l'avesse inviata di proposito.
Ora chi attacca ha fatto qualcosa sul tuo sito usando l'account della vittima, senza che lei lo sapesse. Può aver cambiato la password, trasferito denaro, aggiornato il profilo o inviato dati.
Perché funziona anche con altre misure di sicurezza
Gli attacchi CSRF aggirano diverse funzioni di sicurezza comuni:
L'HTTPS non ferma il CSRF. I dati sono cifrati durante il trasferimento, ma l'attaccante non ha bisogno di intercettarli. Invia la richiesta dal browser della vittima, di cui il browser si fida già.
La protezione con password non ferma il CSRF. L'attaccante non ha mai bisogno della password della vittima. Sfrutta il fatto che la vittima è già connessa.
Un buon sistema di accesso non ferma il CSRF. Anche se l'autenticazione è perfetta, se la vittima è connessa l'attacco funziona.
Per questo la protezione dal CSRF è un livello a sé. Le altre misure di sicurezza non la garantiscono. Devi progettare i moduli in modo specifico per resistere agli attacchi CSRF.
Token CSRF: come fermano l'attacco
La soluzione è un token CSRF. È una stringa unica e imprevedibile che il tuo server genera per ogni modulo. Funziona così:
Il tuo server crea un token unico per ogni visitatore
Quando qualcuno carica una pagina con un modulo, il server genera un token casuale e lo associa alla sessione di quell'utente. Il token è diverso ogni volta ed è unico per quell'utente.
Il token è inserito nel modulo
Il token è incluso come campo nascosto nel modulo HTML. Quando il visitatore invia il modulo, il token viaggia insieme ai dati.
Il tuo server verifica il token prima di elaborare l'invio
Quando il modulo viene inviato, il server controlla se il token ricevuto corrisponde a quello generato per la sessione di quell'utente. Se sì, il modulo viene elaborato. Se no (o se manca il token), il modulo viene respinto.
Il modulo nascosto dell'attaccante non può includere un token valido, perché i token sono imprevedibili e unici per ogni sessione. Chi attacca da un altro dominio non può vedere né indovinare il token. Quindi l'attacco fallisce. Il modulo nascosto viene inviato, ma il tuo server lo respinge perché il token non corrisponde.
Che aspetto ha un token CSRF nella pratica
In HTML, un modulo protetto dal CSRF si presenta così:
<form method="POST" action="/submit-form"> <input type="hidden" name="csrf_token" value="a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"> <input type="email" name="email" placeholder="Your email"> <button type="submit">Submit</button> </form>Il campo `csrf_token` è nascosto. Il visitatore non lo vede, ma viene inviato insieme ai dati del modulo. Il tuo server lo controlla prima di elaborare l'email o qualsiasi altro dato.
Protezione CSRF per i diversi tipi di modulo
Moduli HTML tradizionali
I moduli HTML standard (quelli che inviano i dati al server con POST) hanno bisogno dei token CSRF. Questo vale per i moduli di contatto, di accesso, di reimpostazione della password e per ogni modulo che modifica dati sul tuo server.
Moduli AJAX e JavaScript
Anche i moduli inviati con JavaScript a un endpoint API hanno bisogno della protezione CSRF. Il token può essere inserito nel modulo stesso, salvato in un cookie o letto da un meta tag prima di inviare la richiesta.
Richieste API senza stato
Se la tua API usa l'autenticazione con token (come JWT), la protezione CSRF funziona in modo diverso. Il browser non può allegare automaticamente un token JWT come fa con un cookie di sessione, quindi il CSRF tradizionale è una minaccia minore. La buona pratica resta comunque aggiungere un token CSRF per una protezione extra.
Altre protezioni che lavorano con i token CSRF
I token CSRF sono la difesa principale, ma funzionano meglio insieme ad altre pratiche di sicurezza.
Cookie SameSite
Quando imposti un cookie di sessione, puoi aggiungere l'attributo `SameSite`, che dice al browser di non includere il cookie quando la richiesta arriva da un altro dominio. In questo modo il modulo nascosto dell'attaccante non può usare affatto la sessione della vittima.
Controllo dell'header Referer
Il tuo server può controllare l'header Referer per vedere da dove arriva la richiesta. Se un invio dichiara di arrivare dal tuo dominio ma il Referer indica un altro dominio, probabilmente è un attacco. (Gli header Referer però si possono falsificare, quindi questa non è una difesa completa.)
Schema del cookie a doppio invio
In questo approccio il token CSRF viene salvato sia in un cookie sia in un campo del modulo. Il server controlla che coincidano prima di elaborare i dati. È meno comune dei token tradizionali, ma funziona bene per le applicazioni senza stato.
Come implementare la protezione CSRF
I dettagli dipendono dalla tua tecnologia, ma lo schema è lo stesso:
- Genera un token unico per sessione. Quando un utente avvia una sessione o carica una pagina con un modulo, il tuo backend genera un nuovo token.
- Salva il token lato server. Conservalo associato alla sessione di quell'utente.
- Includi il token nel modulo. Aggiungilo come campo nascosto nell'HTML o come meta tag che JavaScript può leggere.
- Convalida all'invio. Prima di elaborare i dati del modulo, controlla che il token inviato corrisponda a quello salvato per quella sessione.
- Rigenera dopo le azioni sensibili. Dopo che un utente cambia la password o fa qualcosa di critico, genera un nuovo token.
La maggior parte dei framework moderni gestisce in automatico la generazione e la convalida dei token CSRF. Se usi un framework, di solito la protezione CSRF è attiva di default. Assicurati solo di non disattivarla per errore.
Errori comuni che lasciano i moduli vulnerabili
Disattivare la protezione CSRF per comodità. Alcuni sviluppatori spengono i controlli CSRF per testare più facilmente l'API o per semplificare il codice. Non farlo. Crea una vulnerabilità reale.
Usare un token statico per tutti gli utenti. Il token deve essere unico per la sessione di ogni utente. Un token uguale per tutti (o uguale per tutti gli utenti in tutti i giorni) non protegge dal CSRF.
Non rigenerare i token. Se usi lo stesso token per settimane, chi attacca ha più tempo per sfruttarlo. Rigenera i token con regolarità e sempre dopo le operazioni sensibili.
Affidarsi solo ai cookie SameSite. SameSite aiuta ma non basta. Usa i token CSRF come difesa principale e SameSite come riserva.
Dimenticare i token su alcuni moduli. Se proteggi alcuni moduli con i token e altri no, chi attacca userà quelli non protetti. Ogni modulo che modifica dati ha bisogno di protezione.
Che cosa fa WEMASY per la protezione CSRF
I moduli WEMASY includono in automatico la protezione con token CSRF su ogni modulo che crei. Non devi configurarla né pensarci. Quando un visitatore invia un modulo, WEMASY convalida il token prima di salvare l'invio. Questa protezione è integrata e attiva di default.
Scopri di più sulle opzioni di sicurezza dei moduli nella pagina prezzi.