4

By default, browsers don't allow cross-site AJAX requests.

I understand that a badly envisioned cross-domain request can be a security risk. If I take the html or the javascript of an external site and just "render" it into my website, that's a problem. That external code could be used for lots of bad things - like getting access to the current user's session data.

But if I only request JSON or XML data, and I use a proper library to parse the JSON (not just using eval) I can't imagine how that would be a security risk. The worse that can happen is that the content coming from that site doesn't render correctly.

Am I missing anything? Is it possible to compromise a page that reads json/xml simply by sending it some kind of malicious data?

kikito
  • 51,734
  • 32
  • 149
  • 189
  • 2
    `By default, browsers don't allow cross-site requests.` This sentence needs a bit polishing. Are you talking about XHR? Are you talking about cookies? Because in general browsers allow for cross domain requests: suffice to use an anchor or a form pointing to the remote domain and when the user clicks on this link a cross domain request is performed without any issue. – Darin Dimitrov Feb 10 '12 at 13:01
  • 1
    Possible duplicate of http://stackoverflow.com/q/9222822 and http://stackoverflow.com/q/9169038 – Gumbo Feb 10 '12 at 13:04
  • @DarinDimitrov you are right. I've changed the phrase. – kikito Feb 10 '12 at 16:14
  • @Gumbo yes, my question seems duplicate. I searched for this for a while before asking, but could not find those. The "proper json and xml parsing" part is different though. – kikito Feb 10 '12 at 16:23

2 Answers2

13

The risk isn't to the site making the request.

For example:

  1. Alice visits Her Bank and logs in.
  2. She then visits Evil Site.
  3. Evil Site uses JavaScript to cause Alice's browser to make a request to Her Bank
  4. Her Bank responds with Alice's account details and passes them to the JavaScript
  5. The JavaScript then passes them on to the controller of Evil Site

In a nutshell — it prevents attackers from reading private data from any site that Alice has credentials for (and ones that are behind a firewall, e.g. Alice's corporate Intranet).

Note that this won't prevent attacks which don't depend on being able to read data form the site (CSRF), but without the Same Origin Policy the standard defence against CSRF would be easily defeatable.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • You’re wrong. This is not protected by the Same-Origin Policy. – Gumbo Feb 10 '12 at 13:02
  • @Gumbo — I'd spotted the flaw in the example and was editing as you made that comment. – Quentin Feb 10 '12 at 13:08
  • Hmm. If I'm understanding this correctly, you mean that user sessions are shared in a browser? I was under the impression that servers are where able to distinguish between different opened windows/tabs. "Hey, this request comes from a different window, return the unauthorized response code"-kind of thing. Isn't that the case? – kikito Feb 10 '12 at 16:32
  • @kikito — That isn't the case. If you open a new tab, you aren't logged out, and it would be annoying to have to login *again* just because you wanted two tabs on a single site. Even if that wasn't the case, you might visit Evil Site after visiting Your Bank and be using the same tab. – Quentin Feb 10 '12 at 16:36
  • Allright. I think I get it now. Thanks for clarifying. I respect network security guys a bit more now. It is hard. – kikito Feb 10 '12 at 16:49
2

You're absolutely right with your second point re JSON/XML. When proper precaution is taken, there is no risk in receiving JSON from another domain. Even if the server decides to return some nasty script, you can effectively manage risk with proper data parsing. In fact, this is exactly why the JSONP hack is so popular (see twitter's search api for example).

Already we're seeing HTML5 capable browsers introduce new objects and standards for cross domain communication (postMessage - http://dev.w3.org/html5/postmsg/ and Cross-Origin Resource Sharing - http://www.w3.org/TR/cors/ ).

osahyoun
  • 5,173
  • 2
  • 17
  • 15
  • I would prefer that this type of thing was handled the same way the browser requests access to your microphone, your geolocation data or your webcam. Just show a bar across the top of the browser window asking permission for example.com page to access data from data.example.com or mybank.com. If you use CORS or JSONP, then the bar does not appear. If you don't then you get the permission bar. – TxRegex Mar 24 '14 at 17:27