Why the cross-domain Ajax is a security concern?
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.
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:
- Clearly visible to the user.
- The attack will be stuck at this point because the response page from
my-bank.comwill 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:
- User somehow visits
www.bad-guy.com. - If there no opened page to
my-bank.comin other instance of the browser, the attack is unsuccessful. - 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.
- JavaScript code on the page from
www.bad-guy.commakes an Ajax call tomy-bank.com. - For the browser this is a regular HTTP call, it has to send the my-bank cookies to
my-bank.comand it sends them. - Bank processes this request because it cannot distinguish this call from the regular activity of the user.
- 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.compage. - JavaScript code makes several other calls to
my-bank.comif 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.
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.