42

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.

Kirill Kobelev
  • 10,252
  • 6
  • 30
  • 51
Kibbee
  • 65,369
  • 27
  • 142
  • 182
  • modifying those attacks because they are actually xsrf attacks. xss when you inject script onto the legitimate pages site – Shawn Jan 21 '09 at 20:44
  • @Kibbee, are you here? I want to edit your message to make it more clear. In some cases I do not fully understand your English. Will you review? – Kirill Kobelev Oct 12 '12 at 05:28
  • @KirillKobelev The edits look good to me. Nice to see this old question is still alive and well. – Kibbee Oct 12 '12 at 12:41
  • I decided to write my own answer. Can you, please, take a look? – Kirill Kobelev Oct 12 '12 at 23:19
  • "Because XMLHTTPRequest allows you to post, with credentials (cookies) to the destination site, and read the data sent back from the site". Then attacker, just use for example header('Access-Control-Allow-Origin: *') and can read the data sent back from the site and make submit forms and etc. Or misunderdstand something ? – Sever Oct 02 '15 at 13:02

9 Answers9

37

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.

bobince
  • 528,062
  • 107
  • 651
  • 834
  • this is a great answer, but in the last paragraph i still dont think thats a xss attack. an xss attack is where you inject javascript onto the legitimate sites website. – Shawn Jan 22 '09 at 01:58
  • SQL injection is certainly the most common method to get an XSS, but not the only one. The effects of being able to AJAX cross-domain would be just the same as would result from an SQL injection. – bobince Jan 22 '09 at 11:47
  • sql injection is not the most common method to get an xss, it's unencoded user submited text sent from the server – Shawn Jan 22 '09 at 13:54
  • Sorry yes, HTML injection. God I'm bobbins at typing thoughts sometimes. SQL injection is a far worse level of attack... – bobince Jan 22 '09 at 15:28
  • I wrote my own answer. Can you, please, take a look? – Kirill Kobelev Oct 12 '12 at 23:19
8

An important difference between the POST:

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

and Ajax is that after doing any POST the browser will replace the page and after doing the Ajax call - not. The result of the POST will be:

  1. Clearly visible to the user.
  2. The attack will be stuck at this point because the response page from my-bank.com will take the control. No bank will implement a one-click-transfer.

The scenario of XSRF, if the cross domain Ajax would be allowed, will look like the following:

  1. User somehow visits www.bad-guy.com.
  2. If there no opened page to my-bank.com in other instance of the browser, the attack is unsuccessful.
  3. But if such page is opened and the user has already entered his user-name/password, this means that there is a cookie for this session in the cache of the browser.
  4. JavaScript code on the page from www.bad-guy.com makes an Ajax call to my-bank.com.
  5. For the browser this is a regular HTTP call, it has to send the my-bank cookies to my-bank.com and it sends them.
  6. Bank processes this request because it cannot distinguish this call from the regular activity of the user.
  7. The fact that JavaScript code can read the response is not important. In the attack case this might be not necessary. What is really important is that the user in front of the computer will have no idea that this interaction takes place. He will look at nice pictures on the www.bad-guy.com page.
  8. JavaScript code makes several other calls to my-bank.com if this is needed.

The gist is that no injection or any page tampering is needed.

A better solution might be to allow the call itself but not to send any cookies. This is very simple solution that does not require any extensive development. In many cases Ajax call goes to unprotected location and not sending cookies will not be a limitation.

The CORS (Cross Origin Resource Sharing) that is under discussion now, among other things, speaks about sending/not sending cookies.

Kirill Kobelev
  • 10,252
  • 6
  • 30
  • 51
2

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.

Andrew Rollings
  • 14,340
  • 7
  • 51
  • 50
  • It would be nice if they offered it as an update to the existing browsers if they ever decided that we should be able to do cross domain AJAX calls. – Kibbee Jan 21 '09 at 20:18
  • Agreed :) I hate having to duplicate functionality across sites via local wrappers. – Andrew Rollings Jan 21 '09 at 20:32
2

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.

Baishampayan Ghose
  • 19,928
  • 10
  • 56
  • 60
  • That's only a problem if the bank specifically only looks in the post for the values. In many cases, whoever implemented the site just looks in the "Request", which is contains both POST and GET. – Kibbee Jan 21 '09 at 20:22
  • So you could accomplish the same thing by getting them to load the following URL http://some-bank.com/transfer-money.php?amount=10000&to_account=xxxxx – Kibbee Jan 21 '09 at 20:22
  • Also, you could make a hidden form, in an iframe, and make the action point to http://some-bank.com/transfer-money.php, which automatically fills it in and sumbits via Javascript. If the bank didn't check the referrer, it would think the user was making a valid request. – Kibbee Jan 21 '09 at 20:25
  • Referrers can be spoofed. You should never used the referrer for authentication. Look up CSRF and you'll find out how you can prevent this type of web vulnerability. – BacMan Jan 21 '09 at 20:31
  • this can be done with regular javascript. has nothing to do with opps question – Shawn Jan 21 '09 at 20:32
1

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.

Mike Griffith
  • 1,201
  • 11
  • 17
1

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.

Shawn
  • 19,465
  • 20
  • 98
  • 152
1

I don't know what the huge problem is? Have AJAX calls sent towards other domains firs sent to your application and then forwarded elsewhere with filtered data, parse the returned data if you really need to, and feed it to the user.

Handling sensitive AJAX requests? Nail down the incoming suckers by checking for headers, storing session time data or by filtering incoming IP addresses down to sources of you trust or your applications.

What I'd personally like to see in the future is rock solid security on all incoming requests by default on web servers, frameworks and CMSs, and then explicitly define resources that will parse request from outside sources.

Filip Dupanović
  • 32,650
  • 13
  • 84
  • 114
1

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.

Kornel
  • 97,764
  • 37
  • 219
  • 309
0

You turn unsuspecting visitors into denial of service attackers.

Also, Imagine a cross site script that steals all your facebook stuff. It opens an IFrame and navigates to Facebook.com

You're already logged in to facebook (cookie) and it goes reads your data/friends. And does more nasties.

user57660
  • 133
  • 1
  • 6