Respuesta corta: para evitar que Brute fuerce el token CSRF.

Tomemos un ejemplo trivial: digamos que su token es un solo dígito, que acepta valores de 0 a 9.
Ahora, claro, un atacante no puede leer este valor desde la cookie o el encabezado, pero no tiene que hacerlo, solo puede hacer que el ataque envíe 10 solicitudes de CSRF, una con cada valor posible. Uno de ellos será correcto.

El uso de un valor aleatorio criptográficamente fuerte evitará esto y evitará que el atacante intente escalar este ataque (al enviar el ataque, por ejemplo, 1000 solicitudes en lugar de 10, o 10,000, o ...)

Combinando la mejor de las dos respuestas:

1. La longitud del token debe ser proporcional al número de víctimas y al número de solicitudes por víctima. Si un atacante convence a X victimas para que navegue a su página (mediante ataques de spam o phishing) y cada una de esas páginas intente Y de tokens diferentes, deberá protegerse contra 2 ^{x * y} los ataques. Por ejemplo, si la longitud de su token es de 16 bits, un atacante debe enviar 2 correos electrónicos ¹⁶ que intenten 1 token cada uno, o 2 ⁸ que intenten 2 ⁸ fichas de cada uno. Un atacante puede probar múltiples tokens con un solo clic utilizando Javascript o incrustando múltiples enlaces de imágenes maliciosas por página.

2. Desea usar un generador de números aleatorios criptográficamente seguro para evitar que los atacantes soliciten múltiples tokens, luego usar la secuencia que obtuvieron para predecir qué tokens otros usuarios obtendrán en el futuro futuro.

No lo hace

Solo tiene que ser pseudo aleatorio .

CSRF no es compatible con ataques de fuerza bruta. Considere el vector de ataque:

1. El usuario malicioso crea un correo electrónico especial o una página web con HTML que publica en el sitio de interés
2. El usuario ha iniciado sesión en el sitio de interés y el ID de sesión se pasa de forma pasiva (es una cookie)
3. Se engaña al usuario para que haga clic en el enlace del correo electrónico o página web especialmente diseñado
4. El enlace "falsifica" la solicitud. El enlace no tiene que contener el ID de sesión porque está en la cookie. Y no tiene que pasar el token CSRF que se encuentra en el encabezado (se pasa de forma pasiva, es una cookie). Pero tiene que contener el token CSRF en la publicación del formulario.

No hay forma de que un pirata informático engañe a alguien para que haga clic en un enlace cientos de veces. Incluso si se trata de un script que envía una tonelada de solicitudes en un solo clic (suponiendo que el pirata informático haya descubierto cómo hacerlo): los navegadores no permiten solicitudes AJAX de dominios cruzados, por lo que probablemente estamos hablando de una página que contiene cientos de GIFS transparentes o de alguna otra cosa totalmente extravagante), no será capaz de atravesar una gran cantidad de espacio de búsqueda sin un tiempo de espera.

Además, no hay forma de que el atacante determine si el ataque funcionó con un valor en particular: es un ataque de "disparar y olvidar".

Así que la idea de que el token CSRF puede ser forzado con fuerza bruta es, en el mejor de los casos, inverosímil. El hacker tendría que iniciar sesión personalmente, lo que es un ataque completamente diferente.

La única razón por la que necesita cualquier entropía es porque los ataques CSRF tienden a ser enviados a través de spam. Digamos que usted es un idiota y su token CSRF solo tiene 16 bits de entropía, y el pirata informático envió 65,536 correos spam con exactamente el mismo token. 65536/2 ^ 16 = uno de esos ataques realmente tendría éxito. Suponiendo que el 0% de los correos electrónicos afectaron a los filtros de spam, el 100% de los usuarios los abrió y el 100% de los usuarios se registraron en su aplicación en el momento en que hicieron clic en el vínculo malvado.

Aparte de tener la esperanza de succionar a una tonelada de usuarios, no hay forma de que un pirata informático pueda escalar el ataque lo suficientemente grande como para llamarlo un ataque de fuerza bruta con algún significado.