¿Es válido defender un token CSRF contra la reproducción (por ejemplo, con una marca de tiempo)?

Si el token CSRF puede ser interceptado, la cookie de sesión también puede ser interceptada, por lo que CSRF no sería la preocupación inmediata en ese escenario.

Algunas implementaciones de token CSRF tienen vencimientos temporizados, pero esto es una precaución adicional y no es estrictamente necesario. Esta respuesta de tylerl sugiere que una caducidad es una buena precaución en caso de que el token se filtre de alguna manera, pero el vencimiento del token CSRF cuando finaliza la sesión está bien.

En un ataque CSRF, el atacante tiene la capacidad de enviar cualquier formulario de datos que desee de su sesión, pero no puede modificar sus cookies. Para que un token CSRF sea efectivo, debería ser imposible para el atacante saber su valor. Si el atacante explota una vulnerabilidad para obtener tokens CSRF, querrá asegurarse de que los tokens CSRF ya no sean válidos una vez que se solucione la vulnerabilidad. Siempre y cuando la cookie del token haya caducado cuando la sesión expire, todo está bien (siempre que las sesiones caduquen si sospechas que se han filtrado).

A partir de la documentación que vincula, me parece que en realidad está usando Encrypted Token Pattern , que combina una cookie de envío doble con un token de sincronizador.

Hemos tenido esta discusión con muchos clientes a lo largo de los años. La solución más válida para la protección de CSRF es una en la que el servidor rastrea qué 'página' se envió al cliente, luego solo acepta datos válidos de la página que recibió el servicio, solo del cliente para el que recibió la notificación.

Ha pasado un tiempo desde que he estado en el lado de la programación con MS, pero @AntiForgeryToken debería cambiar con cada solicitud y validarse en cada página que recibe datos.

Suena como si la aplicación solo generara el token una vez, y nunca más. Echa un vistazo a este blog para más detalles. enlace