Il Cross-Site Request Forgery (CSRF) è un tipo di attacco informatico in cui un utente autenticato viene indotto a compiere azioni su un’applicazione web senza esserne consapevole.
Mentre l’utente interagisce con un’applicazione ritenuta affidabile, in realtà sta eseguendo richieste impostate dall’attaccante. Questo attacco sfrutta la sessione valida dell’utente nell’applicazione web “legittima” per inviare richieste HTTP malevole all’applicazione stessa, solitamente attraverso una pagina web o un form progettato ad hoc per ingannare l’utente.
L’impatto di questo tipo di attacco dipende fortemente dalla tipologia di applicativo e dai permessi che l’utente ha su quell’applicazione web.
Ad esempio, se un attaccante riesce a sfruttare questo attacco su un’applicazione bancaria che consente di effettuare transazioni, potrebbe eseguire azioni dannose, come trasferimenti di denaro non autorizzati.
D’altra parte, se l’attacco viene sfruttato attraverso un dipendente di un’azienda il quale possiede una sessione attiva su un’applicativo web, gli impatti potrebbero variare in base ai permessi dell’utente. Potrebbero per esempio includere danni all’applicativo, disservizi, perdita di dati e persino ottenere persistenza nel sistema (se i permessi dell’utente gli consentono di creare nuovi account o modificare la configurazione della piattaforma).
In sintesi, un attacco di questo tipo potrebbe portare a:
- Modifiche non autorizzate: Un attaccante potrebbe eseguire azioni come cambiare la password o l’email dell’utente. Oppure, come nell’esempio precedente, trasferire denaro in caso di applicativi bancari.
- Perdite di dati e disservizi: L’attaccante potrebbe eseguire richieste malevole come eliminazioni di dati.
- Compromissione dell’applicativo: se un amministratore è vittima di un attacco di questo tipo, l’intera applicazione potrebbe essere compromessa.
- In alcuni casi particolari, un attacco CSRF può essere utilizzato anche per esfiltrare dati o “spiare” l’utente. Questo è possibile grazie ad una specifica tipologia di attacco chiamata “login CSRF“, spiegata in modo più specifico nella sezione successiva.
Non esistono vere e proprie ‘tipologie’ di attacchi CSRF; piuttosto, si possono individuare alcune varianti che si differenziano principalmente in base ai metodi utilizzati per ingannare l’utente.
- Login CSRF: In questa specifica variante di attacco CSRF, l’attaccante forza l’utente a eseguire il login con un account controllato dall’attaccante stesso. Una volta che l’utente ha effettuato l’accesso, potrebbe essere indotto a inserire dati sensibili, come informazioni bancarie o personali. Successivamente, l’attaccante, essendo il vero proprietario dell’account, può accedere e visualizzare i dati inseriti dall’utente.
- CSRF basato su XSS: In un’applicazione vulnerabile a un attacco XSS, è possibile sfruttare la vulnerabilità per creare dei form che inviano richieste per conto di un altro utente. Questi form possono essere nascosti o inseriti in un iframe. Quando l’utente, autenticato, visita la pagina compromessa, la richiesta malevola viene inviata utilizzando i suoi permessi, probabilmente, senza accorgersene.
- CSRF con Metodo GET: In questo tipo di attacco, l’attaccante deve indurre un utente con una sessione valida nell’applicazione vulnerabile a cliccare su un link. Questo link contiene dei parametri in GET che eseguono un’azione specifica sull’applicativo stesso. Poiché l’utente è autenticato, la richiesta verrà elaborata con i suoi permessi, consentendo all’attaccante di sfruttare la sessione dell’utente per compiere l’azione.
- CSRF con Metodo POST: Questo tipo di attacco viene effettuato in modo simile a quello con metodo GET. L’attaccante crea una pagina HTML che contiene parametri nascosti (input) per eseguire l’azione malevola e un pulsante. Quando l’utente clicca su questo pulsante, il modulo invia una richiesta POST al server dell’applicazione vulnerabile, permettendo così di eseguire un’azione utilizzando i permessi dell’utente autenticato.
- Un esempio pratico di attacco Login CSRF potrebbe essere il seguente: l’attaccante invia un’email (fingendosi un operaio della web app o un messaggio automatico) all’utente con le credenziali di un account creato dall’attaccante per accedere a un’applicazione bancaria di transazioni. L’utente utilizza queste credenziali per accedere, senza modificare la password o l’email associata all’account. Successivamente, l’utente inserisce i propri dati personali e bancari richiesti dall’applicazione. A questo punto, l’attaccante può accedere all’account, di cui conosce le credenziali, e visualizzare i dati sensibili inseriti dall’utente.
- Un esempio che analizzeremo, come visualizzato nella GIF successiva, mostra una pagina HTML la quale potrebbe anche essere un’email di phishing, dove è presente un link “accedi”. Quando l’utente clicca su questo pulsante, viene effettuata una richiesta ad un link malevolo che esegue un’azione sull’applicativo con i suoi permessi, sfruttando la sessione autenticata già attiva nell’applicazione. Nel nostro esempio, l’azione eseguita è il cambio delle credenziali.
- Un altro esempio potrebbe essere quello di mandare all’utente un url con una pagina web simile al formato dell’app bancaria vulnerabile, nella gif successiva, l’utente ingenuamente clicca su “entra”. L’utente non si è accorto della presenza di input nascosti che efettuano una richiesta all’interno dell’applicazione in cui era già autenticato. Di conseguenza, l’azione di trasferimento di denaro è stata completata con successo, poiché l’applicazione vulnerabile a CSRF non riesce a distinguere che la richiesta proviene da un’altra pagina. Essa considera i cookie di sessione dell’utente come validi, fidandosi di essi ed eseguendo la richiesta.
- Un buon modo per difendersi da attacchi CSRF è quello di mitigare le possibili vulnerabilità XSS, poichè se uno dei campi dell’applicativo è vulnerabile, si rischia che l’attaccante utilizzi questa vulnerabilità per eseguire attacchi di tipo CSRF.
- Una tecnica fondamentale per proteggersi dagli attacchi CSRF è verificare le protezioni disponibili nel framework che si sta utilizzando. Ad esempio, Django implementa una protezione CSRF integrata che richiede l’inserimento del tag `{% csrf_token %}` all’interno del template HTML. Questo token viene generato per ogni sessione utente e deve essere incluso in ogni richiesta POST. Se il framework che stai utilizzando non possiede una protezione CSRF di base, si consiglia implementare una funzione di generazione di token CSRF e aggiungerlo in tutte le richieste che modificano lo stato, cioè che causano azioni nella web application.
- Se l’applicativo web esegue azioni paricolarmente sensibili, prendere in considerazione l’implementazione di una protezione basata sull’interazione dell’utente.
- Se possibile, non usare le richieste GET per eseguire azioni che cambiano gli stati.