Il token di autenticità viene utilizzato per prevenire attacchi di falsificazione delle richieste tra siti (CSRF). Per comprendere il token di autenticità, è necessario innanzitutto comprendere gli attacchi CSRF.
CSRF
Supponi di essere l'autore di bank.com. Sul tuo sito è presente un modulo utilizzato per trasferire denaro su un altro account con una richiesta GET:
Un hacker potrebbe semplicemente inviare una richiesta HTTP al server dicendo GET /transfer?amount=$1000000&account-to=999999, giusto?
Sbagliato. L'attacco degli hacker non funzionerà. Il server fondamentalmente penserà?
Eh? Chi è questo ragazzo che cerca di avviare un trasferimento. Non è il proprietario dell'account, questo è certo.
Come fa il server a saperlo? Perché non ci sono session_idcookie per autenticare il richiedente.
Quando accedi con il tuo nome utente e password, il server imposta un session_idcookie sul tuo browser. In questo modo, non è necessario autenticare ogni richiesta con nome utente e password. Quando il browser invia il session_idcookie, il server sa:
Oh, quello è John Doe. Ha effettuato l'accesso con successo 2,5 minuti fa. È bravo ad andare.
Un hacker potrebbe pensare:
Hmm. Una normale richiesta HTTP non funzionerà, ma se potessi mettere la mano su quel session_idcookie, sarei dorato.
Il browser degli utenti ha un gruppo di cookie impostati per il bank.comdominio. Ogni volta che l'utente bank.cominvia una richiesta al dominio, vengono inviati tutti i cookie. Incluso il session_idcookie.
Quindi, se un hacker potrebbe ottenere voi di fare la richiesta GET che i trasferimenti di denaro sul suo conto, che sarebbe successo. Come potrebbe indurti a farlo? Con falsificazione richiesta su più siti.
È abbastanza semplicemente, in realtà. L'hacker potrebbe farti visitare il suo sito Web. Sul suo sito Web, potrebbe avere il seguente tag immagine:
<img src="http://bank.com/transfer?amount=$1000000&account-to=999999">
Quando il browser degli utenti incontra quel tag immagine, farà una richiesta GET a quell'URL. E poiché la richiesta proviene dal suo browser, invierà con essa tutti i cookie associati bank.com. Se l'utente ha recentemente effettuato l'accesso a bank.com... il session_idcookie verrà impostato e il server penserà che l'utente intendesse trasferire $ 1.000.000 all'account 999999!
Bene, non visitare siti pericolosi e andrà tutto bene.
Questo non è abbastanza. E se qualcuno pubblica quell'immagine su Facebook e appare sulla tua bacheca? Cosa succede se viene iniettato in un sito che stai visitando con un attacco XSS?
Non è così male. Solo le richieste GET sono vulnerabili.
Non vero. Un modulo che invia una richiesta POST può essere generato dinamicamente. Ecco l'esempio della Guida di Rails sulla sicurezza :
<a href="http://www.harmless.com/" onclick="
var f = document.createElement('form');
f.style.display = 'none';
this.parentNode.appendChild(f);
f.method = 'POST';
f.action = 'http://www.example.com/account/destroy';
f.submit();
return false;">To the harmless survey</a>
Token di autenticità
Quando hai ApplicationControllerquesto:
protect_from_forgery with: :exception
Questo:
<%= form_tag do %>
Form contents
<% end %>
È compilato in questo:
<form accept-charset="UTF-8" action="/" method="post">
<input name="utf8" type="hidden" value="✓" />
<input name="authenticity_token" type="hidden" value="J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX/8Cts=" />
Form contents
</form>
In particolare, viene generato:
<input name="authenticity_token" type="hidden" value="J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX/8Cts=" />
Per proteggersi dagli attacchi CSRF, se Rails non vede il token di autenticità inviato insieme a una richiesta, non la considererà sicura.
In che modo un utente malintenzionato dovrebbe sapere cos'è questo token? Un valore diverso viene generato casualmente ogni volta che viene generato il modulo:
Un attacco Cross Site Scripting (XSS): ecco come. Ma questa è una vulnerabilità diversa per un giorno diverso.