Perché due token CSRF (campo nascosto e cookie) sono necessari per mitigare gli attacchi CSRF?

Il pattern che stai descrivendo è noto come "double submit cookie" ed è un modo comune per difendersi da CSRF. Il punto qui è che non richiede che il server ricordi il token. Il client invia il token sia in un cookie che in un altro modo, ad es. in un campo modulo. Il server controlla che entrambi i token siano identici.

Funziona perché l'utente malintenzionato non può leggere o scrivere il cookie e quindi non può riprodurlo nel campo modulo. Questo è il motivo per cui deve essere inviato due volte:

• Se esistesse solo un cookie, verrebbe inviato automaticamente ad ogni richiesta e non fornirà alcuna protezione.
• Se esistesse solo un campo modulo, non ci sarebbe nulla da confrontare e l'autore dell'attacco potrebbe inserire qualsiasi valore.

Ci sono altre difese contro CSRF, che usano solo un token. Il più comune è solo memorizzare il valore corretto in una variabile di sessione sul server e controllare che un campo modulo lo corrisponda. Nessun cookie è necessario. Tuttavia, questo ha lo svantaggio che il server deve mantenere uno stato per utente.

Un token è sufficiente purché sia il campo del modulo nascosto ed è per richiesta (ovvero si riceve un token in ogni risposta da inviare alla richiesta successiva). Si noti che il token non deve essere memorizzato in un cookie poiché i cookie vengono inviati automaticamente.

Ci sono diversi modi per fare le cose (e alcuni sono specifici per il framework). Il processo a due token serve anche come un buon modo per risolvere il problema CSRF. Il token nel cookie e nella pagina sono collegati crittograficamente. Quindi il server deve fare questo controllo e procedere con l'elaborazione di questa richiesta se tutto è buono.

Per prevenire gli attacchi CSRF, il token CSRF deve essere confrontato con il token previsto.

Il sito web deve memorizzare quel token previsto e un modo comune per farlo è impostare un cookie.

Se entrambi i token corrispondono, il modulo è valido.