In genere sappiamo che un token casuale aggiunto a ciascuna richiesta è una buona soluzione contro CSRF. Ma come funziona esattamente? Il server Web genera token, lo invia al client in forma nascosta, che questo token viene aggiunto alla richiesta e Webserver lo convalida (per me è ragionevole). il secondo approccio potrebbe essere che il client genera il token e lo invia al web server. Ma come il webserver sa del token, è corretto se non è stato generato dal webserver.
Il token è sempre generato dal server, mai dal client. Hai ragione che se il client ha generato il token, il server non ha potuto verificare che fosse valido. Questo è il motivo per cui ogni singolo schema di mitigazione CSRF include un token generato dal server. Quindi, dal momento che il server ha creato il token, sa sempre quale dovrebbe essere il valore del token e può verificare che il client abbia inviato il token corretto.
È possibile generare un token casuale una volta e archiviare un cookie, quindi inviarlo con ogni modulo come input nascosto in modo da poter controllare il server.
Se uno script ha più moduli da gestire come la maggior parte del codice MVC deve al giorno d'oggi il cookie che contiene il token CSRF sarà lo stesso per tutti, quindi sconfiggere lo scopo del token CSRF poiché ogni token CSRF deve essere specifico per il modulo.
I token CSRF sono un po 'più complicati di così. Questi sono token che impediscono alle persone di pubblicare moduli sul tuo sito web che causano effetti indesiderati ai tuoi utenti. Ti darò un esempio di cosa succede con e senza
Sul tuo sito web, hai un modulo che consente alle persone che hanno effettuato l'accesso di inviare un messaggio al canale di chat principale.
<form action="postmessage/" method="post>
<textarea name="message"></textarea>
<input type="submit" value="Send!" />
</form>
Quando questo modulo viene inviato, andrà a "postmessage /". Quella pagina prenderà il contenuto dell'area di testo e la pubblicherà sul feed accanto all'id dell'utente.
Ora, immagina di andare in un sito che non è affidabile. Su quel sito esiste il seguente codice
<form action="fakesite.fake/postmessage/" method="post" id="secretform">
<input type="hidden" name="message" value="Go to betterfakesite.fake its much better than this site">
</form>
<a href="membersarea/" id="fakelink">Go to Members Area">
<script>
document.getElementById("fakelink").onclick = function(e) {
e.preventDefault();
document.getElementById("secretform").submit();
</script>
Dato che non esiste una protezione CSRF, quando una persona fa clic su quel collegamento verrà inviata al tuo sito e immediatamente pubblicherà un messaggio in cui gli dirà di andare da qualche altra parte.
Ora, riprova con un token CSRF
<form action="postmessage/" method="post>
<input type="hidden" name="_csrf" value="GENERATEDBYSERVER">
<textarea name="message"></textarea>
<input type="submit" value="Send!" />
</form>
Quando visiti questa pagina, viene generato un token per il modulo. Questo token deve essere memorizzato nella sessione degli utenti sul lato server. Quando una persona invia il modulo, invierà anche il token, che il server può quindi verificare rispetto ai token presenti nella sessione degli utenti. Se non è lì, rifiuta il messaggio. Se lo è, accettalo ed elimina il token.
Ora quando vai alla pagina dannosa e fai clic sul link, verrai reindirizzato al tuo sito, ma nessun post sarebbe stato pubblicato. Il token CSRF ti ha protetto.
Un token è sicuro solo quanto lo fai. Quando si genera un token, memorizzarlo sempre nella sessione degli utenti. In PHP è la variabile $ _SESSION e altri equivalenti di lingua. Ciò che questo assicura è che una persona non può generare una tonnellata di questi token, quindi usarli contro altre persone.
JavaScript per impostazione predefinita impedisce le richieste cross-site, la pagina dannosa non può provare a caricare una copia della pagina per estrarre un token. Non possono programmare il loro server per farlo, in quanto i token sono unici per la sessione utente.