跨源资源共享(CORS) - 我在这里遗漏了什么？

我正在阅读有关CORS的内容,我认为实施既简单又有效.

但是,除非我遗漏了什么,否则我认为该规范中缺少一大部分内容.据我了解,根据请求的来源(以及可选地包括凭证)决定是否允许访问其资源,是外国站点.这可以.

但是,如果页面上的恶意代码想要将用户的敏感信息发布到外部站点,该怎么办？外国站点显然将验证请求.因此,如果我没有遗漏某些东西,CORS实际上会更容易窃取敏感信息.

我认为如果原始网站还可以提供其页面允许访问的不可变服务器列表,那将更有意义.

所以扩展的序列将是:

提供包含可接受的CORS服务器列表的页面(abc.com,xyz.com等)

页面想要向abc.com发出XHR请求 - 浏览器允许这样做,因为它在允许列表中并且身份验证正常进行

Page想要向malicious.com发出XHR请求 - 请求在本地(即浏览器)拒绝,因为服务器不在列表中.

我知道恶意代码仍然可以使用JSONP来完成其脏工作,但我认为CORS的完整实现意味着关闭脚本标记多站点漏洞.

我还检查了官方的CORS规范(http://www.w3.org/TR/cors),但没有找到任何关于这个问题的提及.

1> bobince..：

---

但是,如果页面上的恶意代码想要将用户的敏感信息发布到外部站点,该怎么办？

怎么样？你可以在没有CORS的情况下做到这一点.即使追溯到网景2,你一直能够通过所造成的那么简单,界面简单GET和POST请求传送信息给任何第三方网站form.submit(),new Image或设置window.location.

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

3)Page想要向malicious.com发出XHR请求 - 请求在本地拒绝

为什么页面会尝试向尚未列入白名单的网站发出XHR请求？

如果您正在尝试防止因XSS漏洞而注入的恶意脚本的操作,那么您正在尝试修复症状,而不是原因.

---

无效的安全措施比没有安全措施更糟糕.

---

"一个好的银行金库仍会试图让劫匪很难把钱拿出来,即使他们确实设法击败了一级保安"即使是最好的银行金库也不会费心去安装,例如,钢铁屏障,知道小偷唯一要做的就是走在障碍物周围.正如鲍勃所说,一旦你有一个XSS漏洞,你已经完全失败了.