Archivi tag: on-click attack

Attacco CSRF (Cross Site Request Forgery)

In questo post abbiamo parlato del Cross Site Scripting. Ora ci concentreremo su un altro tipo di attacco Web piuttosto diffuso, ovvero il CSRF (Cross Site Request Forgery). A differenza dell’XSS, la cui logica si basa sulla fiducia riposta dagli utenti su un determinato sito Web, il CSRF si fonda sulla fiducia di un sito Web nei confronti del browser degli utenti. Bhè, mi rendo conto che tale affermazione può risultare un pò criptica, ma lasciatemi spiegare meglio.

Supponiamo che l’utente Bob si sia autenticato sul portale on-line della propria banca, ovvero http://bank.example. Supponiamo inoltre che tale portale salvi le credenziali di accesso all’interno di un cookie e che l’expiration date (la data di scadenza) di quest’ultimo non sia proprio “imminente”. Bob, dopo aver effettuato alcune operazioni sul portale sopra citato (ad esempio controllare il saldo, la lista movimenti, ecc.), continua la navigazione passando da un sito Web all’altro. Accede quindi su un forum che è solito frequentare, clicca su un 3D che ha richiamato la sua attenzione in cui è presente un tag <img> con il seguente attributo: src=”http://bank.example/withdraw?account=bob&amount=10000000&for=Trudy” e, nel momento in cui il suo browser cercherà di caricare l’immagine dall’indirizzo precedentemente menzionato… boom, il danno è fatto. Da notare che la riuscita dell’attacco (e la realizzazione dello stesso), avviene in modo completamente trasparente, sarebbe a dire che la vittima non si accorgerà assolutamente di nulla.

Ma come mai un semplice tag <img> è bastato a far cadere il povero Bob nella trappola tesa da Trudy? Esaminiamo l’indirizzo http://bank.example/withdraw?account=bob&amount=100000&for=Trudy. Possiamo notare la presenza dei caratteri ? e &, classici delle querystring, attraverso le quali gli utenti inviano i dati ai server WEB sfruttando il metodo HTTP GET. Nella fattispecie, viene autorizzata una transazione dal conto dell’utente Bob per un ammontare pari a 100000 $ (o €, fate voi), verso l’utente Trudy, ovvero l’attacker, anche lui cliente della banca di Bob.

Inutile dire che gli effetti potenziali di questo attacco sono completamente imprevedibili (come già detto per l’XSS), anche se, in realtà, l’attuazione del CSRF non è così semplice come può sembrare. Infatti, affinchè tale attacco vada a buona fine, è necessario che vi siano alcune situazioni concomitanti, quali:

1) Il sito a cui punta l’URL malevolo generato dall’attaccante non deve prevedere il controllo del campo referrer presente nell’header HTTP (ovvero verificare il sito di provenienza dei visitatori);

2) L’attaccante deve individuare i giusti parametri da passare al server mediante querystring;

3) La vittima deve essere ancora loggata al sito vulnerabile nel momento in cui l’attacco viene sferrato.

La prevenzione è piuttosto semplice e si basa su alcune regole di buon senso. Ad esempio il sito deve garantire il controllo del referrer, deve consentire la sola autenticazione mediante HTTP POST e GET o, in alternativa, ridurre sensibilmente la durata dei cookie. Inoltre, sarebbe opportuno utilizzare un token (gettone) univoco e pseudocasuale per ogni richiesta HTTP POST effettuata dagli utenti.

Prossimamente analizzeremo alcune varianti del CSRF. A presto.