AJAX 跨域安全背后的基本原理是什么?

What is the rationale behind AJAX cross-domain security?

本文关键字：是什么 安全 背后 AJAX      更新时间：2023-09-26

鉴于编写跨域获取数据的服务器端代理的简单性，我不知道阻止客户端 AJAX 跨域调用的最初意图是什么。 我不是在要求猜测，我是在从语言设计师（或与他们关系密切的人）那里寻找他们认为他们在做什么的文档，而不仅仅是给开发人员带来轻微的不便。

蒂亚

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

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

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

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

您可能还会质疑为什么 JSONP 可以。原因是您正在加载一个不是您编写的脚本，因此除非Facebook的脚本决定向您发送来自其JS代码的信息，否则您将无法访问它

此限制的最重要原因是安全问题：JSON 请求是否应该使浏览器提供服务并接受 cookie 或安全凭据以及向另一个域的请求？这不是服务器端代理的问题，因为它不能直接访问客户端环境。有一个关于安全清理 JSON 特定请求方法的建议，但尚未在任何地方实施。

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

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

因此，代理仅适用于公共数据;CORS 也是如此。

我知道

你在问专家的答案，我只是一个新手，这是我对为什么服务器端代理不是一个合适的最终解决方案的看法：

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

对我来说最重要的是：

  • 这是一个黑客......就像JSONP解决方案一样，是时候采用标准，可靠，安全，清洁和舒适的解决方案了。

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

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

相关文章：