Risposta breve: per impedire che la forza bruta forzi il token CSRF.

Facciamo un esempio banale: supponiamo che il tuo token sia una singola cifra, accettando valori da 0 a 9.
Ora sicuro, un utente malintenzionato non può leggere questo valore dal cookie o dall'intestazione, ma non è obbligato a farlo - può solo fare in modo che l'attacco invii 10 richieste CSRF, una con ogni possibile valore. Uno di questi sarà corretto.

L'uso di un valore casuale crittografico strong impedirà questo e può impedire all'attentatore di tentare di scalare questo attacco (facendo sì che l'attacco invii, ad esempio, 1000 richieste invece di 10, o 10.000 o ...)

Combinando il meglio di entrambe le risposte:

1. La durata del token deve essere proporzionale al numero di vittime e al numero di richieste per vittima. Se un utente malintenzionato convince X di vittime a navigare verso la sua pagina (tramite spam o attacchi di phishing) e ciascuna di tali pagine tenta Y di token diversi, allora devi proteggerti contro 2 ^{x * y} attacchi. Ad esempio, se la lunghezza del token è 16 bit, un utente malintenzionato deve inviare 2 email ¹⁶ che tentano 1 token ciascuna o 2 ⁸ e-mail che tentano 2 ⁸ token ciascuno. Un utente malintenzionato può provare più token con un solo clic utilizzando Javascript o incorporando più collegamenti di immagine dannosi per pagina.

2. Si desidera utilizzare un generatore di numeri casuali protetto da crittografia per impedire agli attaccanti di richiedere più token, quindi utilizzare la sequenza che hanno ottenuto per prevedere quali token altri utenti avranno nel vicino futuro.

Non

Deve essere pseudo random .

CSRF non è compatibile con attacchi di forza bruta. Considera il vettore di attacco:

1. L'utente malintenzionato crea un'e-mail o una pagina Web speciale con HTML che pubblica sul sito di interesse
2. L'utente è connesso al sito di interesse e l'ID della sessione viene passato passivamente (è un cookie)
3. L'utente viene indotto a fare clic sul link nell'email o nella pagina Web appositamente predisposta
4. Link "forgia" la richiesta. Il link non deve contenere l'ID di sessione perché è nel cookie. E non deve passare il token CSRF trovato nell'intestazione (è passato passivamente - è un cookie). Ma deve contenere il token CSRF nel post del modulo.

Non c'è modo che un hacker possa indurre chiunque a fare clic su un link centinaia di volte. Anche se si tratta di uno script che invia un sacco di richieste con un solo clic (supponendo che l'hacker abbia capito come farlo), i browser non consentono richieste AJAX tra domini, quindi probabilmente stiamo parlando di una pagina contenente centinaia di di clear GIFS o qualcos'altro totalmente whacky), non sarà in grado di attraversare un sacco di spazio di ricerca senza ritardi.

Inoltre, non c'è modo per l'attaccante di determinare se l'attacco ha funzionato per un particolare valore-- è un attacco "fuoco e dimentica".

Quindi l'idea che il token CSRF possa essere forzato brutalmente è inverosimile nel migliore dei casi. L'hacker dovrebbe essere personalmente connesso - che è un attacco completamente diverso.

L'unica ragione per cui hai bisogno di qualsiasi entropia è perché gli attacchi CSRF tendono ad essere consegnati via spam. Diciamo che sei un idiota e il tuo token CSRF ha solo 16 bit di entropia e l'hacker ha inviato 65.536 email di spam con lo stesso identico token. 65536/2 ^ 16 = uno di quegli attacchi sarebbe effettivamente successo. Supponendo che lo 0% delle e-mail colpisca i filtri spam, il 100% degli utenti li ha aperti e il 100% degli utenti si è collegato alla tua app nel momento in cui ha fatto clic sul link malvagio.

Oltre a sperare di risucchiare un sacco di utenti, non c'è modo per un hacker di ridimensionare l'attacco abbastanza a sufficienza da considerarlo un attacco di forza bruta con qualsiasi significato.