【问题标题】:What is the purpose of the XHR cross domain restrictions?XHR 跨域限制的目的是什么?
【发布时间】:2011-07-06 13:34:21
【问题描述】:

我一直想知道 XHR 跨域限制的目的是什么。

其目的似乎是防止恶意注入的 Javascript 向攻击者发送私人数据。但是,使用注入的scriptimg 标签(或任何其他外部资源)很容易将数据发送到任何域。

【问题讨论】:

    标签: javascript security cross-domain xmlhttprequest


    【解决方案1】:

    如果任意网站可以对您的网站进行 XHR 调用,则可能会发生以下情况:

    1. 无辜用户 Alice 登录您的安全网站并获取安全会话 cookie。
    2. 在另一个浏览器选项卡中,Alice 访问了 Bob 的邪恶黑客网站(她认为这只是 Justin Bieber 的视频)
    3. Bob 的页面向您的安全网站发出 XHR。如果没有跨域策略,浏览器会向您的网站发出请求(包括安全会话 cookie)并检索结果。这些结果可能包括 Alice 登录到您的安全网站时可用的任何内容。

    事实上,即使使用跨域策略,Bob 的邪恶网站实际上也可以通过发布表单向您的服务器发布 HTTP 请求。它不会看到结果,但如果 Bob 很聪明,他可能会在您的站点中发现一个 URL,该 URL 允许来自 POST 的某些活动,即使它不是来自您的一个页面上的表单。这就是所谓的跨站点请求伪造,这是浏览器无法保护您免受攻击的东西。

    【讨论】:

    • 不包含cookie不是更好的解决方案吗?这将避免需要像 JSONP 这样的 hack。我能看到的唯一问题是基于 IP 的“安全性”(例如在家庭路由器中)。
    • 在 XHR 请求上阻止会话 cookie 将意味着具有登录用户的网页(存储在会话 cookie 中的身份验证令牌)无法通过 XHR 与 Web 服务器通信,因为每个 XHR 请求都会被缺少通常由浏览器作为会话 cookie 附加到请求上的身份验证令牌信息。您可以在不使用 cookie 的情况下将身份验证信息嵌入 XHR 请求中,但您必须编写代码将其嵌入客户端并编写代码将其提取到服务器上。此外,cookie 只是跨站点访问问题的一个方面。有关更多信息,请参阅我的答案。
    【解决方案2】:

    设计同站点安全策略是为了让攻击者能够将恶意脚本注入网页,需要满足以下条件之一:

    1. 网页引用驻留在网页域之外的脚本或图像资源,攻击者可以控制这些外部资源之一。
    2. 攻击者可以访问网页的宿主网络服务器
    3. 或者攻击者控制了 Web 服务器和浏览器客户端之间路由上的机器(用于不安全的 http 连接)

    如果您将网站构建为仅引用您自己域中的资源,并且您不做任何愚蠢的事情,例如接受嵌入在 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 spec 为例。

    【讨论】:

      【解决方案3】:

      您可以创建一个网站来访问一些导致 DoS 的网站。这是交叉 XHR 的一种可能的恶意使用。

      【讨论】:

      • 您可以通过随机获取参数包含来自其他网站的数百张不可见图像来做到这一点。
      【解决方案4】:

      查看以下 wiki 文章,它可能会有所帮助。

      http://en.wikipedia.org/wiki/Same_origin_policy

      【讨论】:

      • 文章列出了规避限制的方法。这些变通方法让我想知道这个单一安全措施的目的。这就像在门和其他窗户大开的情况下堵住房子的一扇窗户。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2012-11-08
      • 2012-10-18
      • 2014-10-19
      • 2011-01-02
      • 1970-01-01
      • 2013-05-14
      • 2013-10-29
      相关资源
      最近更新 更多