Why the cross-domain Ajax is a security concern?

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.

标签： ajax security xss

9条回答

在下西门庆

2楼-- · 2019-01-03 09:08

When you send a HTTP request to the server, the cookies set by the server are also sent back by the browser to the server. The server uses those cookies to establish the fact that the user is logged in, etc.

This can be exploited by a malicious attacker who, with the help of some JavaScript, can steal information or perform unauthorised commands on other websites without the user knowing anything about this.

For example, one could ask an user to visit a site which has the following JavaScript code (assuming jQuery):

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

Now, if the user were really logged into the bank while the above code was executed, the attacker could have transferred USD 10K to the account XXX.

This kind of attacks are called Cross Site Request Forgery (XSRF). There is more info about this on Wikipedia.

It's mainly due to this reason the same-origin policy exists and browsers won't allow you to perform XMLHttpRequests on domains different from the origin.

There is some discussion going on to actually allow cross-domain XHR, but we have to see whether this really gets accepted.

0人赞添加讨论(0) 举报

Summer. ? 凉城

3楼-- · 2019-01-03 09:08

With <form> you can post data, but you can't read it. With XHR you can do both.

Page like http://bank.example.com/display_my_password is safe against XSRF (assuming it only displays and not sets the password) and frames (they have same-origin policy). However cross-domain XHR would be a vulnerability.

0人赞添加讨论(0) 举报

够拽才男人

4楼-- · 2019-01-03 09:16

I think another thing that separates this from a normal XSRF attack is that you can do stuff with the data you get back as well via javascript.

0人赞添加讨论(0) 举报

劫难

5楼-- · 2019-01-03 09:18

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.

0人赞添加讨论(0) 举报

Explosion°爆炸

6楼-- · 2019-01-03 09:23

It's a concern because it can be used for bad purposes, as you mentioned. It can also be used with good intent, and for that reason, cross domain protocols are being developed.

The two biggest concerns are when it is used in conjunction with cross-site scripting (XSS) and cross-site request forgery (CSRF). Both are serious threats (which is why they made it into the OWASP top 10 and the SANS 25).

the only way I could see it being abused, would be if someone were to inject Javascript

This is XSS Far too many apps are still vulnerable, and if browser security models don't prevent X-domain AJAX, they are opening their users to a considerable attack vector.

you could simply add an img, script, or iframe element to the document to get it to request the third party URL

Yes, but those will send a HTTP_REFERRER and (through other means) can be blocked to prevent CSRF. AJAX calls can spoof headers more easily and would allow other means of circumventing traditional CSRF protections.

0人赞添加讨论(0) 举报

狗以群分

7楼-- · 2019-01-03 09:28

Well, apparently you're not the only person that feels that way...

http://www.google.com/search?q=xmlhttp+cross+site

EDIT: There is an interesting discussion linked from the above search:

http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx

Looks like proposals are under way to permit cross site xmlhttp requests (IE 8, FF3 etc.), although I wish they'd been there when I was writing the code for my sites :) And then there's the problem of compatibility... It will be a while before it's ubiquitous.

0人赞添加讨论(0) 举报

1 2 下一页