代码之家 › 专栏 › 技术社区 › James Watkins

当存在类似JSONP和CORS的解决方案时,为什么浏览器具有同源策略?

xss cors jsonp security ajax

James Watkins · 技术社区 · 11 年前

这个问题类似于: Why same origin policy for XMLHttpRequest

然而,这个答案并不令人满意,因为它没有解决存在变通办法的事实(如问题中所述)。答案只解决了与XMLHttpRequest直接相关的安全问题,但JSONP(可能还有CORS,不确定)仍然存在这些问题。所以问题仍然存在——当有类似JSONP的解决方案时,为什么要有严格的同源策略,这可能会更糟(因为它是可执行的而不是静态内容)?

下面是一个示例: Company.com希望对一些未受保护的资源进行AJAX调用,例如用于数据查找的简单公共API。Company.com意识到这可能是不安全的,因此他们会仔细清理数据,以确保没有有趣的业务。然而,XMLHttpRequest不允许这样做,因此Company.com必须使用JSONP,但这将阻止数据清理,并可能导致攻击者将任意Javascript注入页面。这是一个更好的解决方案吗?

另一个例子: Company.com有一个漏洞,攻击者可以将Javascript注入到某个用户可以查看的页面中(这种情况有很多种可能发生;这可能是最常见的网站攻击)。有了严格的同源策略,攻击者可以整天乱翻网页,但他不能“打电话回家”,这是一个重要的细节,因为这意味着所有数据都是安全的。但JSONP(和图像标签)通过允许攻击者从页面中抓取所有个人数据并将其发送到任何地方来打破这一点。即使使用CORS,这仍然是现实,因为我可以告诉我的恶意服务器允许来自任何域的入站XS请求。

换句话说,在什么情况下,锁定的XMLHttpRequest实际上提供了更高的安全性?

1 回复 | 直到 9 年前

SilverlightFox 11 年前

你的前提是错误的。同源策略没有提到网页包含外部域资源的能力。它阻止了通过脚本直接访问由不同的Origin拥有的资源,而他们没有选择加入。

因此,CORS和JSONP不是同源策略的变通方法。CORS使Origin能够选择响应XHR请求,而JSONP只是一个允许外部引用向页面返回动态数据的黑客。

这里的重点是保护您的页面,以便 XSS 一开始是不可能的。要做到这一点,重点应该放在 correctly encoding text that is output to the page 。这将防止“打电话回家”,因为一开始就不可能发生攻击。A. Content Security Policy 可以帮助中和任何试图漏网的脚本。在您的网站上定期进行安全漏洞评估时,应该会发现未编码的输出-将CSP视为填补了发现和修复这些漏洞之间的空白,尽管 browser support 还没有完全实现,尤其是Internet Explorer。

然而,XMLHttpRequest不允许这样做,因此Company.com必须使用JSONP,但这将阻止数据清理,并可能导致攻击者将任意Javascript注入页面。这是一个更好的解决方案吗?

事实并非如此。CORS是更好的解决方案,因为请求检索数据而不是可执行代码。CORS允许XMLHttpRequest这样做。

带有CORS响应标头 Access-Control-Allow-Origin 的网站所有者 example.com 可以将此设置为

Access-Control-Allow-Origin: https://company.com

仅允许 company.com 客户端通过用户的浏览器通过HTTPS访问数据。

在该CORS场景中, 示例.com 信任 company.com公司 仅针对该特定请求的数据响应。与 Access-Control-Allow-Credentials 他们可以选择在浏览器上向用户请求任何授权cookie,并将请求与响应一起发送 company.com公司 .

在JSONP场景中, company.com公司 会让人信任 示例.com 具有 他们的全部起源 。这意味着他们信任 示例.com 使用整个客户端站点安全模型。 Example.com 可以做任何它想做的事 company.com公司 的网站。所以如果 示例.com 被黑客破坏,他们也可以控制 company.com公司 每个用户访问包含 <script src="https//example.com/ 标签

换句话说,在什么情况下,锁定的XMLHttpRequest实际上提供了更高的安全性?

互联网上的任何地方。

假设您已登录Gmail。为了论证,假设Gmail有一个AJAX方法来获取收件箱内容:

https://gmail.com/services/inbox/get_conversations

现在,你在网上冲浪,然后登陆我的网站, evil.com .

Evil.com 包含一些JavaScript以向其发出POST请求 https://gmail.com/services/inbox/get_conversations ,它将从 gmail.com 返回到 gmail.com 当您登录时。

位于的服务 https://gmail.com/services/inbox/get_conversations 将尽职尽责地返回收件箱的内容。

在没有同源策略锁定的情况下, evilv.com网站 将能够读取此响应中的数据。i、 e.任何网站都可以阅读您的电子邮件。使用同源策略,数据将返回到浏览器,但客户端脚本无法从 gmail.com (当然还有CORS允许的任何其他来源)。例如,在这种情况下,Google可能允许以下内容:

Access-Control-Allow-Origin: https://google.com

_{注:以上所有内容都是我为了举例说明而编的,并没有反映出谷歌和Gmail是如何做到这一点的。原则上是一样的。}