Attacco Cross Site Request Forgery (CSRF)
Tempo di lettura: 8 minutiData pubblicazione: April 13, 2020
Spulciando il blog mi sono accorto di non aver mai parlato di questa tipologia di attacco, che, sebbene non sembri nulla di chè, potrebbe risultare in una completa compromissione di un sito web o di un account presente su un applicativo Web. In questo articolo andremo ad analizzarlo, cercando di capirne il funzionamento, i possibili attacchi e le eventuali remediation da mettere in campo per difendersi.
Descrizione
Secondo Wikipedia, il CSRF “è una vulnerabilità a cui sono esposti i siti web dinamici quando sono progettati per ricevere richieste da un client senza meccanismi per controllare se la richiesta sia stata inviata intenzionalmente oppure no”.
Un attaccante quindi, tramite un attacco di Social Engineering, potrebbe ingannare gli utenti di un’applicazione web ad eseguire azioni in maniera inconsapevole. Se la vittima è un utente normale, un attacco CSRF riuscito può costringere l’utente ad eseguire richieste di cambiamento di stato come il trasferimento di fondi, il cambio di indirizzo e-mail e potrebbe portare ad una compromissione dell’account, MA se è un amministratore, le conseguenze potrebbero essere ben peggiori, come la cancellazione del database o l’eliminazione completa del sito.
Vediamo un esempio con una normale richiesta GET (preso da OWASP).
L’applicativo di una banca permette il trasferimento di fondi dal proprio conto a quello di un altro tramite questa URL:
GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1
Dove BOB è il destinatario e amount è la cifra da trasferire dal proprio account a BOB. Un’attaccante, per poter eseguire l’attacco, potrebbe semplicemente modificare BOB con il proprio account, ed inserire il quantitativo di soldi voluto, in questo modo
GET http://bank.com/transfer.do?acct=HACKER&amount=10000 HTTP/1.1
Per far si che l’attacco funzioni, deve solo inviare il link alla vittima, magari tramite una mail di phishing o cammuffandola sfruttando un’altra vulnerabilità del sito, magari un XSS Stored o un open redirect. Se la vittima è già loggata all’applicativo e clicca il link, sarà del tutto inconsapevole di ciò che è appena successo, e l’attaccante sarà riuscito ad ottenere il trasferimento di fondi.
Questo attacco quindi è sfruttabile solo per cambiamenti di stato, che portano la vittima a modificare uno stato del proprio account o applicativo.
Esempio reale
Poco tempo fa ho scoperto una bellissima sfida composta da più livelli con diverse vulnerabilità (XSS, RCE, SQLi, etc.) dove possiamo capire al meglio l’attacco CSRF in quanto è presente un motore che simula la presenza di utenti veri, che cliccano i link mandati alla loro mail.
PS: Il livello di Hackxor a cui faccio riferimento è circa a metà della sfida. Oltre a questo livello non farò spoiler, in quanto vi consiglio di eseguirlo autonomamente e completarlo.
Premetto, per farvi comprendere meglio la situazione, che l’attaccante (IO) è l’utente ALGO e la vittima tutti gli altri utenti. In questo caso THURSDAY, che cercherò di attaccare tramite l’utente BOB, a cui ho precedentemente sottratto le credenziali con un attacco SQL Injection.
Dopo essermi loggato all’applicazione GGHB, vediamo un form in cui si può cambiare la password e la mail dell’utente
Andando a modificarla, ci accorgiamo che non c’è nessun controllo per attacchi CSRF e di conseguenza sarà possibile replicare la richiesta, inviandola ad utenti inconsapevoli.
Ora, sapendo che in questa sfida ci sono degli utenti che cliccano sui link nelle mail che ricevono, basta solo creare un form che utilizzi questa vulnerabilità, concatenata ad una vulnerabilità XSS presente nell’applicativo mail (wraithmail), in modo che l’attacco avvenga in maniera automatica.
Il primo form è la richiesta di cambio della mail, mentre il secondo è l’invio delle credenziali alla mail appena cambiata. Poiché l’applicativo mail è vulnerabile a XSS, ho anche inserito un invio dei due form in maniera automatica appena viene visualizzato il messaggio. In questo modo, quando l’utente THURSDAY andrà a visualizzare il messaggio, verranno eseguite in maniera automatica le due richieste e nella mia casella di posta vedrò arrivare le credenziali dello stesso.
Andandola a visitare, infatti
L’attacco ha avuto successo e con una semplice mail, siamo riusciti a modificare sia la mail dell’utente di un’altra applicazione, sia ad ottenerla in chiaro inviandocela alla nostra casella di posta. Vi invito nuovamente a provare hackxor, penso sia una delle sfide più interessanti che abbia mai fatto.
Difese
OWASP ne mostra diverse, ma tra le più comuni abbiamo:
- Token CSRF: questi, se univoci per sessione, non predicibili e soprattutto segreti, non potrebbero permettere l’attacco fatto precedentemente. Infatti, nel caso in cui fosse stato presente un token, la mia richiesta “nascosta” non avrebbe potuto prevederlo e sarebbe andata in errore;
- Attributo Cookie SameSite: è un attributo dei cookie che non permette di inviare un cookie in maniera cross-site, in modo che se fosse stato presente nell’applicativo e l’utente Thursday avessa aperto la mail, la richiesta non sarebbe andata a buon fine perché il cookie di sessione non sarebbe valso per la richiesta cross-site.
- Token JWT: essendo gestito dal browser in maniera diversa rispetto ai cookie, il token JWT potrebbe essere una ottima difesa agli attacchi CSRF. Infatti, esso non viene gestito dal browser ma viene rilasciato direttamente dal server ad ogni richiesta. Se avessimo avuto il token al posto del cookie, l’attacco non avrebbe funzionato.
Conclusioni
Sebbene possa sembrare un attacco di poco conto, cambiamenti di stato in certi applicativi potrebbe avere conseguenze devastanti, come la CVE-2019-12922, che permette la cancellazione di qualsiasi server in phpMyAdmin. Per chi volesse studiare meglio l’attacco, oltre al già nominato Hackxor, consiglio il laboratorio di PortSwigger.