为了账号安全,请及时绑定邮箱和手机立即绑定

为什么跨域Ajax是安全问题?

/ 猿问

为什么跨域Ajax是安全问题?

白衣非少年 2019-11-27 11:19:27

为什么决定使用XMLHTTPRequest进行XML调用不应该跨域边界进行调用?您可以检索JavaScript,图像,CSS,iframe以及我可以想到的来自其他域的几乎所有其他内容。为什么不允许Ajax HTTP请求跨越域边界?考虑到我可以看到它被滥用的唯一方法,这似乎是一个奇怪的限制,那就是如果有人要向页面中注入Javascript。但是,在这种情况下,您只需在文档中添加一个img,脚本或iframe元素即可获取该文件以请求第三方URL并将其发送到服务器。


[编辑]


一些答案指出了以下原因,让我们指出了它们没有创建不允许这样做的主要原因的原因。


XSRF(跨站点请求伪造,也称为CSRF,XSRF)

您可以完全不使用XSRF进行攻击。通常,根本不使用XMLHTTPRequest,只是因为很难以与所有主要浏览器兼容的方式创建XMLHTTPRequest。如果希望他们加载URL,只需在URL上添加一个img标记就容易得多。


发布到第三方网站

<script type="text/javascript">

  $.post("http://some-bank.com/transfer-money.php", 

         { amount: "10000", to_account: "xxxx" })

</script>

可以完成


<body onload="document.getElementById('InvisbleForm').submit()"

    <div style="display:none">

        <form id="InvisbleForm" action="http://some-bank.com/transfer-money.php" method="POST">

            <input type="hidden" name="amount" value="10000">

            <input type="hidden" name="to_account" value="xxxxx">

        </form>

    </div>

</body>

JPunyon:为什么要将该漏洞保留为新功能

您不会再造成任何不安全感。您只是给想要以某种方式使用它的开发人员带来不便。任何想将此功能用于邪恶(又称“真棒”)的人都可以使用其他方法来实现。


结论

我将bobince的答案标记为正确,因为他指出了关键问题。因为XMLHTTPRequest允许您使用凭据(cookie)将其发布到目标站点,并读取从站点发送回的数据以及发送人员凭据,所以您可以编排一些javascript,这些javascript可以提交一系列表单,包括确认表单,并附有为防止XSRF而生成的随机密钥。这样,您就可以像银行一样浏览目标站点,而银行的网络服务器将无法断定,不仅仅是提交所有这些表格的普通用户。


查看完整描述

3 回答

?
阿波罗的战车

为什么不允许Ajax HTTP请求跨越域边界。


因为AJAX请求是(a)使用用户凭据提交的,并且(b)允许调用方读取返回的数据。


这些因素的组合可能导致漏洞。有建议添加一种省略用户凭据的跨域AJAX形式。


您只需将img,脚本或iframe元素添加到文档中


这些方法均不允许调用者读取返回的数据。


(除非脚本经过故意设置以允许这种情况,允许的跨域脚本编写,或者有人进行了可怕的模仿)。


您可以完全不使用XSS进行攻击。发布到第三方网站


这不是XSS攻击。这是跨站点请求伪造攻击(XSRF)。有解决XSRF攻击的已知方法,例如包含一次性令牌或加密令牌,以验证提交是否有意来自用户并且不是从攻击者代码启动的。


如果您允许跨域AJAX,则将失去此保护措施。攻击代码可以从银行网站请求一个页面,读取其中的所有授权令牌,然后在第二个AJAX请求中提交它们以执行转移。那将是跨站点脚本攻击。


查看完整回答
反对 回复 2019-11-27
?
翻过高山走不出你

POST之间的重要区别:

<body onload="document.getElementById('InvisbleForm').submit()" ...

而Ajax是,在执行任何POST之后,浏览器将替换页面,并且在进行Ajax调用后-不会。POST的结果将是:

  1. 对用户清晰可见。

  2. 由于此时来自的响应页my-bank.com将进行控制,因此攻击将停留在此时。任何银行都不会实施一键转账

如果允许跨域Ajax,则XSRF的场景将如下所示:

  1. 用户以某种方式访问www.bad-guy.com

  2. 如果my-bank.com在浏览器的其他实例中没有打开的页面,则攻击不会成功。

  3. 但是,如果打开了此类页面,并且用户已经输入了用户名/密码,则意味着在浏览器的缓存中有此会话的cookie。

  4. 页面上的JavaScript代码从www.bad-guy.com发出Ajax调用my-bank.com

  5. 对于浏览器,这是一个常规的HTTP调用,它必须将my-bank cookie my-bank.com发送到并发送。

  6. 银行处理此请求,因为它无法将此呼叫与用户的常规活动区分开。

  7. JavaScript代码可以读取响应的事实并不重要。在攻击情况下,这可能不是必需的。真正重要的是,计算机前的用户不知道会发生这种交互。他将在www.bad-guy.com页面上看到漂亮的图片。

  8. my-bank.com如果需要,JavaScript代码还会进行其他几个调用。

要点是不需要注入或任何页面篡改。

更好的解决方案可能是允许呼叫本身而不发送任何cookie。这是一个非常简单的解决方案,不需要任何广泛的开发。在许多情况下,Ajax调用会转到不受保护的位置,并且不发送cookie不会受到限制。

目前正在讨论中的CORS(跨源资源共享)涉及发送/不发送cookie。


查看完整回答
反对 回复 2019-11-27
?
幕布斯5086720

当您向服务器发送HTTP请求时,由服务器设置的cookie也将由浏览器发送回服务器。服务器使用这些cookie来确定用户已登录等事实。


这可以由恶意攻击者利用,该恶意攻击者可以借助某些JavaScript在用户不了解任何信息的情况下在其他网站上窃取信息或执行未经授权的命令。


例如,可以要求用户访问具有以下JavaScript代码的网站(假设使用jQuery):


<script type="text/javascript">

  $.post("http://some-bank.com/transfer-money.php", 

         { amount: "10000", to_account: "xxxx" })

</script>

现在,如果执行上述代码时用户确实登录了银行,则攻击者可能已将10K美元转入了XXX帐户。


这种攻击称为跨站点请求伪造(XSRF)。在Wikipedia上有关于此的更多信息。


主要是由于这个原因,存在同源策略,浏览器不允许您在与原始域不同的域上执行XMLHttpRequest。


目前正在进行一些讨论以实际允许跨域XHR,但是我们必须看看它是否真的被接受。


查看完整回答
反对 回复 2019-11-27
  • 3 回答
  • 0 关注
  • 231 浏览
我要回答
慕课专栏
更多

添加回答

回复

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信