安全性 - 没有 XSS 预防，CSRF 预防无用？

Posted 2023-02-19

【中文标题】安全性 - 没有 XSS 预防，CSRF 预防无用？

【英文标题】：Security - CSRF Prevention Useless Without XSS Prevention?

【发布时间】：2019-12-22 09:15:52

【问题描述】：

我正在 AWS 上开发一个无服务器应用程序和一个使用 Svelte.js 和 Sapper 的静态前端。对于用户管理，我使用 AWS Cognito 用户池。 Cognito 在执行身份验证操作时会返回 JWT 令牌，因此这自然会导致在客户端存储这些令牌的位置的问题。

我已经了解了使用 localStorage 与 cookie 的各种优缺点，以及第一个选项如何打开 XSS 漏洞而第二个选项易受 CSRF 攻击。我知道 localStorage 可以很容易地被恶意脚本访问，并且在那里存储 JWT 等敏感信息是有风险的。我也明白使用 HttpOnly 会阻止 javascript 访问 cookie，因此它们应该更能抵御 XSS 攻击。

但在阅读OWASP guide to CSRF prevention 时，我发现了这个有趣的声明：

但是，任何跨站点脚本漏洞都可以用来破坏当今市场上所有可用的 CSRF 缓解技术（除了涉及用户交互的缓解技术，在本备忘单后面描述）... 必须没有 XSS 漏洞存在以确保无法绕过 CSRF 防御。

然而，同一指南中还有另一条声明：

请注意，令牌本身可以缓解 CSRF

这让我很困惑。它是哪一个？用户交互之外的所有 CSRF 预防技术是否都存在漏洞，或者基于令牌的技术是否可以接受？

如果它们无效，并且由于 CSRF 预防依赖于 XSS 预防，这是否意味着将 JWT 存储在 cookie 中提供的安全性几乎不比将它们存储在 localStorage 中？如果我的应用中存在 XSS 漏洞，这是否意味着我设置的任何 CSRF 防御都无效？

如果是这样，那么当我一开始就需要防止 XSS 时，为什么还要麻烦处理 cookie 和防止 CSRF 呢？

有人可以帮忙解释一下这个问题吗？有没有办法正确使用不会暴露于 XSS 攻击的 JWT？同步器模式或加密模式等基于令牌的技术真的有效吗？

谢谢。

【参考方案1】：

我也在尝试了解 Sapper 应用的最佳安全实践。我在这里找到了一些关于使用标题的东西： https://github.com/sveltejs/sapper/issues/880

更一般地说： https://security.stackexchange.com/questions/177155/can-jwt-authentication-act-as-an-anti-csrf-mechanism

CSRF 的更全面的一般分类： https://github.com/pillarjs/understanding-csrf

还有一些更高级的概念在这里链接，通过 Gatsby 讨论： https://github.com/gatsbyjs/gatsby/issues/14741