javascript - cookie 是否可以保护 token 免受 XSS 攻击？

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

5年前关闭。




Improve this question




我正在为基于浏览器的 Javascript Web 应用程序构建基于 JWT(JSON Web token )的身份验证机制，使用无状态服务器(没有用户 session !)，我想一劳永逸地知道，如果使用存储我在 cookie 中的 JWT token 将保护我的 token 免受 XSS 攻击，或者如果没有保护，那么在我的 Javascript 应用程序中使用浏览器本地存储没有真正的优势。
我在 SO 和许多博客中看到过这个问题的提问和回答，但我从未见过真正让我满意的答案。

这个问题最初是在征求意见的基础上提出的 - 考虑到我原来的措辞，这是正确的。所以让我在这里和现在清楚地表明，我不想要基于开发人员懒惰等模糊概念的意见 - 这就是基本规则旨在消除的。我想要的是一个有证据支持的是/否答案。任何一个:

“是的，可以保护 cookie 免受 XSS 和 CSRF 的侵害，方法如下”或

“不，通过保护您的 cookie 免受 CSRF 的影响，您总是将它们暴露在同一种 XSS 攻击面前，这使 cookie 成为一个好主意”

所以我将重述这个问题，使用一些简化的基本规则，并提前指出漏洞，以便您，专家，可以让我直截了当。
基本原则

您的应用程序是一个 javascript 浏览器应用程序 - 它可能使用 AngularJS，但也可能是定制的。它通过 REST 调用与服务器通信。比方说，jQuery $ajax 调用。

服务器是无状态的:没有 session 管理。

应用程序使用 JWT 作为主要身份验证 token (OAuth2 中的“访问 token ”)并使用 secret 签名 key 在服务器上验证它们

忽略 cookie 的其他重要优势:浏览器管理、编码不良的机会较少等。对于这场战斗，我想考虑绝对安全性，并假设我们可以胜任编码任何一种机制。

忽略 cookie 的其他缺点，例如非浏览器应用程序等。在这场战斗中，我们只关注基于浏览器的 javascript 应用程序。

在非 cookie 方法中使用 header 还是请求正文来传输 token 并不重要；使用本地存储还是 session 存储也无关紧要 - 忽略那里的任何安全差异。是的，我知道从技术上讲 Cookie 使用 header ，请忽略它。

简而言之，我们只对比较 browser-handles-tokens 与 your-javascript-handles-tokens 以及比较 XSS 和 CSRF 安全风险感兴趣。

参赛者
在红色 Angular 落， Auth0 :本地存储优于 Cookie，因为 XSS 比 CSRF 更容易修复
在蓝色 Angular 落， Stormpath : Cookies 胜过头文件，因为实际上 CSRF 比 XSS 更容易修复。
(下面详细摘录了两个论点)
选择的武器
XSS 和 CSRF(我们将交替使用 CSRF 和 XSRF:C 似乎在文档中更受欢迎，X 在代码中更受欢迎)
这是我对攻击类型的 super 简化摘要:
假设您的无状态、经过 JWT 身份验证的 javascript 浏览器应用程序用于网上银行，而攻击者“Evil Corp”想要提交一个 AJAX REST 调用，通过冒充您的用户将资金转移到他们的帐户。
XSS(跨站脚本)
(正如 Stormpath 指出的，有很多攻击媒介——我会选择一个)
Evil Corp 购买了用于密码输入的漂亮文本字段小部件的 github 帐户权限。他们知道您的银行网站使用它，因此当您输入密码并按回车键时，他们会更新它以提交 AJAX 请求以将资金转移到他们的帐户。您的构建系统愚蠢地提取更新并投入生产。
CSRF(跨站请求伪造)
Evil Corp 知道您的银行站点使用 cookie 中的 JWT 来验证交易，因此他们编写了一个 Web 应用程序，提交 AJAX 请求以将资金转移到他们的帐户。他们在自己的 evil.com 站点上托管此内容，并在您碰巧在另一个选项卡中登录到您的银行站点时，通过电子邮件(网络钓鱼)或其他方式将您引诱到那里。浏览器提交了来自 evil.com 的请求，但附加了您的 JWT，因为它会转到正确的站点:银行。
标准防御
防御 XSS 的方法是对您站点中的代码非常小心，这样您就不会让浏览器处理用户输入的内容而不对其进行清理(删除 javascript 和 html)以及所有 3rd 方库(Evil 的文本字段小部件)使用前经过审查。正如 Stormpath 正确指出的那样，这很难，几乎是不可能的。
针对 CSRF 的防御是使用双重提交 cookie 的形式。这意味着我们的服务器创建一个 token (安全的随机字符串)并将它发送到我们的 Javascript 浏览器应用程序中的可读 cookie(按照惯例称之为“XSRF-TOKEN”)，我们的 Javascript 将它发送回每个请求的 header 或正文中.
实际上，double-sumbit-cookie 只是对 CSRF 的一种防御，但其他一些需要有状态的服务器 session ，没有其他(我认为!)提供更好的保护。也可以通过将 token 放入 JWT 并在服务器端将其与 header 或正文中的 token 进行比较来实现无状态。
但是这种防御的真正 CSRF 破坏质量是同源策略意味着只有我们的应用程序从我们的域加载的 javascript 才能读取该 cookie。因此，即使 evilcorp.com 上的 javascript 可以随其请求发送我们的 cookie，它也无法嵌入我们的 XSRF-TOKEN，因为它首先无法读取它。
要真正简化 CSRF:

CSRF 攻击有效，因为附加 cookie 的浏览器仅取决于请求的目的地。

CSRF 防御之所以起作用，是因为 Javascript 对 cookie 的访问取决于 Javascript 的来源。

Auth0 的论点

It's easier to deal with XSS than XSRF Cookies have this feature thatallows setting an HttpOnly flag from server side so they can only beaccessed on the server and not from JavaScript. This is useful becauseit protects the content of that cookie to be accessed by injectedclient-side code (XSS). Since tokens are stored in local/sessionstorage or a client side cookie, they are open to an XSS attackgetting the attacker access to the token. This is a valid concern, andfor that reason you should keep your tokens expiration low.

But if youthink about the attack surface on cookies, one of the main ones isXSRF. The reality is that XSRF is one of the most misunderstoodattacks, and the average developer, might not even understand therisk, so lots of applications lack anti-XSRF mechanism. However,everybody understands what injection is. Put simply, if you allowinput on your website and then render that without escaping it, youare open to XSS. So based on our experience, it is easier to protectagainst XSS than protecting against XSRF. Adding to that, anti-XSRF isnot built-in on every web framework. XSS on the other hand is easy toprevent by using the escape syntax available by default on mosttemplate engines.https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies#xss-xsrf

Stormpath的论点

Stormpath recommends that you store your JWT in cookies for webapplications, because of the additional security they provide, and thesimplicity of protecting against CSRF with modern web frameworks.HTML5 Web Storage is vulnerable to XSS, has a larger attack surfacearea, and can impact all application users on a successful attack.https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

还:

I see a lot of discussions where cookies are pitted against accesstokens. While we’ve all been burned by systems that store a session IDin a cookie, and that cookie is not secured and thus gets stolen. Thatsucks, but its not a reason to use tokens. Its a reason to avoidnon-secure, non-https cookies.https://stormpath.com/blog/token-auth-spa/

我的看法
Stormpath 支持 cookie 的论点非常有说服力，但其中有一个漏洞，我没有看到他们清楚地说明:

双重提交 CSRF 防御依赖于这样一个事实，即我的 CSRF 攻击者无法访问我的 cookie:其中包含 XSRF-TOKEN 的 cookie。但是，在 XSS 攻击中，该 cookie 不是和本地存储一样容易受到攻击吗？

XSS 漏洞利用可以在我的域上运行 javascript，因此它可以读取与我的 javascript 相同的 cookie。 (浏览器不知道它不是我的 Javascript)
从另一方面来看:本地存储受到同源策略的保护，就像可读的 cookie 一样。如果我使用 Auth0 方法，并且 XSS 攻击者知道如何在本地存储中找到我的 JWT 并使用它。同一个攻击者不能使用同一个 XSS 脚本来获取我的 XSRF-TOKEN cookie 并使用它吗？
这两种攻击都要求他们阅读和理解我的 javascript 应用程序，但这在他们的浏览器中。
那么有什么区别呢？一个真的比另一个更安全吗，为什么？

Answer 1

放弃所有希望，除非你能抵御 XSS!
或者
根据其他标准选择适合您的方法，因为两者同样安全，同样不安全。

如果您使用 cookie，您绝对应该使用双重提交 cookie 防御或类似的东西，因为它确实可以在没有 XSS 的情况下保护您免受 CSRF 的侵害。也就是说，如果你不这样做，你肯定会受到 CSRF 攻击——来自其他域——甚至不需要 XSS 漏洞利用的工作。
但无论哪种方式，您的源代码都是公开可用的(浏览器中的 JavaScript)，因此对于有动力的黑客来说，查找从本地存储中提取哪个 token 和读取您的 XSRF-TOKEN cookie 之间的努力没有显着差异。如果 Evil Corp 可以让一些 JavaScript 在您的域中运行——那就是 XSS——那么你就完蛋了。
您可能需要考虑的非安全相关标准供您选择:

Cookie 很方便，因为您不必编写 JavaScript 代码来管理 token ——只需编写 XSRF。

如果您想使用它，重定向也会变得更加自动化。

本地存储更容易适应非浏览器应用程序——从服务器的 Angular 来看，也就是说，因为如果你写一个不想处理 cookie 的 Java 安卓应用程序，你的服务器不需要做任何区分in 和浏览器之间，因为它不使用 cookie。

无论如何，请自行决定，但要小心您编写的 JavaScript 和您使用的第 3 方 JavaScript!