Cos'è una richiesta di falsificazione di richieste tra siti (Cross-Site Request Forgery, CSRF)?

Che cos'è un cross-site request forgery (CSRF)?

Un attacco Cross-site request forgery (CSRF) è un tipo di attacco informatico di tipo "confused deputy"* che induce un utente a utilizzare accidentalmente le proprie credenziali per eseguire azioni di modifica di stato, come trasferire fondi dal proprio conto, modificare un indirizzo e-mail e una password, o intraprendere altre azioni indesiderate.

Sebbene l'impatto potenziale su un normale utente sia già notevole, un attacco CSRF andato a buon fine contro un account amministrativo può compromettere un intero server, portando potenzialmente alla completa acquisizione di un'applicazione web, un'API o un altro servizio.

Come funziona un attacco cross-site request forgery?

Questo attacco prende di mira le richieste di modifica di stato, ovvero un tipo di richiesta che comporta la modifica di dati da un valore a un altro. Ad esempio, una richiesta mirata potrebbe effettuare un acquisto o modificare un valore in un account. È interessante notare che si tratta di un “attacco cieco” e non restituisce dati all'aggressore, cosa che lo rende inadatto al furto di dati.

Ecco un esempio dei 4 passaggi di un attacco CSRF:

1. Un utente malintenzionato crea una richiesta contraffatta che, una volta eseguita, trasferirà 10.000 $ da una determinata banca al conto dell'aggressore.
2. L'aggressore inserisce la richiesta contraffatta in un collegamento ipertestuale e la invia tramite una e-mail massiva, e la incorpora anche in dei siti web.
3. Una vittima fa clic su un'e-mail o su un collegamento a un sito web inseriti dall'aggressore, con la conseguenza che la vittima effettua una richiesta alla banca di trasferire 10.000 $.
4. Il server della banca riceve la richiesta e, poiché la vittima è autorizzata, considera la richiesta legittima e trasferisce i fondi.

Gli attacchi CSRF variano nella metodologia, ma in genere presentano le seguenti caratteristiche:

1. Sfruttano siti web che si basano sull'identità di un utente
2. Ingannano il browser dell'utente facendogli inviare richieste HTTP al sito di destinazione
3. Implicano l'utilizzo di richieste HTTP che hanno effetti collaterali e non dispongono di protezioni CSRF adeguate

Verbi HTTP diversi presentano diversi livelli di vulnerabilità agli attacchi CSRF, il che comporta differenti strategie di protezione. Ciò è dovuto al modo in cui i browser gestiscono diversamente tali verbi.

Le richieste HTTP GET contengono parametri incorporati, come quelli all'interno dei tag immagine, che possono essere manipolati e sfruttati. In genere, le richieste GET non modificano lo stato, il che le rende inefficaci come obiettivi di attacchi CSRF per applicazioni web o altre risorse implementate correttamente.

Il metodo HTTP POST viene utilizzato per modificare lo stato, il che comporta una maggiore necessità di protezione. A tal fine, i browser implementano misure di sicurezza denominate Same-Origin Policy (SOP) e Cross-Origin Resource Sharing (CORS), che includono la politica di sicurezza cross-origin. SOP consente solo le richieste dalla stessa origine e CORS consente solo determinati tipi di richieste da un'origine diversa. La combinazione di queste implementazioni aiuta a prevenire gli attacchi CSRF (tra gli altri) limitando la capacità di una richiesta o pagina web di interagire con un'origine diversa.

Altri verbi HTTP, come PUT e DELETE, possono essere eseguiti solo tramite SOP e CORS, mitigando molti attacchi cross-site.

Sebbene sia raro, alcuni siti web disabilitano esplicitamente queste misure di sicurezza, ed è possibile disabilitarle anche all'interno di un browser.

Come è possibile mitigare gli attacchi CSRF?

La metodologia più comune per mitigare gli attacchi CSRF prevede l'utilizzo di token anti-CSRF, e prevede l'adozione di uno dei seguenti due metodi. Sebbene le implementazioni dei token siano leggermente diverse, il principio di base rimane lo stesso: creando e confrontando una stringa di token generata casualmente, è assai improbabile che un aggressore riesca a sferrare un attacco, perché dovrebbe magicamente indovinare il token generato.

Synchronizer token pattern:

Quando un utente visita una pagina web, come ad esempio la pagina di una banca che consente il trasferimento di fondi, il sito incorpora un token casuale nel modulo. Quando l'utente invia il modulo, il token casuale viene restituito e la banca può verificare se i due token corrispondono. Se la corrispondenza è positiva, al trasferimento viene dato corso. L'aggressore non ha modo di accedere al valore del token casuale creato nella pagina, e se anche la richiedesse, la stessa policy d'origine gli impedirebbe di leggere la risposta.

Lo svantaggio di questo metodo di mitigazione è che aumenta il carico sul lato server per la verifica della validità dei token ad ogni richiesta. Può anche creare problemi se un utente ha più finestre del browser aperte o altre situazioni in cui a effettuare la richiesta sono svariati software. Espandendo l'ambito del token in modo che sia per sessione anziché per richiesta, è possibile evitare in parte questa difficoltà.

Token cookie-to-header:

Un altro metodo consiste nell'emissione di un cookie al browser web del visitatore, contenente un token casuale. Lo JavaScript lato client leggerà il valore del token nel cookie e lo copierà in un'intestazione HTTP che verrà inviata con ogni richiesta. Se una richiesta autentica viene inviata dall'utente, il server può verificare il valore nell'intestazione. Qualsiasi altra istanza fallirà, mitigando un attacco andato a buon fine.

Utilizzando regole personalizzate tramite un WAF, gli utenti possono contribuire a prevenire determinati attacchi CSRF. Esplora il WAF di Cloudflare.

*Il problema del confused deputy

Per "confused deputy" si intende un programma per computer che viene indotto con l'inganno a utilizzare impropriamente la propria autorità. Questo rischio, associato a questo tipo di vulnerabilità, è il motivo per cui un modello di sicurezza basato sulle capacità contribuisce a ridurre i rischi associati all'uso improprio. Quando si installa un software, ad esempio, la maggior parte dei computer oggi richiede all'utente di effettuare l'accesso. Questo aiuta a prevenire l'esecuzione involontaria di codice quando l'utente utilizza accidentalmente i propri privilegi per autorizzare un'installazione.

DOMANDE FREQUENTI

Cos'è un cross-site request forgery (CSRF)?

CSRF è un attacco informatico che induce con l'inganno un utente a utilizzare le proprie credenziali per eseguire azioni indesiderate su un'applicazione web in cui è autenticato.

Qual è il problema del "confused deputy"?

Il problema del "confused deputy" è una vulnerabilità di sicurezza in cui un programma con meno privilegi ne manipola uno con più privilegi inducendolo a utilizzare impropriamente la sua autorità.

Cosa sono i token anti-CSRF?

I token anti-CSRF sono un modo per mitigare gli attacchi di Cross-Site Request Forgery (CSRF). Sono token contenenti valori randomizzati, aggiunti alle richieste web per verificarne la legittimità. È altamente improbabile che eventuali aggressori siano in grado di indovinare i valori casuali e falsificare richieste valide.

Che cos'è la same-origin policy (SOP)?

La same-origin policy è un meccanismo di sicurezza di un browser che limita le interazioni tra pagine web alla stessa origine, contribuendo a prevenire attacchi cross-site come CSRF.

In che modo i verbi HTTP influenzano la vulnerabilità ai CSRF?

Verbi HTTP diversi (GET, POST, PUT, DELETE) hanno vulnerabilità diverse rispetto a CSRF. Le richieste POST, poiché sono utilizzate per modificare lo stato, sono quelle più comunemente prese di mira e richiedono una protezione più efficace.