为什么要将刷新令牌存储在仅 HTTP 的 cookie 中以防止 CSRF 攻击？

Question

我刚刚读了一篇文章

https://hasura . io/blog/best-of-practices-of-use-jwt-with-graph QL/

总之，他们建议将JWT Access Token存储在内存中（例如在JavaScript中作为变量），并在HTTP-唯一Cookie中刷新Token。

他们说：

但是，通过通过刷新令牌间接地保持会话，我们防止了JWT令牌可能存在的直接CSRF漏洞。

但是它是否将刷新令牌存储在仅限HTTP的cookie中，仍然容易受到CSRF攻击？例如，evilsite.com可以向 /refreshtokenendpoint发出请求以获取新的JWT访问令牌。我对仅限HTTP的cookie的理解是，cookie不能从JavaScript中读取，但每当发出HTTP请求时，它就会自动发送，就像evilsite.com一样。（如果我错了，请纠正我）。

Answer 1

如果谨慎使用，刷新cookie中的令牌和内存中的访问令牌可能是一个很好的模型。希望在BFF-TMI等标准中提供一些更好的指导。

cookie应该具有这些属性，而SameSite属性意味着evilsite不能发送它，因此从CSRF的角度来看它是好的。

• 仅HTTP
• 安全
• AES256加密
• 同一个站点=严格

OWASP的CSRF指南似乎建议同时使用SameSite和CSRF令牌作为首选选项。

出于兴趣，下面是我目前如何在一个SPA代码示例中实现一些东西——如果借鉴以下内容有用的话:

• 水疗授权代码
• 后端 API OAuth 代码

随着这方面指导的发展，我可能会改变我的想法。

高安全选项？

目前的共识是，在安全方面，以下选项是首选的，尽管我希望风险和缓解措施在未来一年得到更好的记录：

• 将访问令牌完全排除在浏览器之外
• 通过“后端对前端”代理所有API调用
• 看看这段2021的视频吧

然而，这个选项可能会在某些领域增加复杂性，也可能限制某些场景中的功能。

与安全性通常的情况一样，需要权衡其他因素，选择的解决方案可能取决于数据敏感性和利益相关者关心的内容。