我最近在登录页面和CSRF令牌方面遇到了一个有趣的问题。我想确保使用CSRF令牌保护登录表单POST，但是，当用户长时间留在登录页面上时，他/她的会话将过期并且CRSF令牌将失效。关于如何避免此问题的任何建议？我正在考虑不对登录页面使用 CRSF 令牌，但这似乎是一种不好的做法。
从技术上讲，登录页面是一个会话外页面(用户尚未登录(，因此实际上不需要CSRF缓解。 如果用户没有建立会话，黑客就无能为力。 我猜他可以诱使用户登录 - 如果他知道用户名和密码 - 但如果可以这样做，他可以从自己的浏览器登录。
如果您坚持在登录页面上使用 CSRF 令牌，我建议您像往常一样呈现令牌，并在令牌到期前几秒钟使用 Javascript 计时器 (setTimeout( 刷新页面。
基百科关于CSRF的页面提到，一种称为登录CSRF的特殊类别的CSRF是可能的。我引用页面本身
攻击者可能会伪造请求以将受害者登录到目标 使用攻击者凭据的网站;这称为登录 CSRF。 登录CSRF使各种新颖的攻击成为可能;例如，一个 攻击者稍后可以使用其合法凭据登录该站点 并查看已保存的私人信息，例如活动历史记录 在帐户中。该攻击已针对YouTube进行了演示。
此外，一个非常流行的Java MVC框架(Spring MVC(在其最近的版本中添加了使用CSRF令牌的内置CSRF保护，他们也建议使用登录表单进行CSRF保护。我再次引用这里
为了防止伪造登录请求登录表单 也应该受到保护，免受CSRF攻击。由于CsrfToken是 存储在 HttpSession 中，这意味着将创建一个 HttpSession 马上。虽然这在 RESTful/无状态中听起来很糟糕 架构 现实是状态是实现所必需的 实用的安全性。没有国家，我们无能为力，如果 令牌已泄露。实际上，CSRF代币相当 体积小，对我们的架构的影响可以忽略不计。
在考虑 CSRF 保护方法时，您应该查看加密令牌模式。它在设计上是无状态的，只需要一个令牌，而不是比较两个令牌的同步器令牌或双重提交 Cookie 模式。
就登录页面上令牌过期的问题而言，您可以利用称为 ARMOR 的框架来防范 CSRF。我不会担心 CSRF 方面的登录页面，因为您通常不会在此阶段为用户提供更改状态的选项，这就是 CSRF 的全部内容。在您的情况下，可能值得考虑在用户登录后注入令牌。
此外，官方的OWASP备忘单是一个很好的参考点。