Lunghezza del token CSRF

Ritengo che un 128 bit di entropia in un token sia lo standard di fatto. OWASP e CWE lo raccomandano entrambi come minimo. 20 caratteri di Base64 (capaci di 120 bit) sono utili anche per qualcosa nell'URL. Vorrei anche notare che in molti casi una semina povera per quei token crea problemi. Per un po 'di riferimento, guarda le diapositive (tipo di decorazioni senza gusto, ma molto istruttive) dal link .

Assicurati di scegliere bene la fonte di entropia.

Questa è una vecchia domanda, ma ho avuto l'occasione di esaminare questa domanda e ho deciso di esaminare almeno in che modo alcune librerie di CSRF vengono utilizzate per impostazione predefinita e i miei risultati sono i seguenti:

Django : 32 random characters from the set [a-zA-Z0-9] : 190.53 bits of entropy Ruby on Rails : 32 bytes of entropy (encoded as base64) : 256 bits of entropy Spring Security : UUID4 (actually, this seems to use a PRNG, not an RNG, if I'm not mistaken) : 122 bits of entropy OSASP PHP CSRF Guard (https://www.owasp.org/index.php/PHP_CSRF_Guard) : 128 characters from the set [a-z0-9] : 661.75 bits of entropy OWASP J2EE CSRF Guard : 32 characters in the set [A-Z0-9] : 165.44 bits of entropy Oracle ATG version 10.1.1 : a standard Java "long" encoded using ascii base 10: 64 bits of entropy

Si noti che il mio campione è strongmente sbilanciato verso i framework di cui posso accedere al codice sorgente e ai framework con cui ho familiarità.

Ho cercato specificatamente di trovare framework che usano 64 bit o meno di entropia per cercare di giustificare il motivo per cui ATG userebbe un Java standard "long" e non hanno avuto successo, quindi la mia conclusione è che 64 bit è probabilmente troppo breve.

Detto questo, supponendo che un utente malintenzionato possa fare 100.000 richieste al secondo, in media occorrono circa 2,93 milioni di anni per forzare un token CSRF a 64 bit. (E non dovrebbe esserci più di un token nell'intero spazio token, a differenza degli ID di sessione.) Quindi, forse 64 bit sono sufficienti.

2 ^ 63 / (100,000 * 60 * 60 * 24 * 365) = 2.93 * 10 ^ 6

In CSRF un attaccante può fare molte supposizioni. Cosa succede se un dipendente visita un sito di aggressori e poi va in vacanza di Natale? Un utente malintenzionato potrebbe effettuare molti milioni di richieste cross-site. Abbiamo una preoccupazione simile per gli ID di sessione. Se si ottiene un valore, la sessione viene compromessa. Gli stessi standard di forza devono essere applicati sia ai token CSRF che agli ID sessione.

In entrambi i casi assicurati che il valore scada . L'utente malintenzionato non può effettuare 2 ^ 128 richieste in una settimana, ma alla fine sarà in grado di farlo. Se il generatore di numeri casuali è debole, potresti pensare di avere un nonce di crittografia 2 ^ 128th, ma potrebbe essere molto meno.