跨源资源共享（CORS） - 我在这里错过了什么？

我读的是关于CORS，我认为这个实现既简单又有效。跨源资源共享（CORS） - 我在这里错过了什么？

但是，除非我错过了某些东西，否则我认为规范中缺少很大一部分内容。据我了解，外国网站根据请求的来源（可选择包括凭证）决定是否允许访问其资源。这可以。

但是如果页面上的恶意代码想要将用户的敏感信息发布到外部网站会怎么样？国外网站显然会验证请求。因此，如果我没有错过任何东西，CORS实际上可以更容易地窃取敏感信息。

我认为如果原始网站也可以提供其页面允许访问的不可变列表的服务器，它会更有意义。

所以扩展顺序将是：

供应与可接受CORS服务器列表的页面（abc.com，xyz.com等）
页希望让一个XHR请求为abc。 com - 浏览器允许这样做，因为它在允许列表中，并且认证正常进行
Page想要向恶意网站发出XHR请求 - 请求在本地（即通过浏览器）拒绝请求，因为服务器不在列表中。

我知道，恶意代码仍然可以使用JSONP来完成其肮脏的工作，但我想不到的是，CORS的完整实现将意味着脚本标签多站点漏洞闭幕。

我也检查出了官方的CORS规范（http://www.w3.org/TR/cors），并没有发现任何提及这个问题。

来源

2010-03-28 David Semeria

在我看来，CORS纯粹是在扩大可能性，并试图安全地做到这一点。我认为这显然是一个保守的举动。在其他标签（脚本/图像）上制定更严格的跨域策略，同时更安全，会破坏大量现有代码，并使采用新技术变得更加困难。希望能做些什么来弥补这个安全漏洞，但我认为他们需要确保首先进行简单的转换。

来源

2010-03-28 13:45:21

我的主要观点并不是关闭当前的漏洞，而是出现了（至少对我而言）是CORS规范中的一个大漏洞。 – 2010-03-28 14:20:52

但是如果网页上的恶意代码想要将用户的敏感信息发布到外国网站会怎么样？

怎么样？你可以在没有CORS的情况下做到这一点。甚至回到Netscape 2，您始终可以通过简单的GET和POST请求将信息传输到任何第三方站点，这些请求由接口造成，如form.submit(),new Image或设置window.location。

如果恶意代码可以访问敏感信息，那么您已经完全丢失了。

3）页希望让一个XHR请求malicious.com - 请求本地

为什么一个页面试图使XHR请求，它尚未列入白名单的网站被拒绝？

如果你想防止恶意脚本由于注入XSS漏洞的行动，你正试图解决症状，而不是原因。

来源

2010-03-28 14:41:00 bobince

同意 - 但确实需要使受损页面难以将信息写入未列入白名单的位置。我不认为它在处理效果而不是原因。一个好的银行保险库仍然会设法让劫匪很难拿到钱，即使他们确实设法击败一级保安并首先进入保险库。 – 2010-03-28 16:20:53

无效安全措施比没有安全措施更差。 – bobince 2010-03-28 17:03:35

“一个好的银行保险库仍然会试图让劫匪很难拿到钱，即使他们确实设法击败了第一级安全” 即使最好的银行保险库也不会安装，因为例如，一个钢铁屏障，知道小偷唯一要做的就是走过障碍。正如bobince所说，一旦你有XSS漏洞，你已经完全失去了。 – greim 2010-05-12 18:25:22

我分享David的担忧。安全性必须逐层构建，并且源服务器提供的白名单似乎是一种好方法。

另外，这个白名单可以用来关闭存在的漏洞（表单，脚本标签，等...），它是安全的假设，服务白名单的服务器是为了避免后面的兼容性问题。

来源

2010-05-06 11:13:19

不幸的是，CSRF漏洞被纳入了网络的基础架构。现在没有改变它。即使它*可能被改变，它也不应该被改变。是的，有安全问题，但安全并不是事物宏伟计划中唯一的考虑因素。 – greim 2010-05-12 18:40:13

您的担忧是完全有效的。

然而，更令人担忧的是，有不需要的任何恶意目前该代码被利用的事实。有许多基于DOM的跨站点脚本漏洞可以让攻击者利用您描述的问题并将恶意JavaScript插入易受攻击的网页。这个问题不仅仅是可以发送数据的地方，而是可以从中接收数据的地方。

我说起这家位于这里更详细：

来源

2012-04-15 20:43:55

我也查了官方CORS spec，但没有找到这个问题的任何提及。

没错。 CORS规范正在解决一个完全不同的问题。你错误地认为它会让问题变得更糟 - 它使问题不会变得更好或更糟，因为一旦恶意脚本在你的页面上运行，它就可以在任何地方发送数据。

好消息，不过，是有是一个widely-implemented规范，解决了这个问题：Content-Security-Policy。它允许您指示浏览器对您的页面可以执行的操作进行限制。

例如，你可以告诉浏览器不要执行任何内嵌脚本，这将立即打败许多XSS攻击。或者，如您在此请求的那样，您可以明确告诉浏览器哪些域允许该页面联系。

来源

2017-01-19 06:53:39

问题不在于一个网站可以访问其已有权访问的其他网站资源。问题是域名之一 - 如果我在我的公司使用浏览器，并且ajax脚本恶意决定试用10.0.0.1（可能是我的网关），它可能有访问权限，因为请求现在来自我的电脑（可能是10.0.0.2）。

所以解决方案 - CORS。我不是说它是最好的，但解决了这个问题。

1）如果网关无法返回'bobthehacker.com'接受的原始标题，请求被浏览器拒绝。这处理旧的或无准备的服务器。

2）如果网关只允许从myinternaldomain.com域项，它会拒绝的“bobthehacker.com”的原点。在SIMPLE CORS情况下，它实际上仍会返回结果。默认;你可以配置服务器甚至不这样做。然后结果被丢弃，而不被浏览器加载。 3）最后，即使它接受某些域名，也可以控制接受和拒绝的标题，以使来自这些站点的请求符合特定的形状。

注 - ORIGIN和OPTIONS标头由请求者控制 - 显然有人创建自己的HTTP请求可以在其中放置任何他们想要的东西。然而，现代CORS兼容浏览器WONT可以做到这一点。它是控制交互的浏览器。浏览器阻止bobthehacker.com访问网关。这是你失踪的部分。

来源

2017-02-02 17:23:55

跨源资源共享（CORS） - 我在这里错过了什么？

回答

相关问题