Comprensione degli attacchi CSRF e blocco delle vulnerabilità CSRF

Le vulnerabilità Web sono dilaganti e in costante aumento. Mantenere la sicurezza e la privacy dei tuoi utenti è più importante che mai. Non affrontare le vulnerabilità del web può portare a una reputazione rovinata e multe salate da parte delle autorità di regolamentazione, e perderai anche la fiducia dei tuoi utenti.

I siti Web e le applicazioni Web sono vulnerabili a malware, spam e altri attacchi: questo articolo si concentra su uno di questi vettori di attacco: gli attacchi CSRF (Cross-Site Request Forgery). Gli attacchi CSRF sono particolarmente preoccupanti perché possono verificarsi all'insaputa dell'utente. Sono anche difficili da rilevare per uno sviluppatore o un proprietario di un sito Web perché le richieste dannose sembrano molto simili alle richieste autentiche.

Questo articolo esplora un attacco CSRF, come funziona e i passaggi che puoi intraprendere per prepararti a uno.

Cos'è un attacco CSRF?

Un attacco Cross-Site Request Forgery, noto anche come attacco CSRF, induce un utente autenticato a eseguire azioni indesiderate inviando richieste dannose senza che se ne renda conto.

In genere, un attacco CSRF comporta richieste di modifica dello stato perché l'attaccante non riceve una risposta. Esempi di tali richieste includono l'eliminazione di un record, la modifica di una password, l'acquisto di un prodotto o l'invio di un messaggio. Questi possono verificarsi tutti all'insaputa dell'utente.

L'attaccante malintenzionato in genere utilizza l'ingegneria sociale per inviare a un utente ignaro un collegamento tramite chat o e-mail.

Quando l'utente fa clic sul collegamento, esegue i comandi impostati dall'attaccante.

Ad esempio, facendo clic su un collegamento è possibile trasferire fondi dall'account di un utente. In alternativa, può modificare l'indirizzo e-mail di un utente impedendogli di riottenere l'accesso all'account.

Come funziona un attacco CSRF?

Convincere l'utente ad avviare una richiesta di modifica dello stato mentre è connesso è il primo e più cruciale passaggio in un attacco CSRF. Con gli attacchi CSRF, l'attaccante mira a convincere un utente autenticato a inviare inconsapevolmente una richiesta Web dannosa a un sito Web o un'applicazione Web. Queste richieste possono essere costituite da cookie, parametri URL e altri tipi di dati che appaiono normali all'utente.

Affinché un attacco CSRF abbia successo, devono verificarsi le seguenti condizioni:

• Un utente autenticato deve essere connesso a un'applicazione Web che utilizza i cookie per la gestione delle sessioni.
• Un utente malintenzionato deve creare una richiesta contraffatta che modifica lo stato.
• Le richieste autentiche gestite dal server di destinazione non devono contenere parametri imprevedibili. Ad esempio, la richiesta non dovrebbe prevedere una password come parametro a scopo di verifica prima di avviare la richiesta di modifica dello stato.

Il metodo più comune per completare gli attacchi CSRF consiste nell'utilizzare i cookie nelle applicazioni con una policy sui cookie SameSite debole. I browser Web includono i cookie automaticamente e spesso in modo anonimo e salvano i cookie utilizzati da un dominio in qualsiasi richiesta Web che un utente invia a quel dominio.

La politica sui cookie SameSite definisce il modo in cui il browser nei contesti di navigazione tra siti tratta il cookie. Se impostato su strict, il cookie non viene condiviso nei contesti di navigazione tra siti, impedendo gli attacchi CSRF. Il browser allega il cookie in tutti i contesti tra siti se è impostato su nessuno. Ciò rende l'applicazione vulnerabile agli attacchi CSRF.

Quando un utente invia inconsapevolmente una richiesta dannosa tramite un browser Web, i cookie salvati fanno sì che la richiesta appaia legittima al server. Il server quindi risponde alla richiesta modificando l'account dell'utente, modificando lo stato della sessione o restituendo i dati richiesti.

Diamo un'occhiata più da vicino a due esempi di vie di attacco CSRF, una con una richiesta GET e l'altra con una richiesta POST.

CSRF per una richiesta GET

Innanzitutto, considera una richiesta GET utilizzata da un'applicazione web di banca finanziaria, 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 assomigli a questa:

 GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1

Nella richiesta genuina di cui sopra, l'utente richiede di trasferire $ 1.000 su un conto con 547895 come pagamento per i prodotti acquistati.

Sebbene questa richiesta sia esplicita, semplice e pratica, espone il titolare dell'account a un attacco CSRF. Questo perché la richiesta non richiede dettagli che un utente malintenzionato potrebbe non conoscere. Quindi, per avviare un attacco, un utente malintenzionato dovrebbe solo modificare i parametri di questa richiesta (l'importo e il numero di conto) per creare una richiesta contraffatta eseguibile.

La richiesta dannosa sarebbe efficace su qualsiasi utente della banca fintanto che hanno sessioni in corso gestite dai cookie.

Ecco come apparirebbe la richiesta falsificata di trasferire $ 500 sull'account di un hacker (qui, numero 654585 ). Si noti che l'esempio seguente è una versione altamente semplificata dei passaggi coinvolti in un attacco CSRF per una spiegazione.

 GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1

Una volta completato, l'attaccante deve trovare un modo per indurre l'utente a inviare questa richiesta mentre è connesso alla propria applicazione di online banking. Uno dei modi per farlo è creare un collegamento ipertestuale innocuo che attiri l'attenzione dell'utente. Il collegamento potrebbe essere simile a questo:

 <a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.

Dato che l'attaccante ha trovato gli indirizzi e-mail corretti dei propri obiettivi, può inviarlo tramite e-mail a molti clienti bancari. Coloro che fanno clic sul collegamento durante l'accesso attivano la richiesta di inviare all'attaccante $ 500 dall'account registrato.

CSRF per una richiesta POST

Vediamo come lo stesso istituto finanziario sperimenterebbe un CSRF se accettasse solo richieste POST. In questo caso, la consegna del collegamento ipertestuale utilizzata nell'esempio di richiesta GET non funzionerebbe. Pertanto, un attacco CSRF riuscito richiederebbe a un utente malintenzionato di creare un modulo HTML. La vera richiesta di inviare $ 1.000 per un prodotto acquistato sarebbe simile a questa:

 POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895

Questa richiesta POST richiede un cookie per determinare l'identità dell'utente, l'importo che desidera inviare e l'account che desidera inviare. Gli aggressori possono modificare questa richiesta per eseguire un attacco CSRF.

L'attaccante deve solo aggiungere un cookie autentico a una richiesta contraffatta per fare in modo che il server elabori il trasferimento. Possono farlo creando un collegamento ipertestuale dall'aspetto innocuo che porta l'utente a una pagina Web di attivazione simile 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 l'importo e i parametri del conto nel modulo sopra. 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 quindi inoltra $ 500 all'account dell'hacker.

3 modi per ridurre gli attacchi CSRF

Esistono diversi metodi per prevenire e mitigare drasticamente i potenziali attacchi CSRF sul tuo sito Web o applicazione Web, tra cui:

• Utilizzo di token CSRF
• Utilizzando l'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 CSRF assegna a ciascuna sessione un token univoco e lo condivide con il lato server e il browser client. Ogni volta che un browser invia una richiesta sensibile, il server si aspetta che contenga il token CSRF assegnato. Se ha il token sbagliato, il server lo elimina. Il token CSRF non viene archiviato nei cookie di sessione nel 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:

• Ignora convalida: alcune applicazioni ignorano il passaggio di verifica se non trovano un token. Se un utente malintenzionato ottiene l'accesso al codice che contiene un token, può rimuovere quel token ed eseguire con successo un attacco CSRF. Quindi, se una richiesta valida a un server è simile a questa:

 POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433

Un utente malintenzionato 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 utente invece di designare un token specifico per una sessione. Un utente malintenzionato deve solo ottenere uno dei token già presenti nel pool per impersonare uno qualsiasi degli utenti 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=93j9d8eckke20d433

E poiché i token sono raggruppati, l'attaccante può copiare e utilizzare lo stesso token per accedere a un account utente diverso, poiché lo utilizzerai di nuovo:

• I CSRF possono essere token copiati nel cookie : alcune applicazioni copieranno i parametri relativi a un token nel cookie di un utente. Se un utente malintenzionato ottiene l'accesso a tale cookie, può facilmente creare un altro cookie, inserirlo in un 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:93j9d8eckke20d433

Possono quindi utilizzare queste informazioni per creare un altro cookie per completare l'attacco

• Token non validi : alcune applicazioni non associano i token CSRF a una sessione utente. In tali casi, un utente malintenzionato può effettivamente accedere a una sessione, ottenere un token CSRF simile a quelli precedenti e utilizzarlo per orchestrare un attacco CSRF sulla sessione di una vittima.

Come prevenire gli attacchi CSRF con l'intestazione del referrer

Un'altra strategia per prevenire gli attacchi CSRF consiste nell'utilizzare l'intestazione del referrer. In HTTP, le intestazioni dei referrer indicano l'origine delle richieste. In genere vengono usati per eseguire analisi, ottimizzazione e registrazione.

Puoi anche abilitare il controllo delle intestazioni dei referrer sul lato server per prevenire attacchi CSRF. Il lato server controlla l'origine di 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'utilizzo delle intestazioni dei referrer è molto più semplice rispetto all'utilizzo dei token perché non richiede l'identificazione dell'utente individuale.

Potenziali vulnerabilità dell'intestazione del referrer

Come i token CSRF, le intestazioni dei referrer presentano alcune vulnerabilità significative.

Innanzitutto, le intestazioni dei referrer non sono obbligatorie e alcuni siti invieranno richieste senza di esse. Se il CSRF non dispone della policy per gestire le richieste senza intestazioni, gli aggressori possono utilizzare le richieste senza intestazione per eseguire attacchi che cambiano lo stato.

Inoltre, questo metodo è diventato meno efficace con la recente introduzione della politica di riferimento. Questa specifica impedisce la perdita di URL ad altri domini, offrendo agli utenti un maggiore controllo sulle informazioni nell'intestazione del referrer. Possono scegliere di esporre parte delle informazioni dell'intestazione del referrer o di disabilitarle aggiungendo un tag di metadati sulla pagina HTML, come mostrato di seguito:

 <meta name="referrer" content="no-referrer">

Il codice precedente rimuove l'intestazione del referrer per tutte le richieste da questa pagina. Ciò rende difficile per le applicazioni che si basano sulle intestazioni dei referrer impedire attacchi CSRF da tale pagina.

In che modo Kinsta protegge dagli attacchi CSRF

Oltre a utilizzare l'intestazione del referrer e i token CSRF, esiste una terza opzione molto più semplice: scegliere un servizio di hosting sicuro come Kinsta per i vostri siti Web e applicazioni Web fornisce una barriera molto più forte e sicura tra gli aggressori e i vostri utenti.

Oltre alle funzionalità di sicurezza critiche come i backup automatici, l'autenticazione a due fattori e i protocolli SFTP su SSH, l'integrazione Cloudflare di Kinsta fornisce protezione a livello aziendale con protezione firewall e basata su IP.

Nello specifico, Kinsta ha attualmente circa 60 regole firewall personalizzate per aiutare a prevenire attacchi dannosi e affrontare gravi vulnerabilità non autenticate in plugin e temi, compresi quelli specifici che cercano vulnerabilità CSRF.

Riepilogo

Cross-site request forgery (CSRF) è un attacco che induce gli utenti autenticati ad avviare involontariamente richieste di modifica dello stato. Prendono di mira le applicazioni che non sono in grado di distinguere tra richieste di modifica dello stato valide e contraffatte.

CSRF può avere successo solo su applicazioni che si basano sui cookie di sessione per identificare gli utenti registrati e hanno una policy sui cookie SameSite debole. Hanno anche bisogno di un server che accetti richieste che non contengono parametri sconosciuti come le password. Gli hacker possono inviare attacchi dannosi utilizzando GET o POST.

Sebbene l'utilizzo di token CSRF o l'applicazione della verifica dell'intestazione del referrer possa prevenire alcuni attacchi CSRF, entrambe le misure presentano potenziali vulnerabilità che possono rendere inutili le misure preventive se non si presta attenzione.

La migrazione a una piattaforma di hosting sicura come Kinsta protegge i vostri siti web o le vostre app web dagli attacchi CSRF. Inoltre, l'integrazione di Kinsta con Cloudflare previene specifici attacchi CSRF.