Il Cross Site Request Forgery, chiamato anche CSRF, è una vulnerabilità che si verifica quando manca un adeguato controllobsulle richieste che non vengono inviate intenzionalmente, ma sono pensate da un utente malintenzionato che successivamente le farà eseguire alla vittima tramite un link che porta ad un pagina html, la quale invierà la richiesta senza che la vittima se ne accorga.Tramite CSRF è possibile effettuare azioni più o meno gravi, per questo motivo vanno classificati in base all'impatto e ai danni che possono causare ad ogni utente.

Basso Impatto

Questi tipi di CSRF non hanno un grande impatto sulla sicurezza se sfruttati, a parte causare qualche fastidio, non arrecano danni ingenti agli utenti di un sito web vulnerabile. Un esempio potrebbe essere un CSRF di logout, ovvero visitando una pagina contenente quel tipo di CSRF si verrà sloggati dal sito web in questione e bisognerà effettuare di nuovo il login.

Se ad esempio un utente è loggato sul sito 'testsite' ed io inserisco in una pagina html del mio sito (diverso da testsite) il seguente codice:

<img src="http://www.testsite.com/logout">

Ed infine mando il link di quella pagina all'utente, una volta che esso aprirà la pagina sarà sloggato dal sito 'testsite' e dovrà ripetere il login.

Un altro esempio potrebbe essere un CSRF che va a modificare le preferenze delle impostazioni di ricezione delle notifiche via email, dove se ad esempio era stato impostato di ricevere un email per ogni post che viene creato, visitando la pagina che contiene il CSRF non si riceverà più un email per ogni post. Basterà settare di nuovo le impostazioni per risolvere il problema.

Medio Impatto

I CSRF a medio impatto causano una moderata quantità di danni all'utente ma non compromettono del tutto l'utilizzo del profilo e del sito web.

Un esempio form vulnerabile a CSRF potrebbe essere:

<form action="http://www.testsite.com/Trasferisci.php" method="get">
<input type="text" name="username-destinatario" value="Nomeutente">
<input type="text" name="valuta" value="EURO">
<input type="text" name="importo" value="1000">
<input type="submit" value="Trasferisci">

</form>

Richiesta generata:

http://www.testsite.com/Trasferisci.php?username-destinatario=Nomeutente&valuta=EURO&importo=1000

Se inviato questo form genera una richiesta GET, che per usare lo stesso esempio di prima, viene inserita in una pagina html dentro ad il tag html img, la quale può essere sfruttata per trasferire 1000 euro dall'account della vittima all'account dell'utente malintenzionato senza che se ne accorga.

<img src="http://www.testsite.com/Trasferisci.php?username-destinatario=Nomeutente&valuta=EURO&importo=1000">

Alto Impatto

Questi tipi di CSRF se sfruttati causano grossi danni agli utenti che ne sono vittima. Fanno parte di questa categoria
quelli che permettono di cancellare l'account o modificare i dati d'accesso della vittima e darebbero possibilità ad un utente malintenzionato di prenderne il controllo.
Un form che permette di cambiare l'indirizzo email potrebbe essere vulnerabile a CSRF e se un utente malintenzionato sfruttasse questa vulnerabilità potrebbe cambiare l'indirizzo email di un account, semplicemente inviando un link alla vittima, che senza saperlo, sostituirà l'email che usa per accedere al sito con quella immessa dall'utente malintenzionato.
Il quale, pur non sapendo la password, potrebbe resettarla tramite la funzione 'password dimenticata' per poi entrare nell'account della vittima e prenderne il totale controllo. Se ciò accadesse il bersaglio non sarebbe più in grado di riprendere il controllo del suo account.

Esempio di Full Account Takeover- CSRF:

Se un'utente malintenzionato aggiunge al suo sito Web la richiesta riportata qua sotto e la manda alla vittima, l'email di quest'ultima viene cambiata con quella scelta dal malintenzionato.

A questo punto, l'utente malintenzionato non deve far altro che richiedere una nuova password per prendere il controllo dell'account.

<form action="http://www.testsite.com/ChangeEmail.php" method="post">
<input type="text" name="username" value="Nomeutente">
<input type="email" name="email" value="Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.">
<input type="submit" value="Aggiorna">

</form>

Le richieste di tipo POST, possono anch'esse essere vulnerabili a CSRF, ma per sfruttare tali richieste va ricostruito il form che genera la richiesta (o copiato direttamente dal sorgente pagina) e poi va reso "self-submit",
Ovvero, fare in modo che il form si invii da solo appena la pagina che lo contiene viene aperta. Per fare ciò basta
semplicemente assegnare un id al form e poi inserire seguente codice all'interno dei tag <body></body>:

<body on-load="document.[ID-form].submit();">

Una vulnerabilità molto simile al CSRF è detta Insecure Direct Object Reference, anche detta IDOR, che a differenza del CSRF non richiede un'interazione da parte della vittima per essere sfruttata, ma all'utente malintenzionato basta solamente conoscere l'ID dell'account della vittima per cambiarne i dati, oppure cancellare l'intero account.
Questo tipo di vulnerabilità si verifica quando un applicazione fornisce accesso diretto agli oggetti in base all'input fornito dall'utente.
Tramite ciò un utente malintenzionato può accedere a risorse protette come database o file semplicemente modificando il valore di un parametro inviato in una richiesta, il tutto è possibile poichè non sono presenti nella richiesta sufficienti controlli d'autorizzazione. Ad esempio se la seguente richiesta corrisponde al tasto "Elimina Account" per l'utente con "ID account = 3". Se non ci sono abbastanza controlli sull'autorizzazione, l'utente con ID=3 potrà eliminare l'account dell'utente con ID=2 semplicemente inviando la seguente richiesta (cosa che non dovrebbe essere in grado di fare) eliminando dal database del sito tutti i dati dell'utente con ID=2:

http://testsite.com/user-id/2/delete

Come difendersi:

Per difendersi da questo tipo di vulnerabilità si possono scegliere diverse strade: La più comune è quella di implementare
un csrf_token o xsrf_token, ovvero un [codice-generato-random-dal-server] per ogni form che trasmette informazioni sensibili che causerebbero danni in caso fossero vulnerabili. Se proprio non si vuole utilizzare un csrf_token per proteggersi da questa vulnerabilità è possibile richiedere una conferma aggiuntiva (ad esempio chiedendo la password corrente dell'account dal quale si cerca di mandare la richiesta) ai form che trattano informazioni sensibili.

Form con CSRF-Token:

<form action="http://www.testsite.com/ChangeEmail.php" method="post">
<input type="text" name="username" value="Nomeutente">
<input type="email" name="email" value="Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.">
<input type="hidden" name="csrf_token" value="random-string">
<input type="submit" value="Aggiorna">

</form>

Il valore di Token verrà generato casualmente e quindi verificato dal Server.
Nel caso in cui il esso non coincida con quello fornito, comparirà un messaggio di errore, rendendo impossibile per un utente malintenzionato conoscerne il valore e evitando che la vulnerabilità venga sfruttata.