What are the security risks in using cross-domain XMLHttpRequest?

Question

In many places I've seen people have talked about the Cross-Domain XMLHttpRequest, which is not possible, due to some security reasons. However, I haven't found a post indicating what those security reasons actually are?

People have mentioned that JSONP is one of the good alternatives. Another alternative would be to use Origin and Access-Control-Allow-Origin headers.

However, I just want to know what security problems can be raised due to cross-domain XMLHttpRequest usage?

Answer 1

I think it would be best to answer your question of an example of WHY it would be horrendously bad.

You go to my website (example.org). I load a script that makes a client-side AJAX request to facebook.com/messages/from/yourgirlfriend. You happened to be logged in to facebook, and your browser tells Facebook that my request is actually you. Facebook happily gives my request that message about the strange sexual things you want to try. I now know things about you you probably didn't want me to know.

This, of course is a wild exaggeration, and thankfully not possible thanks to the same origin policy.

Don't you feel safer now?

Answer 2

Without these "security reasons" the entire Internet as you know it could not exist. In fact i will go out on a limb and say there is no rule that is more important for Internet security than the same-origin policy.

No web page could have authentication without these rules, google, web mail accounts, SO, none of this could exist. It would be as if you had XSS on every domain. You could perform an XHR against gmail.com and read anyone's email. CSRF tokens wouldn't work because you could read any page and forge the request.

There is no single same-origin policy, but the rules are clearly laid out in the Google Browser Security handbook. These are very logical, and rules for the various platforms are very similar, because this is way the Internet must work.

By doing a Access-Control-Allow-Origin: * you are forfeiting your rights granted to you by web browsers for that page. This has major security implications. You will not be able to protect your self from CSRF using tokens. A capthca could mitigate this problem, also checking the referer might also help(it will be blank if the origin is HTTPS). You should read the CSRF prevention cheat sheet.

Answer 3

If it was allowed, an attacker who manage to inject Javascript into your page (through exploit/social-engineering) can send data (usually sensitive) which are acquired from your clients without them knowing (since XMLHttpRequests don't require user actions to occur and they are silent). It is a browser security measure.

JSONP is just a work around this security measure, where you give the destination a callback and entrust them with whatever they will give you back through this callback.

EDIT: Examples of a security risk: you login to your email account through the web (like gmail or yahoo). You carry on browsing (in another tab or even in the current tab) to another malicious site. This malicious site try to do XHR to the same website of your email account. Since the XHR is on your behave, and since it is client/browser-side request, this request will have the same session you used to login, and therefore, this website can do whatever they want with your account (send a spam mail through your account, download your contacts, ...etc). Another example: In a forum, someone manage to inject Javascript with XHR to another website. He now can steal the contacts list (and maybe then delete them) from all the people who visit his post in the forum (by using the same session of your web email). Not to mention that he can share the session of the members of the forum visiting his post to get whatever data they have in the forum (private messages/friends..etc). He can then send these data to his server to save them.