XHR跨域限制的目的是什么？
我一直想知道XHR跨域限制的目的是什么。
其目的似乎是防止恶意注入的 Javascript 向攻击者发送私有数据。但是，通过注入的 script 或 img 标签（或任何其他与此相关的外部资源）可以轻松地将数据发送到任何域。
I was always wondering what the purpose of the XHR cross domain restrictions is.
It seems the intention is to prevent maliciously injected Javascript from sending private data to the attacker. However, sending data to any domain is easily possible with an injected script or img tag (or any other external resource for that matter).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果任何任意网站都可以对您的网站进行 XHR 调用，则可能会发生以下情况：
事实上，即使采用了跨域策略，Bob 的邪恶网站实际上也可以通过发布表单向您的服务器发送 HTTP 请求。它无法看到结果，但如果 Bob 很聪明，他可能会在您的站点中发现一个 URL，该 URL 允许通过 POST 进行某些活动，即使它不是来自您某个页面上的表单。这就是所谓的跨站点请求伪造，浏览器无法保护您免受这种情况的影响。
If any arbitrary website could make an XHR call to your website, then the following could happen:
As it is, even with the cross-domain policy, Bob's evil website can in fact POST an HTTP request to your server by posting a form. It won't be able to see the results, but if Bob is clever he may have discovered a URL in your site that allows some activity from a POST even if it's not from a form on one of your pages. That's called Cross-Site Request Forgery, and it's something the browser cannot protect you from.
同站点安全策略的设计使得攻击者能够将恶意脚本注入网页，需要满足以下条件之一：
如果您构建的网站仅引用您的网站上的资源如果您拥有自己的域，并且您不会做任何愚蠢的事情，例如接受嵌入在 URL 中的 javascript（或 SQL）或在用户输入文本上使用 javascript eval()，那么您的网页上的数据隐私状况相对良好。
如果您链接到驻留在不同域中的脚本或图像资源，则您网站的安全性也取决于该外部域的安全性。
防范上述#3（中间人攻击）的最佳方法是使用 https 协议而不是 http 来保护对服务器的所有请求（页面、脚本和图像）。中间人无法为目标域生成有效的加密证书，因此浏览器至少可以警告用户该网站存在可疑之处。
同站点安全的经典案例是将目标网页包装在由攻击者的 evil.com 服务器托管的页面上的 iframe 中。如果父页面 URL 和 iframe 内容 URL 在同一个域中，则允许它们相互通信并查看彼此的内部数据、变量、DOM 等。如果域不同，则同域安全策略规定浏览器不应允许 iframe 看到其父级的任何变量或 DOM 信息，也不应允许父级查看 iframe 内部的变量或 DOM。这是为了防止两个域之间意外或不适当的数据交换。
如果缺少同域安全策略，那么攻击者很容易将您的银行网站包装在 iframe 中，引导您通过误导（发送给您的虚假电子邮件上的链接）通过包装登录。网站，并随意观察您的所有银行活动。从那里，他们可以在几秒钟内耗尽你的账户。
另请注意，XHR 最初作为第三方扩展添加到浏览器环境中，因此最好的做法是遵循客户端请求的现有浏览器安全模型。 XHR 遵循与浏览器获取 html 页面、脚本和图像相同的规则。如果 XHR 从一开始就被设计到 HTML 规范中而不是后来添加，那么 XHR 的情况可能会有所不同。请参阅 HTML5 PostMessage 规范 作为示例。
Same-site security policy is designed so that for an attacker to be able to inject malicious script into a web page one of the following is required:
If you build your web site to only reference resources on your own domain, and you don't do anything stupid like accept javascript (or SQL) embedded in the URL or use javascript eval() on user input text, you're in relatively good shape for data privacy on your web page.
If you link to script or image resources that reside on a different domain, the security of your web site is dependent upon the security of that external domain as well.
The best way to protect against #3 above (man in the middle attack) is to secure all requests to your server (for page, script, and images) using https protocol instead of http. The man in the middle cannot produce a valid crypto certificate for the target domain, so the browser can at least warn the user that something is fishy about the site.
The classic case for same-site security is wrapping a target web page in an iframe on a page hosted by the attacker's evil.com server. If the parent page URL and the iframe content URL are on the same domain, then they are allowed to talk to each other and see each other's internal data, variables, DOM, etc. If the domains are different, the same-domain security policy states that the browser should not allow the iframe to see any variables or DOM info of its parent, nor the parent to see the variables or DOM of the iframe interior. This is to prevent unintended or inappropriate exchange of data between the two domains.
If the same-domain security policy were missing, then it would be a very simple matter for an attacker to wrap your bank web site in an iframe, lead you with misdirection (links on false email sent to you) to log in via the wrapped site, and casually observe all your bank activity. From there, they can drain your accounts in a matter of seconds.
Note also that XHR was added to the browser environment as a third party extension initially, so the best course of action was to follow the existing browser security model for client requests. XHR follows the same rules as the browser uses for fetching html pages, script, and images. If XHR were designed into the HTML spec from the start instead of being tacked on later, things might have been different for XHR. See the HTML5 PostMessage spec as an example.
您可以制作一个网站来访问某些导致 DoS 的网站。这是跨 XHR 可能的恶意使用之一。
You can make a web site for accesing some websites causing DoS. It's one of possible malicious using of cross XHR.
查看以下 wiki 文章可能会有所帮助。
http://en.wikipedia.org/wiki/Same_origin_policy
Check the following wiki article it could help.
http://en.wikipedia.org/wiki/Same_origin_policy