使用跨域XMLHttpRequest有哪些安全风险？
我在很多地方看到人们谈论跨域 XMLHttpRequest，但由于某些安全原因，这是不可能的。但是，我还没有找到说明这些安全原因实际上是什么的帖子？
人们提到 JSONP 是很好的替代方案之一。另一种选择是使用 Origin 和 Access-Control-Allow-Origin 标头。
但是，我只是想知道跨域使用XMLHttpRequest会带来哪些安全问题？
In many places I've seen people have talked about the Cross-Domain XMLHttpRequest, which is not possible, due to some security reasons. However, I haven't found a post indicating what those security reasons actually are?
People have mentioned that JSONP is one of the good alternatives. Another alternative would be to use Origin and Access-Control-Allow-Origin headers.
However, I just want to know what security problems can be raised due to cross-domain XMLHttpRequest usage?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为最好回答你的问题，举个例子来说明为什么它会非常糟糕。
您访问我的网站 (example.org)。我加载一个脚本，该脚本向 facebook.com/messages/from/yourgirlfriend 发出客户端 AJAX 请求。你碰巧登录了Facebook，你的浏览器告诉Facebook我的请求实际上是你。 Facebook 很高兴地满足了我的请求，即关于你想尝试的奇怪的性事物的信息。我现在知道了关于你的事情，你可能不想让我知道。
这当然是一种夸张的说法，而且幸运的是，由于同源政策，这是不可能的。
你现在不觉得更安全了吗？
I think it would be best to answer your question of an example of WHY it would be horrendously bad.
You go to my website (example.org). I load a script that makes a client-side AJAX request to facebook.com/messages/from/yourgirlfriend. You happened to be logged in to facebook, and your browser tells Facebook that my request is actually you. Facebook happily gives my request that message about the strange sexual things you want to try. I now know things about you you probably didn't want me to know.
This, of course is a wild exaggeration, and thankfully not possible thanks to the same origin policy.
Don't you feel safer now?
如果没有这些“安全原因”，您所知道的整个互联网就不可能存在。事实上，我会大胆地说，对于互联网安全来说，没有什么规则比同源策略更重要了。
如果没有这些规则，任何网页都无法进行身份验证，谷歌，网络邮件帐户，所以，这些都不可能存在。这就好像每个域都存在 XSS。您可以针对 gmail.com 执行 XHR 并读取任何人的电子邮件。 CSRF 令牌不起作用，因为您可以读取任何页面并伪造请求。
没有单一的同源策略，但 Google 浏览器安全性中明确列出了规则手册。这些非常符合逻辑，而且各个平台的规则也非常相似，因为这是互联网必须运作的方式。
通过执行
Access-Control-Allow-Origin: *，您将放弃网络浏览器授予您的该页面的权利。这具有重大安全隐患。您将无法使用令牌来保护自己免受 CSRF 的侵害。 capthca 可以缓解这个问题，检查引用也可能有帮助（如果来源是 HTTPS，它将为空）。您应该阅读CSRF 预防备忘单。Without these "security reasons" the entire Internet as you know it could not exist. In fact i will go out on a limb and say there is no rule that is more important for Internet security than the same-origin policy.
No web page could have authentication without these rules, google, web mail accounts, SO, none of this could exist. It would be as if you had XSS on every domain. You could perform an XHR against gmail.com and read anyone's email. CSRF tokens wouldn't work because you could read any page and forge the request.
There is no single same-origin policy, but the rules are clearly laid out in the Google Browser Security handbook. These are very logical, and rules for the various platforms are very similar, because this is way the Internet must work.
By doing a
Access-Control-Allow-Origin: *you are forfeiting your rights granted to you by web browsers for that page. This has major security implications. You will not be able to protect your self from CSRF using tokens. A capthca could mitigate this problem, also checking the referer might also help(it will be blank if the origin is HTTPS). You should read the CSRF prevention cheat sheet.如果允许，设法将 Javascript 注入您的页面（通过利用/社会工程）的攻击者可以发送从您的客户那里获取的数据（通常是敏感的），而他们不知道（因为 XMLHttpRequest 不需要用户操作）他们沉默了）。这是一种浏览器安全措施。
JSONP 只是围绕此安全措施的一种解决方案，您可以向目的地提供回调，并委托他们通过此回调返回给您的任何内容。
编辑：
安全风险的示例：您通过网络（例如 gmail 或 yahoo）登录您的电子邮件帐户。您继续浏览（在另一个选项卡中甚至在当前选项卡中）另一个恶意站点。此恶意网站尝试对您的电子邮件帐户的同一网站执行 XHR。由于 XHR 取决于您的行为，并且由于它是客户端/浏览器端请求，因此该请求将具有您用于登录的相同会话，因此，该网站可以对您的帐户执行任何他们想要的操作（通过发送垃圾邮件）您的帐户、下载您的联系人等）。
另一个例子：在论坛中，有人设法将带有 XHR 的 Javascript 注入到另一个网站。他现在可以从论坛中访问他的帖子的所有人员那里窃取联系人列表（然后可能将其删除）（通过使用网络电子邮件的同一会话）。更不用说他可以分享论坛成员访问他的帖子的会话，以获取他们在论坛中拥有的任何数据（私人消息/朋友等）。然后他可以将这些数据发送到他的服务器来保存。
If it was allowed, an attacker who manage to inject Javascript into your page (through exploit/social-engineering) can send data (usually sensitive) which are acquired from your clients without them knowing (since XMLHttpRequests don't require user actions to occur and they are silent). It is a browser security measure.
JSONP is just a work around this security measure, where you give the destination a callback and entrust them with whatever they will give you back through this callback.
EDIT:
Examples of a security risk: you login to your email account through the web (like gmail or yahoo). You carry on browsing (in another tab or even in the current tab) to another malicious site. This malicious site try to do XHR to the same website of your email account. Since the XHR is on your behave, and since it is client/browser-side request, this request will have the same session you used to login, and therefore, this website can do whatever they want with your account (send a spam mail through your account, download your contacts, ...etc).
Another example: In a forum, someone manage to inject Javascript with XHR to another website. He now can steal the contacts list (and maybe then delete them) from all the people who visit his post in the forum (by using the same session of your web email). Not to mention that he can share the session of the members of the forum visiting his post to get whatever data they have in the forum (private messages/friends..etc). He can then send these data to his server to save them.