为什么跨域 Ajax 是一个安全问题? [英] Why the cross-domain Ajax is a security concern?

查看:28
本文介绍了为什么跨域 Ajax 是一个安全问题?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

为什么决定使用 XMLHTTPRequest 进行 XML 调用不应跨越域边界进行调用?您可以从其他域中检索 JavaScript、图像、CSS、iframe 以及我能想到的任何其他内容.为什么 Ajax HTTP 请求不允许跨域边界?考虑到我看到它被滥用的唯一方式,这似乎是一个奇怪的限制,如果有人将 Javascript 注入页面.但是,在这种情况下,您可以简单地向文档添加一个 img、脚本或 iframe 元素,以使其请求第三方 URL 并将其发送到服务器.

有些答案指出了以下原因,让我们指出他们没有成为不允许这样做的主要原因的原因.

XSRF(Cross Site Request Forgery,也称为 CSRF、XSRF)

你可以在不使用它的情况下进行 XSRF 攻击.作为一般规则,根本不使用 XMLHTTPRequest,因为很难以与所有主要浏览器兼容的方式制作 XMLHTTPRequest.如果您希望他们加载您的网址,只需在网址中添加一个 img 标签就容易多了.

发布到第三方网站

可以用

<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"></表单>

JPunyon:你为什么要把漏洞留在新功能中

你不会再制造任何不安全感.您只是给想要永久使用它的开发人员带来不便.任何想要将此功能用于邪恶(又名很棒)的人都可以使用其他方法来实现.

结论

我将 bobince 的答案标记为正确,因为他指出了关键问题.因为 XMLHTTPRequest 允许您将凭据 (cookie) 发布到目标站点,并读取从站点发回的数据以及发送人员凭据,所以您可以编排一些 javascript 来提交一系列表单,包括确认表单, 包括生成的所有随机密钥,这些密钥已被放置到位以尝试防止 XSRF.通过这种方式,您可以浏览目标站点,例如银行,而银行的网络服务器将无法判断这不仅仅是提交所有这些表单的普通用户.

解决方案

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

因为 AJAX 请求是 (a) 与用户凭据一起提交的,并且 (b) 允许调用者读取返回的数据.

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

<块引用>

您可以简单地将 img、脚本或 iframe 元素添加到文档中

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

(除了那些故意设置为允许的脚本,允许跨域脚本 - 或者有人做了一个可怕的错误.)

<块引用>

你可以在不使用它的情况下进行 XSS 攻击.发布到第三方网站

那不是 XSS 攻击.这是跨站点请求伪造攻击 (XSRF).有一些已知的方法可以解决 XSRF 攻击,例如包括一次性或加密令牌来验证提交是故意来自用户而不是由攻击者代码发起的.

如果您允许跨域 AJAX,您将失去此保护措施.攻击代码可以从银行网站请求一个页面,读取页面上的任何授权令牌,然后在第二个 AJAX 请求中提交它们以执行传输.而那是一种跨站点脚本攻击.

Why was it decided that using XMLHTTPRequest for doing XML calls should not do calls across the domain boundary? You can retrieve JavaScript, images, CSS, iframes, and just about any other content I can think of from other domains. Why are the Ajax HTTP requests not allowed to cross the domain boundaries? It seems like an odd limitation to put, considering the only way I could see it being abused, would be if someone were to inject Javascript into the page. However, in this case, you could simply add an img, script, or iframe element to the document to get it to request the third party URL and send it to the server.

[Edit]

Some of the answers point out the following reasons, let's point out the reasons they don't create a major reason to disallow this.

XSRF (Cross Site Request Forgery, also known as CSRF, XSRF)

Your can do XSRF attacks without using this at all. As a general rule, XMLHTTPRequest isn't used at all, simply because it's so hard to make an XMLHTTPRequest in a way that's compatible with all major browsers. It's much easier to just add an img tag to the URL if you want them to load your URL.

Posting to third party site

<script type="text/javascript">
  $.post("http://some-bank.com/transfer-money.php", 
         { amount: "10000", to_account: "xxxx" })
</script>

Could be accomplished with

<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: why would you leave the vulnerability in a new feature

You aren't creating any more insecurities. You are just inconveniencing developers who want to use it in a way for good. Anybody who wants to use this feature for evil (aka awesome) could just use some other method of doing it.

Conclusion

I'm marking the answer from bobince as correct because he pointed out the critical problem. Because XMLHTTPRequest allows you to post, with credentials (cookies) to the destination site, and read the data sent back from the site, along with sending the persons credentials, you could orchestrate some javascript that would submit a series of forms, including confirmation forms, complete with any random keys generated that were put in place to try to prevent a XSRF. In this way, you could browse through the target site, like a bank, and the bank's webserver would be unable to tell that it wasn't just a regular user submitting all these forms.

解决方案

Why are Ajax HTTP Requests not allowed to cross domain boundaries.

Because AJAX requests are (a) submitted with user credentials, and (b) allow the caller to read the returned data.

It is a combination of these factors that can result in a vulnerability. There are proposals to add a form of cross-domain AJAX that omits user credentials.

you could simply add an img, script, or iframe element to the document

None of those methods allow the caller to read the returned data.

(Except scripts where either it's deliberately set up to allow that, for permitted cross-domain scripting - or where someone's made a terrible cock-up.)

Your can do XSS attacks without using this at all. Posting to third party site

That's not an XSS attack. That's a cross-site request forgery attack (XSRF). There are known ways to solve XSRF attacks, such as including one-time or cryptographic tokens to verify that the submission came deliberately from the user and was not launched from attacker code.

If you allowed cross-domain AJAX you would lose this safeguard. The attacking code could request a page from the banking site, read any authorisation tokens on it, and submit them in a second AJAX request to perform the transfer. And that would be a cross-site scripting attack.

这篇关于为什么跨域 Ajax 是一个安全问题?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆