Visualizza wikitesto di 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]] (XSS), che sfrutta la fiducia di un utente in un particolare sito, il CSRF sfrutta la fiducia di un sito nel browser di un utente.

==Possibile tecnica==
Un attaccante fa in modo che un utente vittima invii involontariamente una richiesta [[Hypertext Transfer Protocol|HTTP]] dal suo [[browser Web|navigatore]] al sistema ''web'' in cui è attualmente autenticato; il sistema, vulnerabile al CSRF, avendo la certezza che la richiesta provenga dall'utente già precedentemente autenticato la esegue senza sapere che in realtà dietro di essa si cela un'azione pensata dall'attaccante, come per esempio un trasferimento di fondi, un acquisto di un oggetto, una richiesta di dati o qualsiasi altra funzione offerta dall'applicazione vulnerabile.
Ci sono innumerevoli modi coi quali un utente può essere ingannato nell'inviare una richiesta pensata da un attaccante a un server ''web'', per esempio nascondendo la richiesta in un [[Tag HTML|elemento HTML]] come un'immagine, un'''[[XMLHttpRequest]]'' o un [[URL]].

==Esempio di attacco==
Supponiamo che l'utente A si sia autenticato al sito www.ilmiocontobancario.it per l'accesso 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: l'utente 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 un'immagine come il seguente: 
''<IMG src='www.ilmiocontobancario.it/... versamento?importo=1000E&destinatario=B'>''.
Quando A tenterà di accedere all'immagine, il [[browser Web|browser]] invierà di fatto una richiesta [[Hypertext Transfer Protocol|HTTP]] alla pagina web indicata cercando di caricare l'immagine. Il sito ''www.ilmiocontobancario.it'' rileverà, tramite il [[cookie]], che la richiesta arriva effettivamente da A e perciò autorizzerà l'operazione.

==Valutazione gravità==
Cross-site request forgery si piazza al nono posto nella lista dei 25 errori più comuni e pericolosi che riguardano il software redatta dal Mitre in collaborazione con il [[SANS|Sans Institute]]<ref>{{Cita web|url = https://cwe.mitre.org/top25/index.html |titolo = 2019 CWE Top 25 Most Dangerous Software Errors|lingua = inglese|accesso = 5 luglio 2020}}</ref>. 
Secondo la lista, questa vulnerabilità è incontrata molto spesso nel codice, con la conseguenza che un eventuale [[exploit]] può permettere all'attaccante 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 nell'architettura del codice stesso. Un sistema può essere giornalmente esposto ad attacchi informatici che sfruttano questa debolezza facendo sì che la frequenza dell'attacco sia ritenuta alta nonostante una moderata difficoltà nel trovare un suo [[exploit]].

==Misure per la mitigazione del rischio==
La seguente lista rappresenta una serie di contromisure per mitigare il rischio di un attacco CSRF:
* 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 [[Referer|HTTP referer]] per vedere se la richiesta è stata generata da una pagina valida.
* 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.
* Usare [[framework]], [[libreria software|librerie]], moduli e in generale codice fidato che permettano allo sviluppatore di evitare l'introduzione di questa vulnerabilità.
* Identificare quelle operazioni che possano risultare pericolose e quando un utente genera un'operazione di questo tipo inviare una richiesta addizionale di conferma all'utente, per esempio, la richiesta di una [[password]], che deve essere verificata prima di eseguire l'operazione.
* Dal lato utente è buona abitudine eseguire sempre il [[logout]] da [[sito web|siti web]] sensibili prima di visitare altre [[pagine web]].

== Note ==
<references/>

== Voci correlate ==
* [[Same origin policy]]
* [[Cross-site scripting]]
* [[Replay attack]]

{{Portale|sicurezza informatica}}

[[Categoria:Tecniche di attacco informatico]]