我正在读关于CORS https://developer.mozilla.org/en/HTTP_access_control我认为实施既简单又有效。
然而，除非我遗漏了什么，否则我认为规范中遗漏了很大一部分。据我了解，外国站点根据请求的来源（以及可选的包括凭据）决定是否允许访问其资源。这可以。
但是，如果页面上的恶意代码想要将用户的敏感信息发布到国外站点怎么办？外国网站显然会验证该请求。因此，如果我没有遗漏什么的话，CORS 实际上使窃取敏感信息变得更容易。
我认为，如果原始站点还可以提供允许其页面访问的不可变服务器列表，那就更有意义了。
所以扩展的序列将是：
- 提供包含可接受的 CORS 服务器列表的页面（abc.com、xyz.com 等）
- 页面想要向 abc.com 发出 XHR 请求 - 浏览器允许这样做，因为它位于允许列表中并且身份验证正常进行
- Page 想要向 Malware.com 发出 XHR 请求 - 请求在本地被拒绝（即被浏览器拒绝），因为服务器不在列表中。
我知道恶意代码仍然可以使用 JSONP 来完成其肮脏的工作，但我本以为 CORS 的完整实现将意味着脚本标记多站点漏洞的关闭。
我还查看了官方 CORS 规范（http://www.w3.org/TR/cors http://www.w3.org/TR/cors）并且找不到任何提及此问题的信息。
但是，如果页面上的恶意代码想要将用户的敏感信息发布到国外站点怎么办？
那又怎样呢？无需 CORS，您已经可以做到这一点。即使早在 Netscape 2 中，您就始终能够通过简单的 GET 和 POST 请求将信息传输到任何第三方站点，这些请求的接口非常简单：form.submit(), new Image或设置window.location.
如果恶意代码能够访问敏感信息，那么您就已经彻底失败了。
3）页面想要向malicious.com发出XHR请求 - 请求在本地被拒绝
为什么页面会尝试向尚未列入白名单的网站发出 XHR 请求？
如果您试图防止由于 XSS 漏洞而注入的恶意脚本的操作，那么您只是在尝试修复症状，而不是修复原因。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
