为什么 XMLHttpRequest 的同源策略
为什么浏览器对 XMLHttpRequest 应用同源策略？这对于开发人员来说确实很不方便，但看起来它在实际阻止黑客方面几乎没有什么作用。 有一些解决方法，它们仍然可以包含来自外部来源的 javascript（JSONP 背后的力量）。
这似乎是一个在很大程度上相互关联的网络中过时的“功能”。
Why do browsers apply the same origin policy to XMLHttpRequest? It's really inconvenient for developers, but it appears it does little in actually stopping hackers.
There are workarounds, they can still include javascript from outside sources (the power behind JSONP).
It seems like an outdated "feature" in a web that's largely interlinked.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
因为 XMLHttpRequest 传递用户的身份验证令牌。如果用户使用基本身份验证或一些cookie登录到example.com，然后访问attacker.com，则后一个站点可以创建一个到example.com的XMLHttpRequest，并对该用户进行完全授权，并读取该用户可以访问的任何私人页面（然后将其转发回攻击者）。
由于在 web 应用程序页面中放置秘密令牌是阻止简单的跨站点请求伪造攻击的方法，因此这意味着attacker.com 可以执行用户在 example.com 上可以执行的任何页面操作，而无需获得用户的任何同意或交互。 Global XMLHttpRequest 是全局跨站点脚本。
（即使您有一个未通过身份验证的 XMLHttpRequest 版本，仍然存在问题。例如，攻击者可以向 Intranet 上的其他非公共计算机发出请求，并读取可以从这些计算机下载的任何文件，而这些文件可能无法从这些计算机上下载。供公众使用的
Because an XMLHttpRequest passes the user's authentication tokens. If the user were logged onto example.com with basic auth or some cookies, then visited attacker.com, the latter site could create an XMLHttpRequest to example.com with full authorisation for that user and read any private page that the user could (then forward it back to the attacker).
Because putting secret tokens in webapp pages is the way to stop simple Cross-Site-Request-Forgery attacks, this means attacker.com could take any on-page actions the user could at example.com without any consent or interaction from them. Global XMLHttpRequest is global cross-site-scripting.
(Even if you had a version of XMLHttpRequest that didn't pass authentication, there are still problems. For example an attacker could make requests out to other non-public machines on your intranet and read any files it can download from them which may not be meant for public consumption.
<script>tags already suffer from a limited form of this kind of vulnerability, but the fully-readable responses of XMLHttpRequest would leak all kinds of files instead of a few unfortunately-crafted ones that can parse as JavaScript.)