Longueur du jeton CSRF
Existe-t-il une longueur standard du jeton qui doit être utilisé tout en générant les jetons aléatoires? Devrions-nous utiliser le même standard que nous utilisons pour générer des identifiants de session?
Je considérerais que 128 bits d'entropie dans un jeton sont la norme de facto. OWASP et CWE Les deux recommandent ceci au minimum. 20 caractères de base64 (capable de 120 bits) sont également utiles pour quelque chose dans l'URL. Je voudrais également noter que, dans de nombreux cas, les ensemencements pauvres pour ces jetons crée des problèmes. Pour un bit de référence, voir le (type de type de diapositives à la décoration insipide, mais très informative) de http://samy.pl/bh10/ .
Assurez-vous de bien choisir votre source d'entropie.
C'est une question ancienne, mais j'ai eu l'occasion de regarder dans cette question et j'ai décidé d'examiner au moins que les bibliothèques de certaines et du CSRF utilisent par défaut et mes résultats sont les suivants:
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
Notez que mon échantillon est fortement biaisé vers des cadres dont je peux accéder au code source et aux cadres que je connais.
J'ai spécifiquement essayé de trouver des cadres qui utilisent 64 bits ou moins d'entropie pour essayer de justifier pourquoi ATG utiliserait une norme Java "long" et a échoué, alors ma conclusion est que ma conclusion est donc cette conclusion. Les bits sont probablement trop courts.
Cela dit, en supposant qu'un attaquant puisse faire 100 000 demandes par seconde, il devrait prendre environ 2,93 millions d'années en moyenne à la force brute, un jeton CSRF de 64 bits. (Et il ne devrait pas y avoir plus d'un jeton dans tout l'espace de jeton, contrairement aux identifiants de la session.) Donc, peut-être que 64 bits suffisent.
2 ^ 63 / (100,000 * 60 * 60 * 24 * 365) = 2.93 * 10 ^ 6
En CSRF, un attaquant peut faire de nombreuses suppositions. Que se passe-t-il si un employé visite un site d'attaquants et continue ensuite de vacances de Noël? Un attaquant pourrait faire plusieurs millions de demandes de cross-sites. Nous avons une préoccupation similaire pour les identifiants de session. Si l'une ou l'autre valeur est obtenue, la session est compromise. Les mêmes normes de force doivent être appliquées aux jetons CSRF et aux ID de session.
Dans les deux cas assurez-vous que la valeur expire. L'attaquant ne peut pas faire 2 ^ 128 demandes dans une semaine, mais éventuellement, il sera capable de. Si votre générateur de nombres aléatoires est faible, vous pouvez penser que vous avez une autre nonce cryptographique de 2 ^ 128ème, mais cela pourrait être beaucoup moins.