跨源资源共享（CORS） - 我在这里缺少什么？ [英] Cross-Origin Resource Sharing (CORS) - am I missing something here?

问题描述

我在阅读关于 CORS 的信息，我认为实施既简单又有效。 / p>

但是，除非我错过了一些东西，我认为规范中缺少一个很大的部分。根据我的理解，外部网站决定，基于请求的原点（并且可选地包括凭证），是否允许访问其资源。这很好。

但是，如果页面上的恶意代码想要将用户的敏感信息发布到外国站点怎么办？外地站点显然要认证请求。因此，再次，如果我没有错过一些东西，CORS实际上使得更容易窃取敏感信息。

我认为如果原始网站可以还提供其页面被允许访问的服务器的不可变列表。

因此，展开的顺序是：

1. 可接受的CORS服务器（abc.com，xyz.com等）


2. 页面想要向abc.com发出XHR请求 - 浏览器允许这样做，因为它位于允许列表中，正常


3. 网页要向恶意网址发出XHR请求 - 由于服务器不在列表中，请求被本地拒绝（即由浏览器拒绝）。

我知道恶意代码仍然可以使用JSONP来完成其肮脏的工作，但我认为CORS的完整实现将意味着脚本标记多网站漏洞。

我也检出了官方的CORS规范（ http://www.w3.org/TR/cors ），但找不到此问题的任何提示。

解决方案

但是，如果页面上的恶意代码要将用户的敏感信息发布到外国站点呢？

那么呢？你可以没有CORS。甚至回到Netscape 2，你总是能够通过简单的接口导致的简单GET和POST请求传递信息到任何第三方网站 form.submit（）， new Image 或设置 window.location 。

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

发出XHR请求到恶意网站 - 请求本地拒绝

为什么一个网页试图向一个网站发出XHR请求尚未列入白名单？

如果您试图防范由于XSS漏洞而注入的恶意脚本的行为，您正在尝试修复该症状，而不是原因。

I was reading about CORS and I think the implementation is both simple and effective.

However, unless I'm missing something, I think there's a big part missing from the spec. As I understand, it's the foreign site that decides, based on the origin of the request (and optionally including credentials), whether to allow access to its resources. This is fine.

But what if malicious code on the page wants to POST a user's sensitive information to a foreign site? The foreign site is obviously going to authenticate the request. Hence, again if I'm not missing something, CORS actually makes it easier to steal sensitive information.

I think it would have made much more sense if the original site could also supply an immutable list of servers its page is allowed to access.

So the expanded sequence would be:

1. Supply a page with list of acceptable CORS servers (abc.com, xyz.com, etc)
2. Page wants to make an XHR request to abc.com - the browser allows this because it's in the allowed list and authentication proceeds as normal
3. Page wants to make an XHR request to malicious.com - request rejected locally (ie by the browser) because the server is not in the list.

I know that malicious code could still use JSONP to do its dirty work, but I would have thought that a complete implementation of CORS would imply the closing of the script tag multi-site loophole.

I also checked out the official CORS spec (http://www.w3.org/TR/cors) and could not find any mention of this issue.

解决方案

But what if malicious code on the page wants to POST a user's sensitive information to a foreign site?

What about it? You can already do that without CORS. Even back as far as Netscape 2, you have always been able to transfer information to any third-party site through simple GET and POST requests caused by interfaces as simple as form.submit(), new Image or setting window.location.

If malicious code has access to sensitive information, you have already totally lost.

3) Page wants to make an XHR request to malicious.com - request rejected locally

Why would a page try to make an XHR request to a site it has not already whitelisted?

If you are trying to protect against the actions of malicious script injected due to XSS vulnerabilities, you are attempting to fix the symptom, not the cause.

这篇关于跨源资源共享（CORS） - 我在这里缺少什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！