Longitud del token CSRF

Consideraría que un estándar de facto es una entrada de 128 bits de entropía en un token. OWASP y CWE ambos recomiendan esto como mínimo. 20 caracteres de Base64 (con capacidad para 120 bits) también son útiles para algo en la URL. También me gustaría señalar que, en muchos casos, una mala siembra para esos tokens crea problemas. Para obtener un poco de referencia, consulte las diapositivas (tipo de decoración sin sabor, pero muy informativas) de enlace .

Asegúrate de elegir bien la fuente de entropía.

Esta es una pregunta antigua, pero tuve la oportunidad de analizar esta pregunta y decidí por lo menos analizar qué utilizan algunas de las bibliotecas CSRF de forma predeterminada y mis resultados son los siguientes:

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

Tenga en cuenta que mi muestra está muy orientada hacia los marcos de los cuales puedo acceder al código fuente y los marcos con los que estoy familiarizado.

Intenté específicamente encontrar marcos que usen 64 bits o menos de entropía para intentar justificar por qué ATG usaría un Java estándar "largo" y no tuvo éxito, por lo que mi conclusión es que es probable que 64 bits sea demasiado breve.

Dicho esto, asumiendo que un atacante puede hacer 100,000 solicitudes por segundo, debería tomar alrededor de 2.93 millones de años en promedio para forzar a un token CSRF de 64 bits. (Y no debería haber más de un token en todo el espacio de token, a diferencia de los identificadores de sesión). Por lo tanto, tal vez 64 bits sean suficientes.

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

En CSRF, un atacante puede hacer muchas conjeturas. ¿Qué pasa si un empleado visita un sitio de atacantes y luego se va de vacaciones de Navidad? Un atacante podría hacer muchos millones de solicitudes entre sitios. Tenemos una preocupación similar para los identificadores de sesión. Si se obtiene cualquiera de los dos valores, la sesión se ve comprometida. Los mismos estándares de solidez deben aplicarse tanto a los tokens CSRF como a los identificadores de sesión.

En ambos casos, asegúrese de que el valor caduque . ¿Puede el atacante no hacer 2 ^ 128 solicitudes en una semana, pero eventualmente podrá hacerlo? Si su generador de números aleatorios es débil, entonces puede pensar que tiene una fuente criptográfica 2 ^ 128, pero podría ser mucho menos.