cookies - 使用会话的带有 API 的 CSRF SPA

Question

设置/上下文

我在 Vue.Js 中有一个 SPA，并以 Node 服务器作为后端。我还有一个辅助应用程序，.net core web API。当用户访问 SPA 时，他被迫通过外部身份提供者登录。会话在登录后创建并实际存储在 Web API 上（以 cookie 的形式），而不是 Vue.Js。这意味着如果他已登录，则 SPA 没有上下文，除了调用 API 以查看他是否已登录。我意识到这有点奇怪，但我们实际上并不想在节点服务器上管理会话，所以我们选择这种方法。

CSRF

我想防止 CSRF 攻击。据我发现，我已经看到了两种防止这种情况的方法。

1. Cookie 上的 SameSite 属性 这不仅仅作为防御机制被信任，因为人们通常不相信 API 会遵守 GET/POST 最佳实践，但如果实施得当并且如果 SPA 和 API 共享一个域，应该就足够了。

2. 反 CSRF 令牌 这个想法是使您的非 GET 请求是唯一的，因此它们不能被伪造。意见不同，但如果它们至少在每个用户的每个会话中是唯一的，它已经增加了好处（与每个请求的唯一性相反，这在 SPA 中还有其他缺点）

我上面的假设是否正确？

在我的设置中添加反 CSRF 令牌是否可能且有用？

由于登录过程使用外部身份提供者（使用 OAUTH），浏览器最终将登陆 API 回调 url，该 URL 将响应 HTTP 302 重定向到带有会话 cookie 的 SPA 主页。通常 CSRF 令牌存储在正文中，这是不可能的，因为我们对另一个站点执行 302。所以我可以： a) 在 url 中返回 CSRF 令牌，这通常很糟糕，因为您不应该将敏感信息放在 url 中，因为它可能会在某处登录时暴露。b) 返回另一个带有 CSRF-token 的 cookie，而不是 HTTP-ONLY。这允许 SPA 从 cookie 中检索值，然后将值发送到 XHR 标头/正文以添加为 CSRF 保护。

我的问题是，在选项 b) 中，这会增加什么吗？由于我暂时公开了 CSRF 值，我不确定这是否会被滥用，或者我是否被迫在此设置中仅依赖 SameSite cookie。

标签： cookiessingle-page-applicationsession-cookiescsrfcsrf-token