¿Qué tan frecuente debe ser la actualización de token en la seguridad CSRF?

Para comenzar con los antecedentes, esta publicación es lo que Jeff Atwood dice sobre los tokens CSRF. En esta misma página, continúa diciendo:

Un método de prevención aún más fuerte, aunque más complejo, es aprovechar el estado del servidor para generar (y rastrear, con tiempo de espera) una clave aleatoria única para cada FORMULARIO HTML que envíe al cliente. Utilizamos una variante de este método en Stack Overflow con gran éxito.

Pero en esta publicación, Jeff nunca comenta sobre cuándo y cómo deben actualizarse los tokens.

Estaba usando una técnica similar en una aplicación web en la que estaba trabajando. Funciona así:

1. Siempre que el usuario POSTenvíe datos a mi servidor, se envía un token csrf.
2. Este token CSRF se almacena en una cookie criptográficamente fuerte en la sesión del usuario.
3. Si el token es válido, se procesa la solicitud del usuario y viceversa.
4. Si la solicitud es válida, deseche el token anterior en el lado del servidor y cree un token nuevo. La respuesta del servidor contiene un nuevo token csrf que se utilizará en la próxima solicitud. El token antiguo en todos los formularios de una página se actualiza con el nuevo para que la siguiente solicitud se procese correctamente.

¿Es aconsejable actualizar los tokens después de POSTsolicitarlos o la actualización se debe realizar solo cuando el usuario realiza una GETsolicitud y mantener el mismo token hasta que se realice la siguiente solicitud GET?

El punto principal de un token CSRF es que no puede haber sido enviado desde otro sitio. Por lo tanto, (a) no puede ser predicho o detectado por un atacante, y (b) no se adjunta automáticamente a una solicitud de la misma forma que una cookie.

Entonces, teóricamente, si un token CSRF nunca se divulga a terceros, nuevamente teóricamente, no es necesario que caduque en absoluto. Pero entonces corres el riesgo de que tu ficha se "filtre" de alguna manera. Por lo tanto, su período de vencimiento realmente debería ser lo suficientemente corto como para combatir la posibilidad de que un token salga y se use contra su usuario.

Realmente no hay pautas, pero una buena técnica sólida es generar automáticamente un nuevo token en CADA solicitud que incorpore un código de tiempo firmado, y luego aceptar tokens hasta cierta edad.

Una función de muestra podría ser:

concat(current_time,salt,sha256_sum(concat(salt,userid,current_time,secret_string)))

El token contiene información de sincronización y una sal, pero también contiene una firma que no se puede falsificar y que está vinculada al ID de usuario.

Luego puede definir su propio intervalo de caducidad: una hora, un día, 2 horas. Lo que sea. El intervalo en este caso no está vinculado al token, por lo que puede establecer reglas de caducidad como lo desee.

Sin embargo, como mínimo, los tokens CSRF deberían caducar cuando caduque la sesión de inicio de sesión o cuando el usuario cierre sesión. El usuario no espera que un formulario que haya presentado ANTES de cerrar sesión continúe funcionando DESPUÉS de que vuelva a iniciar sesión.