问题描述
设置/上下文
我在 Vue.Js 中有一个 SPA，有一个 Node 服务器作为后端。 我还有一个辅助应用程序，.net core web API。 当用户前往 SPA 时，他被迫通过外部身份提供者登录。会话在登录后创建并实际存储在 Web API（以 cookie 的形式）上，而不是 Vue.Js。这意味着 SPA 没有上下文，如果他已登录，除了调用 API 以查看他是否已登录。 我意识到这有点奇怪，但我们实际上并不想在节点服务器上管理会话，所以我们选择了这种方法。
CSRF
我想防范 CSRF 攻击。据我所知，我看到了两种防止这种情况的方法。
-
Cookie 上的 SameSite 属性 这不仅仅作为防御机制值得信赖，因为人们通常不相信 API 会遵守 GET/POST 最佳实践，但如果实施得当并且 SPA 和 API 共享域，则应该足够了。
-
反 CSRF 代币 这个想法是让你的非 GET 请求独一无二，这样它们就不能被伪造。意见不同，但如果它们至少是每个用户每个会话唯一的，它已经增加了好处（而不是每个请求唯一，这在 SPA 中还有其他缺点）
我上面的假设是否正确？
在我的设置中添加 Anti-CSRF 令牌是否可能且有用？
由于登录过程使用外部身份提供者（使用 OAUTH），浏览器最终将登陆 API 回调 URL，该 URL 将响应 HTTP 302 重定向到带有会话 cookie 的 SPA 主页。通常CSRF令牌存储在正文中，这是不可能的，因为我们对另一个站点进行了302。 所以，我可以： a) 在 url 中返回 CSRF 令牌，这通常是不好的，因为您不应该在 url 中放置敏感信息，因为它可能会在某个地方的日志记录中暴露出来。 b) 返回另一个带有 CSRF 令牌的 cookie，而不是使其成为 HTTP-ONLY。这允许 SPA 从 cookie 中检索值，然后将该值发送到 XHR 标头/正文以添加为 CSRF 保护。
我的问题是，在选项 b) 中，是否添加了任何内容？由于我暂时公开 CSRF 值，我不确定这是否会被滥用，或者我是否被迫在此设置中仅依赖 SameSite cookie。
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）