CSRF expira antes del formulario enviado

Hay absolutamente preocupaciones de seguridad con esto; de lo contrario, el tiempo de espera de la sesión sería inútil en primer lugar.

Dicho esto, puede haber buenas razones para deshabilitar los tiempos de espera de sesión, pero en este caso, puede y debe hacerlo de manera explícita, y con plena consideración de todas las consecuencias.

Para agregar a la solución: si bien creo que ya es cuestionable tener un solo formulario en una sola página web que tarde tanto en completarse sin ahorrar, con el riesgo de perder todo el trabajo cuando algo sale mal. (gran problema de usabilidad), creo que lo que desea lograr es prolongar la sesión (y, por lo tanto, la validez del token csrf) realizando una solicitud ajax cada vez que el usuario aún esté activo . Por lo tanto, debe supervisar si se modificaron algunos campos de formulario (por ejemplo, en los últimos 5 minutos), y solo entonces iniciar la solicitud ajax.

No es necesario establecer un tiempo de caducidad independiente para el token CSRF, el token debe ser único y válido para la sesión del usuario actual, cuando la sesión del usuario expirará, el token csrf expira junto con la sesión, y luego debes generar un nuevo token. Esta podría ser una solución simple.

Consulte la respuesta de Nicolai Ehemann para obtener una respuesta más general. Esta respuesta asume que el token se está actualizando sin alargar la sesión.

No veo ningún problema con esto. En realidad, es lo mismo que restablecer el token cuando el usuario vuelve a cargar la página. Suponiendo que está usando https e implementando correctamente la solicitud de ajax y la generación de token, un atacante aún no debería saber qué es el token de usuario.

Se aplican los mismos riesgos que cuando se genera normalmente un token CSRF sin ajax, porque para el navegador, básicamente está haciendo el mismo trabajo.