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或安全凭证并请求到另一个域？它与服务器端代理无关，因为它无法直接访问客户端环境。有a proposal for safe sanitized JSON-specific request methods，但它还没有在任何地方实现。

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页面。
• 正如我在书中所读到的那样Third Party Javascript “它需要加载一个中间隧道文件才能进行跨域请求”。至少你把JSONP放在了比赛中更棘手的杂耍。
• IE8也不支持，也来自上面的书：“IE8有一个相当奇怪的错误，阻止顶级域名与其子域名进行通信，即使他们都选择加入公共域命名空间”
• 人们在其他答案中解释了几个安全问题，甚至比他们更多，您可以查看上述书中 4.3.2使用子域代理的消息交换
一章。

对我来说最重要的是：

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

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

因为您不希望您访问的任何网页能够将从桌面调用任何计算机或服务器进入您办公室的内部网< /强>