Le vulnerabilità sul web sono dilaganti e in costante aumento. Mantenere la sicurezza e la privacy dei vostri utenti è diventato più importante che mai. Trascurare le vulnerabilità può rovinare la reputazione e portare a multe salate da parte delle autorità di controllo, oltre a farvi perdere la fiducia dei vostri utenti.
I siti e le applicazioni web sono vulnerabili a malware, spam e altri pericoli. Questo articolo si concentra su uno di questi vettori di attacco: gli attacchi CSRF (Cross-Site Request Forgery). Questi attacchi sono particolarmente pericolosi perché possono verificarsi all’insaputa dell’utente. Inoltre, sono difficili da individuare per uno sviluppatore o per il proprietario di un sito web, perché le richieste dannose sono molto simili a quelle autentiche.
Questo articolo analizza un attacco CSRF, come avviene e le misure da adottare per prepararsi ad affrontarlo.
Guarda la nostra video-guida per scoprire tutto sugli attacchi CSRF
Cos’è un Attacco CSRF?
Un attacco Cross-Site Request Forgery, noto anche come attacco CSRF, inganna un utente autenticato e lo costringe a eseguire azioni non volute inviando richieste dannose senza che se ne renda conto.
In genere, un attacco CSRF comporta richieste che cambiano stato perché chi attacca non riceve risposta. Esempi di richieste di questo tipo sono la cancellazione di un record, la modifica di una password, l’acquisto di un prodotto o l’invio di un messaggio. Tutte queste operazioni possono avvenire all’insaputa dell’utente.
L’aggressore malintenzionato di solito utilizza tecniche di social engineering per inviare a un utente ignaro un link tramite chat o e-mail.
Quando l’utente clicca sul link, esegue i comandi impostati dall’aggressore.
Ad esempio, cliccando su un link si possono trasferire fondi dal conto dell’utente. Oppure, si può cambiare l’indirizzo e-mail di un utente impedendogli di riottenere l’accesso all’account.
Come Funziona un Attacco CSRF?
Far sì che l’utente avvii una richiesta di cambio di stato mentre è connesso è il primo e più importante passo di un attacco CSRF. Con gli attacchi CSRF, l’aggressore mira a far sì che un utente autenticato invii inconsapevolmente una richiesta web dannosa a un sito o a un’applicazione web. Queste richieste possono essere costituite da cookie, parametri URL e altri tipi di dati che all’utente appaiono normali.
Affinché un attacco CSRF abbia successo, devono verificarsi le seguenti condizioni:
- Un utente autenticato deve accedere a un’applicazione web che utilizza i cookie per la gestione della sessione.
- Chi attacca deve creare una richiesta contraffatta che cambia stato.
- Le richieste autentiche gestite dal server di destinazione non devono contenere parametri imprevedibili. Ad esempio, la richiesta non deve prevedere una password come parametro di verifica prima di avviare la richiesta di cambio di stato.
Il metodo più comune per portare a termine gli attacchi CSRF è l’utilizzo dei cookie nelle applicazioni con una policy debole sui cookie SameSite. I browser web includono i cookie automaticamente e spesso in modo anonimo e salvano i cookie utilizzati da un dominio in ogni richiesta web che l’utente invia a quel dominio.
La policy sui cookie SameSite definisce il trattamento del cookie da parte del browser in contesti di navigazione cross-site. Se è impostata su strict, il cookie non viene condiviso in contesti di navigazione cross-site, prevenendo gli attacchi CSRF. Se è impostata su none, il browser attribuisce il cookie in tutti i contesti cross-site. Questo rende l’applicazione vulnerabile agli attacchi CSRF.
Quando un utente invia inconsapevolmente una richiesta dannosa attraverso un browser web, i cookie salvati fanno sì che la richiesta appaia legittima al server. Il server risponde alla richiesta cambiando l’account dell’utente, modificando lo stato della sessione o restituendo i dati richiesti.
Vediamo due esempi di attacchi CSRF, uno con una richiesta GET e l’altro con una richiesta POST.
CSRF per una Richiesta GET
In primo luogo, consideriamo una richiesta GET utilizzata da un’applicazione web di banking finanziario, in cui l’attacco sfrutta una richiesta GET e la consegna di un collegamento ipertestuale.
Supponiamo che la richiesta GET per il trasferimento di denaro sia simile a questa:
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1Nella richiesta autentica qui sopra, l’utente chiede di trasferire 1.000 dollari a un conto di 547895 come pagamento per i prodotti acquistati.
Sebbene questa richiesta sia esplicita, semplice e pratica, espone il titolare del conto a un attacco CSRF. Questo perché la richiesta non richiede dettagli che un malintenzionato potrebbe non conoscere. Quindi, per sferrare un attacco, un malintenzionato dovrebbe solo alterare i parametri di questa richiesta (l’importo e il numero di conto) per creare una richiesta falsificata eseguibile.
La richiesta dannosa sarebbe efficace per tutti gli utenti della banca, purché abbiano sessioni gestite da cookie in corso.
Ecco come apparirebbe la richiesta contraffatta di trasferire 500 dollari sul conto di un hacker (qui il numero 654585). Si noti che l’esempio che segue è una versione molto semplificata dei passaggi necessari per un attacco CSRF.
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1Una volta completata l’operazione, l’aggressore deve trovare un modo per ingannare l’utente e indurlo a inviare la richiesta mentre è connesso alla sua applicazione bancaria online. Uno dei modi per farlo è creare un collegamento ipertestuale innocuo che attiri l’attenzione dell’utente. Il link potrebbe avere il seguente aspetto:
<a
href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.Dato che l’aggressore ha trovato gli indirizzi e-mail corretti dei suoi obiettivi, può inviare questo link via e-mail a molti clienti della banca. Coloro che cliccheranno sul link mentre sono connessi attiveranno la richiesta di inviare all’aggressore 500 dollari dal conto registrato.
CSRF per una Richiesta POST
Vediamo come lo stesso istituto finanziario subirebbe un CSRF se accettasse solo richieste POST. In questo caso, il collegamento ipertestuale utilizzato nell’esempio della richiesta GET non funzionerebbe. Pertanto, un attacco CSRF riuscito richiederebbe all’aggressore di creare un modulo HTML. La richiesta autentica di inviare 1.000 dollari per un prodotto acquistato avrebbe il seguente aspetto:
POST /online/transfer HTTP/1.1
Host: xymbank.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg
amount=1000
account=547895Questa richiesta POST richiede un cookie per determinare l’identità dell’utente, l’importo che desidera inviare e il conto che desidera inviare. Gli aggressori possono alterare questa richiesta per eseguire un attacco CSRF.
Chi attacca deve solo aggiungere un cookie autentico a una richiesta contraffatta per far sì che il server elabori il trasferimento. Può farlo creando un collegamento ipertestuale dall’aspetto innocuo che porti l’utente a una pagina web innescata che assomiglia a questa:
<html>
<body>
<form action="https://xymbank.com/online/transfer" method="POST">
<input type="hidden" name="amount" value="500"/>
<input type="hidden" name="account" value="654585" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>Abbiamo già impostato i parametri dell’importo e del conto nel modulo precedente. Una volta che un utente autenticato visita la pagina, il browser aggiunge il cookie di sessione prima di inoltrare la richiesta al server. Il server inoltra quindi 500 dollari all’account dell’hacker.
3 Modi per Ridurre gli Attacchi CSRF
Esistono diversi metodi per prevenire e ridurre drasticamente i potenziali attacchi CSRF sul vostro sito o sulla vostra applicazione web, tra cui:
- Utilizzo di token CSRF
- Utilizzo dell’intestazione del referrer
- Scegliere una soluzione di hosting incentrata sulla sicurezza, come Kinsta
Come Prevenire gli Attacchi CSRF Utilizzando i Token CSRF
Un sito web sicuro dal punto di vista CSRF assegna a ogni sessione un token unico e lo condivide con il server e il browser del client. Ogni volta che un browser invia una richiesta sensibile, il server si aspetta che contenga il token CSRF assegnato. Se la richiesta contiene il token sbagliato, il server la rifiuta. Il token CSRF non viene memorizzato nei cookie di sessione del browser del client per motivi di sicurezza.
Potenziali Vulnerabilità dei Token CSRF
Sebbene i token CSRF siano un’eccellente misura di sicurezza, questo metodo non è a prova di attacco. Alcune delle vulnerabilità che accompagnano i token CSRF includono:
- Bypass della validazione – Alcune applicazioni saltano la fase di verifica se non trovano un token. Se un utente malintenzionato riesce ad accedere al codice che contiene un token, può rimuoverlo ed eseguire con successo un attacco CSRF. Quindi, se una richiesta valida a un server si presenta come questa:
POST /change_password
POST body:
password=pass123&csrf_token=93j9d8eckke20d433Un aggressore deve solo rimuovere il token e inviarlo in questo modo per eseguire l’attacco:
POST /change_password
POST body:
password=pass123- Token in pool – Alcune applicazioni mantengono un pool di token per convalidare le sessioni degli utenti invece di assegnare un token specifico a una sessione. Un aggressore deve solo ottenere uno dei token già presenti nel pool per impersonare qualsiasi utente del sito.
Un utente malintenzionato può accedere a un’applicazione utilizzando il proprio account per ottenere un token, ad esempio:
[application_url].com?csrf_token=93j9d8eckke20d433Inoltre, poiché i token sono raggruppati, l’aggressore può copiare e utilizzare lo stesso token per accedere a un account di un altro utente, che lo utilizzerà di nuovo:
- I CSRF possono essere il token copiato nel cookie – Alcune applicazioni copiano i parametri relativi a un token nel cookie di un utente. Se un utente malintenzionato riesce ad accedere a tale cookie, può facilmente crearne un altro, inserirlo nel browser ed eseguire un attacco CSRF.
Quindi un utente malintenzionato può accedere a un’applicazione utilizzando il proprio account e aprire il file cookie per vedere quanto segue:
Csrf_token:93j9d8eckke20d433Può quindi utilizzare queste informazioni per creare un altro cookie e completare l’attacco
- Token non validi – Alcune applicazioni non abbinano i token CSRF alla sessione dell’utente. In questi casi, un aggressore può accedere realmente a una sessione, ottenere un token CSRF simile a quelli sopra citati e usarlo per orchestrare un attacco CSRF alla sessione della vittima.
Come Prevenire gli Attacchi CSRF con l’Intestazione Referrer
Un’altra strategia per prevenire gli attacchi CSRF è l’utilizzo dell’intestazione referrer. Nell’HTTP, le intestazioni referrer indicano l’origine delle richieste. In genere vengono utilizzate per eseguire analisi, ottimizzazioni e registrazioni.
È anche possibile attivare il controllo delle intestazioni referrer sul lato server per prevenire gli attacchi CSRF. Il lato server controlla l’origine della richiesta e determina l’origine di destinazione della richiesta. Se corrispondono, la richiesta è consentita. Se c’è una mancata corrispondenza, il server elimina la richiesta.
L’uso delle intestazioni del referrer è molto più semplice dell’uso dei token perché non richiede l’identificazione di un singolo utente.
Potenziali Vulnerabilità dell’Intestazione Referrer
Come i token CSRF, anche le intestazioni referrer presentano alcune vulnerabilità significative.
Innanzitutto, le intestazioni del referrer non sono obbligatorie e alcuni siti inviano richieste senza di esse. Se il CSRF non dispone di una policy per gestire le richieste senza intestazioni, gli aggressori possono utilizzare le richieste senza intestazione per eseguire attacchi con cambio di stato.
Inoltre, questo metodo è diventato meno efficace con la recente introduzione del criterio del referrer. Questa specifica impedisce la fuga di URL verso altri domini, dando agli utenti un maggiore controllo sulle informazioni contenute nell’intestazione del referrer. Possono scegliere di esporre parte delle informazioni dell’intestazione del referrer o di disabilitarle aggiungendo un tag di metadati alla pagina HTML, come mostrato di seguito:
<meta name="referrer" content="no-referrer">Il codice sopra riportato rimuove l’intestazione del referrer per tutte le richieste provenienti da questa pagina. In questo modo è difficile per le applicazioni che si basano sulle intestazioni del referrer prevenire gli attacchi CSRF da questa pagina.
Come Kinsta Protegge dagli Attacchi CSRF
Oltre all’utilizzo dell’intestazione referrer e dei token CSRF, c’è una terza opzione molto più semplice: scegliere un servizio di hosting sicuro come Kinsta per i vostri siti e applicazioni web fornisce una barriera molto più forte e sicura tra gli aggressori e i vostri utenti.
Oltre a funzioni di sicurezza fondamentali come i backup automatici, l’autenticazione a due fattori e i protocolli SFTP e SSH, l’integrazione di Kinsta con Cloudflare offre una protezione di livello enterprise con protezione basata su IP e firewall.
In particolare, Kinsta dispone attualmente di circa 60 regole firewall personalizzate che aiutano a prevenire gli attacchi dannosi e a gestire le gravi vulnerabilità non autenticate nei plugin e nei temi, comprese quelle specifiche che cercano le vulnerabilità CSRF.
Riepilogo
Il Cross-Site Request Forgery (CSRF) è un attacco che inganna gli utenti autenticati e li induce a iniziare involontariamente richieste che cambiano stato. Le applicazioni prese di mira sono quelle che non sono in grado di distinguere tra le richieste di cambio di stato valide e quelle falsificate.
Il CSRF può avere successo solo nelle applicazioni che si affidano ai cookie di sessione per identificare gli utenti registrati e che hanno una policy debole sui cookie SameSite. Inoltre, è necessario un server che accetti richieste che non contengano parametri sconosciuti come le password. Gli hacker possono inviare attacchi dannosi utilizzando sia GET che POST.
Sebbene l’utilizzo di token CSRF o la verifica dell’intestazione del referrer possano prevenire alcuni attacchi CSRF, entrambe le misure presentano potenziali vulnerabilità che possono rendere inutili le misure preventive se non si sta attenti.
La migrazione a una piattaforma di hosting sicura come Kinsta mette al sicuro i vostri siti o le vostre applicazioni web dagli attacchi CSRF. Inoltre, l’integrazione di Kinsta con Cloudflare previene specifici attacchi CSRF.
Salman Ravoof é uno sviluppatore web autodidatta, uno scrittore, un creatore e un grande ammiratore del Free and Open Source Software (FOSS). Oltre alla tecnologia, è appassionato di scienza, filosofia, fotografia, arte, gatti e cibo. Per saperne di più su di lui, visitate il suo sito web o contattate Salman su X.
Lascia un commento