Ventajas de múltiples tokens CSRF válidos

  

Mi pregunta es: ¿Cuáles son las ventajas de varios tokens CSRF válidos?

En general, no hay una ventaja de seguridad particular ... el bit importante acerca de un token es cuándo y cómo se vuelve inválido (como en la discusión anterior acerca de si un token se vuelve inválido después de una sola solicitud o no). Cuando y cuantos tokens se generan es más un detalle de implementación:

Si implementa tokens CSRF como valores aleatorios almacenados de forma persistente (el patrón del 'token sincronizador'), realmente no desea almacenar más de un token por sesión, ya que tomará más y más ancho de banda de la base de datos para hacerlo. Por lo tanto, es natural en este modelo tener un solo token almacenado como un atributo en la sesión.

Si implementa tokens CSRF como una firma (generalmente: HMAC) sobre la aserción de sesión, entonces está validando ese token al verificar la firma con la clave secreta de su aplicación, por lo que no necesita almacenar el token en el servidor. lado en absoluto En este modelo, es barato generar / firmar un token nuevo cada vez, y como los tokens suelen incluir una marca de tiempo y una sal aleatoria, serán diferentes cada vez.

La ventaja habitual del método de firma es que no necesita almacenamiento, por lo que potencialmente puede ser parte de un esquema de control de acceso sin sesión. La desventaja es que necesita administrar la clave secreta de manera segura. (Pero a menudo ya tienes esa carga de todos modos).

Sin embargo ...

  

Entonces, ¿por qué los desarrolladores de Connect decidieron generar un nuevo token en cada solicitud

No está claro. A juzgar por el código en la página vinculada, Connect tiene un valor aleatorio almacenado en la sesión, pero luego los tokens que emite son firmas sobre este valor aleatorio y otro valor aleatorio por token.

Esto no parece tener ninguna ventaja sobre el token de sincronizador simple: aún tiene que almacenar los atributos de la sesión, y los tokens emitidos no están limitados por ninguna otra restricción firmada (por ejemplo, marca de tiempo de caducidad o revocación). Por lo tanto, el conocimiento del token emitido otorga el mismo acceso que el conocimiento del valor aleatorio almacenado. Son totalmente equivalentes, por lo que no hay ningún punto obvio en el hecho de tener los tokens emitidos que varían, puedes simplemente emitir el valor aleatorio almacenado sin ningún inconveniente de seguridad.     

De acuerdo con

Casi todos los sitios web, incluida la banca en línea, deben usar tokens por sesión. Si tu aplicación lanza armas nucleares, entonces tal vez querrías tokens por solicitud, pero dudo que utilices una aplicación web para ese propósito.

En las guías de seguridad se ve mucho énfasis en los tokens por solicitud, pero no hay una buena razón para ello. Si un atacante puede robar un token CSRF, entonces tiene más de qué preocuparse que CSRF. Es probable que también puedan robar la cookie de sesión, y hacer que su token CSRF por solicitud no ayude con eso.

No hay ningún beneficio de seguridad para el enfoque que Node Connect ha adoptado. Supongo que acaban de leer algunas de estas guías de desarrollo seguro que se basan en tokens por solicitud, encontraron el problema del botón de retroceso y terminaron con una tontería.