AJAX跨域安全性的基本原理是什么？

Question

考虑到编写跨域提取数据的服务器端代理的简单性，我不知道初始意图是阻止客户端AJAX跨域调用。 我不是要求猜测，我正在寻找语言设计者（或与他们关系密切的人）的文档，因为他们认为他们正在做的事情，而不仅仅是为开发人员带来轻微的不便。

TIA

Answer 1

这是为了防止浏览器充当反向代理 。 假设您正在办公室的PC上浏览http://www.evil.com ，并假设该办公室在http://intranet.company.com上存在一个包含敏感信息的内部网，该网站只能从本地网络访问。 如果跨域策略不存在，www.evil.com可以使用您的浏览器作为反向代理向http://intranet.company.com发出ajax请求 ，并将该信息发送到www.evil.com Ajax请求。

这是我猜的限制原因之一。

Answer 2

此限制的最重要原因是安全问题：JSON请求是否应该使浏览器服务并接受cookie或安全凭证并请求到另一个域？ 它与服务器端代理无关，因为它无法直接访问客户端环境。 有一个提议安全清理JSON特定的请求方法 ，但它还没有在任何地方实现。

Answer 3

如果您是myblog.com的作者并且您向facebook.com发送了XHR，那么请求是否会发送您的facebook cookie凭据？ 不，这意味着您可以从您的博客请求用户的私人Facebook信息。

如果您创建代理服务来执行此操作，则您的代理无法访问Facebook Cookie。

您可能也在质疑为什么JSONP没问题。 原因是你正在加载你没写的脚本，所以除非facebook的脚本决定从他们的JS代码发送信息，否则你将无法访问它

Answer 4

直接访问和代理之间的区别是cookie和其他与安全相关的标识/验证信息，这些信息绝对限于一个来源。

有了这些，您的浏览器就可以访问敏感数据。 您的代理不会，因为它不知道用户的登录数据。

因此，代理仅适用于公共数据; 就像CORS一样 。

Answer 5

我知道你要求专家的答案，我只是一个新手，这是我的意见，为什么服务器端代理不是一个正确的最终解决方案：

• 构建服务器端代理并不像根本不构建它那么容易。
• 并不总是像在第三方JS小部件中那样 。 您不会要求所有发布者声明用于集成窗口小部件的DNS注册表。 并修改其页面的document.domain与附带问题。
• 正如我在“ 第三方Javascript ”一书中所读到的那样， 它“需要加载一个中间隧道文件才能进行跨域请求” 。 至少你把JSONP放在游戏中更加棘手的杂耍。
• IE8也不支持，也来自上面的书： “IE8有一个相当奇怪的错误，即使它们都选择加入公共域名称空间时，也会阻止顶级域名与其子域名进行通信” 。
• 有人在其他答案中解释了几个安全问题，甚至比他们更多，您可以查看章节4.3.2使用上述书籍的子域代理进行消息交换 。

对我来说最重要的是：

• 这是一个黑客......就像JSONP解决方案一样，它是时候建立一个标准，可靠，安全，干净和舒适的解决方案。

但是，在重新阅读你的问题之后，我想我仍然没有回答它，那么为什么这个AJAX安全呢？ 我想，答案是：

因为您不希望您访问的任何网页能够从您的桌面拨打任何计算机或服务器到您办公室的内部网