这里的攻击向量是令牌的泄露。防御并不特别关注该令牌的公开方式，而是解决攻击者可能获得该值的任何方法。如果攻击者可以获得令牌，那么他们就有可能进行 CSRF 攻击。同样，具体的攻击方法本身并不是这里的关注点。

更改代币的目的是限制机会之窗。您可以每月更改一次 CSRF 令牌，也可以在每次请求时更改。每次会话都更改它是一个很好的中间立场，可以避免令牌更改过快带来的一些并发症，但仍然提供良好的曝光限制。结束会话也是状态的自然转换，因此这也是更改 CSRF 令牌的好地方。

限制您对 CSRF 的整体接触可以降低每次会话更改 CSRF 令牌的重要性。一些方法是：

• 将令牌作为 HTTP 标头而不是表单值传递。
• 在更新数据或启动事务时正确使用 POST 与 GET 请求。
• 使用 SameSite cookie 属性、Secure 属性和 __Host- 或 __Secure- cookie 前缀来帮助防止 cookie 暴露信息或被覆盖。
• 使用 Origin 和 Referer HTTP 标头来验证请求是否来自预期位置。
• 提供额外的交互步骤，例如确认页面，甚至对最敏感的操作进行重新身份验证。

决定何时更新 CSRF 令牌取决于您的整体风险和对 CSRF 攻击的总体抵抗力。借助良好的纵深防御策略，您可能会在更改该令牌的频率上做出妥协。

您的服务器在注销时不需要对同步器令牌执行任何操作。它只需要在每次登录时生成一个新令牌。

Syncrhronizer Token 起作用的明显条件是：攻击者必须不知道受害者的 CSRF Token。否则，令牌变得毫无意义，因为攻击者可以简单地将令牌作为恶意请求的一部分提交。

如果您不在每个新会话（即登录时）上重新生成令牌，攻击者可以通过两种方式获取它：

1. CSRF 令牌固定。与会话固定相关的概念。想象一下，攻击者设法将自己的会话 ID 和 CSRF 令牌注入受害者的浏览器，然后受害者执行登录。假设您的服务器通过重新生成会话 ID 来缓解会话固定，但不重新生成 CSRF 令牌。攻击者已经拥有受害者的 CSRF 令牌，尽管没有他的会话 ID，并且现在可以执行 CSRF 攻击。

2. 算法猜测。如果 CSRF Token 永远不会为用户改变，它本质上就会永久地与用户绑定。猜测是时间问题（蛮力），特别是如果攻击者弄清楚所使用的算法和/或参数。在每次登录时重新生成令牌会使任何暴力攻击窗口变得更小。