Cosa significa cross-site request forgery e come proteggersi

Proteggere un sito non significa solo impedire accessi non autorizzati. Ci sono attacchi, chiamati CSRF, che non puntano a impadronirsi delle credenziali degli utenti ma a far eseguire delle azioni fraudolente agli utenti autenticati a loro insaputa.

In questa guida vedremo cos’è il cross-site request forgery, come funziona a livello pratico e tecnico e in che modo sfrutta le richieste HTTP. Scoprirai i principali metodi per prevenire gli attacchi CSRF e gli errori da evitare per mantenere il tuo sito sicuro.

Cosa significa cross-site request forgery (CSRF)

Il cross-site request forgery (CSRF), che in italiano significa “falsificazione di richiesta tra siti”, è un tipo di attacco informatico in cui un utente viene indotto a compiere delle azioni indesiderate, senza rendersene conto, su un sito web su cui si è autenticato. A fare da esca possono essere pulsanti che mostrano inviti all’azione banali, come “Scopri l’offerta”, dietro i quali si nascondono richieste fraudolente.

A differenza di quanto avviene negli attacchi alla riservatezza delle informazioni però, nel CSRF lo scopo degli hacker non è sottrarre dati ma far compiere all’utente un’azione precisa, infatti è classificato come attacco all’integrità delle operazioni.

Il CSRF è definito anche attacco cieco perché gli hacker non vedono la risposta del server, ma non ne hanno bisogno.

Come funziona un attacco CSRF? 

Per capire come funziona un attacco cross-site request forgery, immagina di eseguire il login su un qualsiasi sito e poi, mentre la sessione è attiva, continuare la navigazione su pagine esterne. Una di queste potrebbe contenere un pulsante apparentemente innocuo, come “Scopri di più”, che in realtà contiene un link che invia una richiesta fraudolenta al server dell’ecommerce. Se clicchi sul pulsante, il sito su cui hai eseguito l’accesso la riceverà e la eseguirà, perché non è in grado di verificare il contesto da cui proviene.

Nell’ambito della sicurezza informatica questa vulnerabilità è chiamata confused deputy – in italiano delegato confuso – perché il server, che dovrebbe agire per conto dell’utente, non è capace di distinguere una richiesta volontaria da un’involontaria. E i criminali informatici ne approfittano nascondendo richieste all’interno di pagine web malevole.

L’azione innescata dal sito fraudolento può essere qualsiasi operazione che un visitatore autenticato possa compiere su quel sito. Per esempio se accedi ai servizi online della tua banca e navighi su altri siti mentre la sessione è ancora attiva, cliccando su link e pulsanti apparentemente innocui potresti inviare al server una richiesta che trasferisce denaro dal tuo conto a quello di un gruppo di criminali informatici.

Per indurre l’utente a eseguire l’azione che desiderano, spesso gli hacker sfruttano tecniche di ingegneria sociale, cioè strategie che manipolano il comportamento dell’utente creando curiosità o senso di urgenza, come un’offerta limitata o una notifica di sicurezza falsa.

Come avviene un attacco CSRF a livello tecnico

Gli attacchi CSRF si possono verificare grazie a due meccanismi usati nel web per rendere la navigazione più fluida: l’uso dei cookie di sessione e la possibilità per le pagine web di inviare richieste verso altri siti.

Quando effettui il login su un sito, il server crea e salva nel browser un cookie, cioè un piccolo file che tiene traccia della sessione e identifica la tua utenza. Questo ti permette di navigare per un certo lasso di tempo senza dover inserire in continuazione le tue credenziali. Il problema è che il browser allega in automatico il cookie di sessione a ogni richiesta verso quel sito, anche se è stata generata da una pagina esterna, per cui per il server è impossibile distinguere le richieste che provengono dallo stesso sito e quelle che provengono da pagine esterne. 

Succede anche perché i browser sono progettati per permettere alle pagine web di caricare risorse da altri domini, come immagini, script o servizi di terze parti. In caso contrario l’esperienza utente in WordPress e altre piattaforme sarebbe molto peggiore.

In passato era molto facile far partire richieste fraudolente anche senza il clic dell’utente, alla sola apertura della pagina. Bastava inserire elementi come:

• tag HTML a caricamento automatico;
• moduli POST nascosti nel codice JavaScript, che viene inviato al caricamento della pagina;
• script in background che usano AJAX o Fetch per inviare richieste al browser in modo asincrono.

Oggi è molto difficile far partire in questo modo attacchi cross-site request forgery perché i browser aggiornati bloccano le richieste automatiche o invisibili provenienti da siti esterni.

Attacchi CSRF e richieste HTTP

Gli attacchi CSRF sfruttano diversi tipi di richieste HTTP.

Le richieste POST sono le più comuni, perché vengono usate per modificare dati e compiere azioni sul server.

In teoria anche i metodi GET, PUT e DELETE potrebbero essere sfruttati negli attacchi cross-site request forgery, ma ormai è molto raro grazie alle regole per la sicurezza applicate dai browser.

Differenza tra CSRF e altri attacchi simili

È facile confondere il CSRF con altri attacchi web che coinvolgono il browser, le richieste HTTP e le interazioni dell’utente ma hanno funzionamento e obiettivi diversi.

Un attacco spesso associato al CSRF, per esempio, è il cross-site scripting (XSS), che però funziona diversamente perché esegue codice JavaScript nel browser della vittima.

Un’altra tecnica simile al CSRF è il clickjacking o (UI Redressing), che inganna visivamente l’utente inserendo nella pagina livelli trasparenti o iframe per far sì che clicchi inavvertitamente su pulsanti invisibili.

Invece il cross-site request forgery – un attacco cieco che dipende da un’azione dell’utente – è molto distante dalle tecniche che sfruttano l’automazione per intercettare le password e rubare informazioni come gli attacchi di forza bruta (brute force). Nonostante questo, l’autenticazione a due fattori su WordPress e sulle altre piattaforme, può proteggere i siti da entrambi i tipi di attacco.

Come difendersi dagli attacchi CSRF

Per prevenire gli attacchi CSRF bisogna fare in modo che il server possa verificare che ogni richiesta dell’utente sia intenzionale. Ci sono varie tecniche, che funzionano meglio quando combinate:

• token anti-CSRF
• cookie con attributo SameSite
• controllo degli header HTTP
• OTP e CAPTCHA
• Web Application Firewall (WAF)
• protezioni integrate nei framework.

In generale queste soluzioni migliorano la sicurezza, ma possono rendere meno piacevole l’esperienza utente e aumentare il carico sul server.

Cookie con attributo SameSite

I cookie possono essere configurati con l’attributo SameSite, che fa sì che vengano allegati solo alle richieste provenienti dallo stesso sito a cui sono associati. In questo modo le richieste generate da siti esterni possono essere filtrate dal server.

È una protezione utile soprattutto se associata ai token anti-CSRF.

Token anti-CSRF

Il token anti-CSRF è uno dei metodi più efficaci per la protezione da questo tipo di attacco. Come funziona?

Quando il server genera una pagina che contiene un modulo che permette un’azione sensibile, incorpora nella pagina anche un codice univoco, il token. Quando l’utente invia la richiesta, il token viene incluso nei dati. Il server può così confrontare il codice ricevuto con quello che aveva generato e valutare se la richiesta è legittima. 

I token anti-CSRF vengono usati con 2 modalità principali.

• Nel synchronizer token pattern, il codice viene generato dal server e inserito nella pagina.
• Nel metodo cookie-to-header, il codice viene salvato in un cookie e poi copiato da JavaScript in un header della richiesta. 

Controllo degli header HTTP

Un’altra tecnica per la prevenzione degli attacchi CSRF è il controllo degli header Referer, che contiene l’URL completo di provenienza, e Origin, che specifica il dominio. Questo controllo permette al server di riconoscere e bloccare ogni operazione che non provenga dalle proprie pagine.

È semplice da implementare, ma da solo non è una difesa efficace poiché questi header possono essere omessi per motivi di privacy o risultare assenti a causa di specifiche configurazioni del browser, e in questi casi il server non ha gli elementi per decidere. A seconda della configurazione, bloccherà la richiesta per sicurezza oppure la accetterà comunque rischiando di esporre l’utente a un attacco CSRF.

Ecco perché viene considerato un filtro supplementare e non una soluzione definitiva contro questo tipo di attacco.

OTP e CAPTCHA

Un altro metodo consiste nel richiedere una conferma esplicita da parte dell’utente inserendo un doppio controllo come le one-time password (OTP) o i CAPTCHA. Questi sistemi sono molto sicuri ma non molto amati dalle persone che visitano i siti, perché richiedono azioni aggiuntive per raggiungere il risultato desiderato.

Protezioni integrate nei framework

Molti framework – come Django, Laravel o Spring – includono una protezione CSRF automatica, cioè generano e verificano i token senza che lo sviluppatore debba implementare tutto manualmente. Però è importante che siano configurati in modo corretto per evitare errori o disattivazioni che rendono l’applicazione vulnerabile.

Web Application Firewall (WAF)

Un Web Application Firewall (WAF) può aiutare a bloccare alcune richieste sospette prima che raggiungano il server e aggiungere un ulteriore livello di sicurezza.

Errori comuni nelle protezioni CSRF

Le difese contro il CSRF sono oggi molto diffuse, ma vanno implementate nel modo giusto. Oggi molte vulnerabilità CSRF nascono proprio dall’uso scorretto delle tecniche di prevenzione.

Uno degli errori consiste nel controllare i token anti-CSRF solo su alcuni tipi di richieste HTTP. Per esempio se la verifica riguarda solo le richieste POST ma l’operazione è disponibile anche tramite GET, un hacker può aggirare la protezione cambiando semplicemente metodo.

Alcune applicazioni controllano le richieste che contengono i token ma accettano tutte le richieste senza token. In questo caso per bypassare la verifica basta non inviarlo.

A volte le applicazioni non controllano che il token appartenga alla sessione dell’utente che sta facendo la richiesta, ma accettano qualsiasi codice presente in una lista di token validi. Di conseguenza un hacker può usare un codice ottenuto con il proprio account e inserirlo nella richiesta inviata inconsapevolmente dalla vittima.

In altri casi, per esempio se sono coinvolti più framework o librerie che accettano cookie diversi senza coordinarsi, il server può finire per non riuscire a verificare i token in modo accurato e accettare codici che non appartengono alla stessa sessione. 

Un’altra situazione pericolosa nasce quando il token viene salvato sia nella richiesta sia in un cookie, e il server si limita a controllare che i due valori coincidano, ma senza verificarne l’origine. Questo permette agli hacker di creare un valore e inserirlo sia nel cookie che nella richiesta.

Conseguenze di un attacco CSRF

Le conseguenze di un attacco CSRF dipendono da cosa è possibile fare sul sito preso di mira. Per esempio gli hacker possono:

• modificare le impostazioni dell’account come la password o l’indirizzo email associato;
• usare i privilegi di un admin per creare o eliminare utenti o modificare i dati di un sito;
• inviare messaggi e postare contenuti sui social;
• inviare moduli, compresi quelli per autorizzare pagamenti non voluti dall’utente. 

L’obiettivo di un attacco CSRF può essere sottrarre denaro o effettuare acquisti con il profilo della vittima, pubblicare contenuti non autorizzati a scopo di spam o propaganda, oppure prendere il controllo dell’account, per rivenderlo o usarlo in frodi successive.

In realtà impadronirsi di un account con un attacco cross-site request forgery è possibile solo su siti che permettono di modificare dati sensibili tramite una semplice richiesta senza richiedere ulteriori conferme all’utente – come l’inserimento della vecchia password o l’autenticazione a due fattori – e non prevedono token anti-CSRF o attributi SameSite restrittivi. Per fortuna ormai davvero rari.

Il CSRF diventa più pericoloso quando viene combinato con altri attacchi XSS, che permettono di sferrare un attacco CSRF dall’interno della pagina stessa rendendolo più difficile da individuare, sia per i sistemi di protezione che per l’utente.

Conclusioni 

In questa guida abbiamo visto che il cross-site request forgery è un attacco insidioso perché porta gli utenti autenticati, compresi gli amministratori, a compiere le azioni volute dagli hacker.

Proteggersi significa fare in modo che il server possa distinguere una richiesta intenzionale da una generata da una pagina esterna. I token anti-CSRF sono uno strumento efficace, ma vanno implementati nel modo giusto e integrati con altre misure, come i cookie SameSite e il controllo degli header. 

Per mettere il tuo sito al riparo dalla falsificazione delle richieste tra siti è importante anche prendere precauzioni contro gli attacchi XSS, che possono diventare uno strumento per aggirare le protezioni CSRF.

Se vuoi rendere il tuo sito ancora più sicuro, puoi leggere le nostre guide alla sicurezza WordPress e agli attacchi DDoS.

Tu hai già implementato dei sistemi di protezione per il cross-site request forgery? Se vuoi, raccontaci la tua esperienza nei commenti.