CSRF: valor aleatorio o HMAC

  

El primero utiliza tokens CSRF generados aleatoriamente, que utiliza un generador criptográfico aleatorio fuerte para generar el token.

Esto es ideal. En este caso, el token es un bloque opaco absolutamente impredecible sin importancia fuera del contexto previsto.

  

La segunda implementación que encontré usa HMAC que cifra el ID de sesión con   clave secreta almacenada en la configuración del lado del servidor.

Esto es más sencillo de implementar. Es de suponer que los ID de sesión ya se están generando, por lo que no es necesario persistir nada adicional. Dado que no es necesario un almacenamiento adicional, podría ser que este mecanismo se pueda implementar en situaciones donde un token aleatorio no se pueda trabajar en un diseño heredado. Esta es una solución relativamente elegante. Suponiendo que la clave secreta no sea conocida por el atacante, el token no debería ser reproducible fuera del servidor.

  

La tercera implementación que vi usa una combinación de ambos, una clave secreta almacenada en la configuración del lado del servidor se usa para HMAC un valor generado aleatoriamente

Esto es un poco tonto. Presumiblemente impulsado por el hecho de que un HMAC es un concepto relacionado con la seguridad, el autor intenta agregar seguridad a su diseño al incluir algo relacionado con la seguridad. Una especie de mágico talismán de seguridad. Es de suponer que no es peor que usar el número aleatorio solo, pero ciertamente no es mejor. A menos que cuente la cálida sensación borrosa que obtiene al usar HMAC en su implementación de seguridad.

Es es , sin embargo, es una solución alternativa si tiene un RNG deficiente, aunque en ese caso probablemente mezclaría el ID de sesión o algo similar antes de hacer hash para que pueda Garantizado que el número que hash es único.

Sé que asp.net MVC 3/4 usa un método similar al 2. El problema que encuentro con este enfoque es que hay un token CSRF para la sesión, en lugar de hacerlo mediante la forma. Por ejemplo, si obtengo el token CSRF una vez, ese token es válido para cualquier publicación de formulario durante el curso de la sesión. Cuando se prueba con una herramienta como ZAP, una solicitud me da el token que luego puedo reutilizar a mi gusto. Además de esto, el token debe escribirse en algún lugar de la página HTML (no se almacena en una cookie, por ejemplo) y luego un atacante puede leerlo fácilmente en busca de la cadena específica.

Me gusta la idea de 1/3. La aleatoriedad proporciona seguridad por formulario / llamada, a diferencia de una por sesión. También se puede utilizar para evitar múltiples publicaciones de la misma forma. Esto sería útil en un sistema transaccional en el que querría asegurarse de que un envío solo ocurra una vez. Cuando el servidor recibe el primer envío, invalida el token. El siguiente envío fallaría. El atacante ahora tiene que obtener un token y usarlo antes que el usuario.

Puedo ver su punto con respecto al agrupamiento / balanceo de carga, pero la mayoría de los balanceadores de carga pueden / remitirán solicitudes desde la misma sesión al mismo servidor backend.