Indietro

ⓘ Cross-site request forgery




                                     

ⓘ Cross-site request forgery

Il Cross-site request forgery, abbreviato CSRF o anche XSRF, è 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. Diversamente dal cross-site scripting, che sfrutta la fiducia di un utente in un particolare sito, il CSRF sfrutta la fiducia di un sito nel browser di un utente.

                                     

1. Possibile tecnica

Un attaccante fa in modo che un utente vittima invii involontariamente una richiesta HTTP dal suo browser al sistema web dove è attualmente autenticato. Il sistema, vulnerabile al CSRF, avendo la certezza che la richiesta provenga dallutente già precedentemente autenticato la esegue senza sapere che in realtà dietro la richiesta si cela unazione pensata dallattaccante come ad esempio un trasferimento di fondi, un acquisto di un oggetto, una richiesta di dati o qualsiasi altra funzione offerta dallapplicazione vulnerabile. Ci sono innumerevoli modi con i quali un utente può essere ingannato nellinviare una richiesta pensata da un attaccante a un web server. Questo può essere fatto nascondendola ad esempio in un elemento HTML di unimmagine, una XMLHttpRequest o un URL.

                                     

2. Esempio di attacco

Supponiamo che lutente A si sia autenticato al sito www.ilmiocontobancario.it per laccesso alle operazioni sul suo conto bancario. Il sito www.ilmiocontobancario.it ha un form per i versamenti che, nel momento in cui invieremo i dati, richiederà una pagina del tipo www.ilmiocontobancario.it/versamento?importo=XXXX&destinatario=XXXX ; ad esempio: lutente B invia ad A, eventualmente attraverso la sua email, un tag img html al fine di caricare automaticamente il contenuto del link come se fosse unimmagine come il seguente. Quando A tenterà di accedere allimmagine, il browser invierà di fatto una richiesta HTTP alla pagina web indicata cercando di caricare limmagine. Il sito www.ilmiocontobancario.it rileverà, tramite il cookie, che la richiesta arriva effettivamente da A e perciò autorizzerà loperazione.

                                     

3. Valutazione gravità

Cross-site request forgery si piazza al dodicesimo posto nella lista dei 25 errori più comuni e pericolosi che riguardano il software redatta dal Mitre in collaborazione con il Sans Institute. Secondo la lista, questa vulnerabilità è incontrata molto spesso nel codice, con la conseguenza che un eventuale exploit può permettere allattaccante di eseguire del codice maligno oppure rubare, modificare e alterare dati sensibili. La correzione di questa vulnerabilità su codice già scritto e implementato è vasta, richiede cioè cambiamenti significativi e profondi nellarchitettura del codice stesso. Un sistema può essere giornalmente esposto ad attacchi informatici che sfruttano questa debolezza facendo sì che la frequenza dellattacco sia ritenuta alta nonostante una moderata difficoltà nel trovare un suo exploit.

                                     

4. Misure per la mitigazione del rischio

La seguente lista rappresenta una serie di contromisure per mitigare il rischio di un attacco CSRF:

  • Identificare quelle operazioni che possano risultare pericolose e quando un utente genera unoperazione di questo tipo inviare una richiesta addizionale di conferma allutente, per esempio, la richiesta di una password, che deve essere verificata prima di eseguire loperazione.
  • Verificare che il sistema sia esente da vulnerabilità di tipo cross-site scripting poiché molte delle difese CSRF possono essere evitate usando vulnerabilità di questo tipo.
  • Dal lato utente è buona abitudine eseguire sempre il logout da siti web sensibili prima di visitare altre pagine web.
  • Non utilizzare il metodo GET per richieste che comportano un cambiamento di stato, come ad esempio la modifica di dati. Controllare il campo di intestazione HTTP referer per vedere se la richiesta è stata generata da una pagina valida.
  • Usare framework, librerie, moduli e in generale codice fidato che permettano allo sviluppatore di evitare lintroduzione di questa vulnerabilità.