注销后的 CSRF 令牌生命周期
CSRF Token lifecycle after Logout
在玩 Spring security 时，我想知道 CSRF（跨站点请求伪造）令牌生命周期在应用程序注销时的方法。
假设用户登录并浏览我的网站。然后他注销。我是否应该使 CSRF 令牌无效（如果重要的话，在我的情况下作为 cookie 实现）？
如果不是，在安全方面我应该注意什么？
如果是，我应该如何管理用户对应用程序的任何进一步操作？如果没有任何 CSRF Token，服务器端将禁止某些操作。那我应该生成一个新的令牌吗？
我在服务器端使用 Spring boot，它似乎默认使令牌无效（或者我做错了导致此结果...）
感谢您的帮助。
正在登录
为了防止伪造登录请求，登录表单也应防止 CSRF 攻击。由于 CsrfToken 存储在 HttpSession 中，这意味着将立即创建一个 HttpSession。虽然这在 RESTful / 无状态架构中听起来很糟糕，但现实是状态对于实现实际安全性是必要的。没有状态，如果令牌被泄露，我们将无能为力。实际上，CSRF 令牌的大小非常小，对我们的架构影响可以忽略不计。
注销
添加 CSRF 会将 LogoutFilter 更新为仅使用 HTTP POST。这确保注销需要 CSRF 令牌，并且恶意用户无法强制注销您的用户。
一种方法是使用表单注销。如果你真的想要 link，你可以使用 JavaScript 让 link 执行 POST（即可能在隐藏表单上）。对于禁用 JavaScript 的浏览器，您可以选择让 link 将用户带到将执行 POST.
的注销确认页面
查看此 link 了解更多信息：Csrf protection
你还可以看到 csrf timeout
我假设你在谈论 Double Submit Cookies CSRF prevention method。
如果不是，那么这不是一个安全的解决方案 - 有关一些针对 CSRF 的保护方法，请参阅 Why is it common to put CSRF prevention tokens in cookies?
是的，您应该在注销和登录时刷新 CSRF 令牌。请注意，并非每个站点都需要防范登录 CSRF。 See this answer 如果您需要这样做。
登录时不刷新 CSRF 令牌的（非常低的）风险是，如果另一个用户使用相同的浏览器登录，则原始用户知道 CSRF 令牌，并且如果他们引诱新用户，则可以自己使用 CSRF 攻击用户关注恶意 link。当然，如果第一个用户可以控制浏览器或操作系统，他们可以简单地在机器本身上安装一些东西来做到这一点。然而，如果第二个用户在使用前彻底检查机器，那么这种类型的 CSRF 攻击将无法检测到（尽管如果用户如此警惕，那么他们在登录时不会点击任何收到的 links）。 =13=]
简而言之，如果您正在实施 CSRF 保护，那么您也可以正确地执行此操作并在登录和注销时刷新令牌。
在玩 Spring security 时，我想知道 CSRF（跨站点请求伪造）令牌生命周期在应用程序注销时的方法。
假设用户登录并浏览我的网站。然后他注销。我是否应该使 CSRF 令牌无效（如果重要的话，在我的情况下作为 cookie 实现）？
如果不是，在安全方面我应该注意什么？
如果是，我应该如何管理用户对应用程序的任何进一步操作？如果没有任何 CSRF Token，服务器端将禁止某些操作。那我应该生成一个新的令牌吗？
我在服务器端使用 Spring boot，它似乎默认使令牌无效（或者我做错了导致此结果...）
感谢您的帮助。
正在登录
为了防止伪造登录请求，登录表单也应防止 CSRF 攻击。由于 CsrfToken 存储在 HttpSession 中，这意味着将立即创建一个 HttpSession。虽然这在 RESTful / 无状态架构中听起来很糟糕，但现实是状态对于实现实际安全性是必要的。没有状态，如果令牌被泄露，我们将无能为力。实际上，CSRF 令牌的大小非常小，对我们的架构影响可以忽略不计。
注销
添加 CSRF 会将 LogoutFilter 更新为仅使用 HTTP POST。这确保注销需要 CSRF 令牌，并且恶意用户无法强制注销您的用户。
一种方法是使用表单注销。如果你真的想要 link，你可以使用 JavaScript 让 link 执行 POST（即可能在隐藏表单上）。对于禁用 JavaScript 的浏览器，您可以选择让 link 将用户带到将执行 POST.
的注销确认页面查看此 link 了解更多信息：Csrf protection 你还可以看到 csrf timeout
我假设你在谈论 Double Submit Cookies CSRF prevention method。
如果不是，那么这不是一个安全的解决方案 - 有关一些针对 CSRF 的保护方法，请参阅 Why is it common to put CSRF prevention tokens in cookies?
是的，您应该在注销和登录时刷新 CSRF 令牌。请注意，并非每个站点都需要防范登录 CSRF。 See this answer 如果您需要这样做。
登录时不刷新 CSRF 令牌的（非常低的）风险是，如果另一个用户使用相同的浏览器登录，则原始用户知道 CSRF 令牌，并且如果他们引诱新用户，则可以自己使用 CSRF 攻击用户关注恶意 link。当然，如果第一个用户可以控制浏览器或操作系统，他们可以简单地在机器本身上安装一些东西来做到这一点。然而，如果第二个用户在使用前彻底检查机器，那么这种类型的 CSRF 攻击将无法检测到（尽管如果用户如此警惕，那么他们在登录时不会点击任何收到的 links）。 =13=]
简而言之，如果您正在实施 CSRF 保护，那么您也可以正确地执行此操作并在登录和注销时刷新令牌。