ASP.NET Core 防伪令牌可在多个选项卡上工作？

Question

我最近将我们的应用程序迁移到 .NET 8，并且我正在尝试让我们之前工作的防伪令牌发挥作用。大部分都工作正常。

但是，每当打开多个浏览器选项卡时，我们就会开始收到验证错误，表明防伪令牌无效。我在 Microsoft 文档中发现了这个简介，指出每当您打开新选项卡时，同步器模式都会使防伪令牌失效。如果这造成问题，它会建议考虑替代的 CSRF 保护模式。

但是，它没有演示文档中的其他模式！

在我看来，用户使用多个浏览器选项卡现在很常见，那么还有哪些其他模式呢？在他们展示的每种情况下，您本质上都是在创建一个令牌，将其发送到 JavaScript 并在请求中将其发送回来......防伪令牌还可能有什么其他模式？我不明白。

https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-8.0#antiforgery-in-aspnet-core

Answer 1

经过更多搜索，解决方案似乎是根本不使用 AntiForgery 令牌，而是使用完全不同的模式。 OWASP 的 CSRF 备忘单中列出了一些方法，尽管只有另一种方法没有受到关注。该方法就是此处描述的签名双重提交 Cookie 方法，我将继续采用该方法。

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

替代方案：使用双重提交 Cookie 模式¶ 服务器上 CSRF 令牌的状态有问题，您可以使用 另一种技术称为双重提交 Cookie 模式。这 技术易于实现并且是无状态的。有不同的 实现此技术的方法，其中朴素模式是最常见的 常用的变体。

签名双重提交 Cookie（推荐）¶ 最安全 双重提交 Cookie 模式的实现是 Signed Double-Submit Cookie，它使用只有本人知道的密钥 服务器。这确保攻击者无法创建和注入他们的 将自己的、已知的 CSRF 令牌放入受害者的经过身份验证的会话中。这 系统的令牌应通过散列或加密来保护。

我们强烈建议您使用基于哈希的消息 身份验证 (HMAC) 算法，因为它的计算量较小 比加密和解密 cookie 更密集。你也应该 将 CSRF 令牌与用户当前会话进一步绑定 增强安全性。

使用 HMAC CSRF 令牌¶ 生成 HMAC CSRF 令牌（带有 会话相关的用户值），系统必须具有：

随每个登录会话而变化的会话相关值。这 值应该只对所有经过身份验证的用户有效 会议。避免使用静态值，例如用户的电子邮件或 ID，因为 它们不安全 (1 | 2 | 3)。值得注意的是，更新 CSRF 令牌太频繁（例如对于每个请求）是 误解认为它增加了实质性的安全性，而实际上 损害用户体验（1）。例如，您可以选择以下之一 以下与会话相关的值： 服务器端会话 ID （例如 PHP 或 ASP.NET）。 JWT 中的随机值（例如 UUID） 每次创建 JWT 时都会发生变化。秘密加密密钥 不 与幼稚实现中的随机值混淆。这 值用于生成 HMAC 哈希值。理想情况下，将此密钥存储为 环境变量。用于防碰撞目的的随机值。 生成一个随机值（最好是加密随机的） 确保同一秒内的连续调用不会产生 相同的哈希 (1)。