CSRF 客户端双重提交令牌生成

CSRF client side double submission token generation

提问人：Bram Vanbilsen 提问时间：11/8/2023 最后编辑：Gabor LengyelBram Vanbilsen 更新时间：11/9/2023 访问量：47

问：

我正在研究保护网站免受 CSRF 攻击。尽管敏感 cookie 已经标记了 ，但我仍然想实现 CSRF 令牌。更具体地说，双重提交模式。我读到这些令牌也可以在客户端生成。这是正确的吗？我正在考虑采取以下方法：same-site=lax

  1. 用户在网站上并发出请求
  2. 客户端生成一个随机令牌，该令牌被添加到将发送到服务器的 cookie 中
  3. 客户端将此令牌添加到名为“x-csrf-token”的请求标头中。
  4. 服务器将 cookie 中的令牌与请求标头中的令牌进行比较。

是否应该为每个请求生成这些令牌？或者，我是否可以只生成一个令牌，并在用户每次再次访问时刷新该令牌？

这是否是针对 CSRF 攻击的良好保护措施？攻击者无法为我的特定域设置 cookie，因此无法自行生成令牌的假设是否正确？

JavaScript 安全 Cookie http-headers csrf

评论

答：

1赞 Gabor Lengyel 11/8/2023 #1

这完全是正确的，是的。

如果为每个请求生成一个新令牌，则将遇到争用条件，因为设置 cookie 需要浏览器花费一些时间，并且一个 cookie 在任何给定时间都可以有一个值。太快的请求将发送错误的 cookie 值。

通常，为每个用户会话（登录）生成一个令牌就足够了。

此外，如今 SameSite 越来越被接受为针对 CSRF 的唯一保护措施。在您的用例中，它可能足够，也可能不够，这主要取决于您可能想要服务的潜在客户（哪些浏览器），即。您的合法用户将使用什么，因为这是攻击者想要在 CSRF 情况下利用的会话。如果您想要额外的保护，双重提交是一个合理的解决方案。

0赞 Juraj Martinka 11/9/2023 #2

在服务器端执行此操作更安全，特别是如果您想防止子域劫持。 然后，您可以对双重提交令牌进行加密签名，以将其绑定到会话 Cookie。

我建议阅读 API Security in Action 的第 4.4.2 节。 相关代码可以在这里找到：

评论

0赞 Bram Vanbilsen 11/9/2023
我不明白为什么会这样。只要生成的令牌在加密上是随机的，安全级别就应该看起来是相同的。如果我是对的，cookie 不会在子域之间共享（除非专门配置为这样做）。我浏览了提供的代码，谢谢！但我仍然不太确定安全性的好处。你能详细说明一下吗？

上一个：有什么正当理由为什么 gem omniauth-rails_csrf_protection 只兼容 Rails 4.2+ 吗？

下一个：为什么期望：100 在 2 中继续标头拆分响应