托管在不同域上的 JavaScript 可以读取/修改另一个域的 DOM 吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/27403797/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Can a JavaScript hosted on different domain read/modify DOM of another domain?
提问by Carmine Giangregorio
I have a question regarding a potential security issue/limitation regarding JavaScript hosted on a domain (ex: domain of a CDN, say example.com), but loaded from a website under a different domain (say, example.net).
我有一个关于托管在域（例如：CDN 的域，例如 example.com）上但从不同域（例如 example.net）下的网站加载的 JavaScript 的潜在安全问题/限制的问题。
Now imagine that the JavaScript loaded will just read/modify text in a divwith a particular id, so nothing "complicated".
An example: I have the script loaded from http://example.com/myscript.js, and executed on http://example.net/index.html: [note the different TLD!]
现在想象一下，加载的 JavaScript 只会读取/修改div具有特定 id 的文本，所以没有什么“复杂”的。一个例子：我从http://example.com/myscript.js加载了脚本，并在http://example.net/index.html 上执行：[注意不同的 TLD！]
<!-- Page example.net/index.html -->
<script src="http://example.com/myscript.js"></script>
I know that I can't access Cookies under mysite.com from the JavaScript, but I can access all the DOM on the page and in case, modify it. Isn't this a possible security issue? Shouldn't this trigger the same-origin-policy protection?
我知道我无法从 JavaScript 访问 mysite.com 下的 Cookie，但我可以访问页面上的所有 DOM，以防万一，修改它。这不是一个可能的安全问题吗？这不应该触发同源策略保护吗？
Are there user agents that prevents a JavaScript hosted on a different domain to access elements in the page that executes the script?
是否有用户代理阻止托管在不同域上的 JavaScript 访问执行脚本的页面中的元素？
And, moreover, will the example above work also on HTTPS pages? (ex: https://example.net/index.htmlloads the script from https://example.com/myscript.js)
此外，上面的示例是否也适用于 HTTPS 页面？（例如：https://example.net/index.html从https://example.com/myscript.js加载脚本）
回答by Quentin
All URL based security restrictions in client side JavaScript are based on the URL of the webpage containing the <script>element which loads the JS.
客户端 JavaScript 中所有基于 URL 的安全限制都基于包含<script>加载 JS的元素的网页的 URL 。
The URL the JS itself is hosted at is irrelevant.
JS 本身所在的 URL 无关紧要。
Now, I know that I can't access Cookies under mysite.com from the JS.
现在，我知道我无法从 JS 访问 mysite.com 下的 Cookie。
The script is loaded into example.netand hosted on example.com. It can read cookies from example.net. It cannot read cookies from example.com. (Server side code on example.comcould dynamically generate the JavaScript and embed data taken out of cookies though).
脚本被加载example.net并托管在example.com. 它可以从example.net. 它无法从 读取 cookie example.com。（example.com尽管服务器端代码可以动态生成 JavaScript 并嵌入从 cookie 中取出的数据）。
But, I can access all the DOM on the page, and, in case, modify it.
但是，我可以访问页面上的所有 DOM，并且可以修改它。
Yes
是的
Isn't this a possible security issue? Shouldn't this trigger the same-origin-policy protection?
这不是一个可能的安全问题吗？这不应该触发同源策略保护吗？
It is a potential security issue, but it should not trigger the Same Origin Policy.
这是一个潜在的安全问题，但不应触发同源策略。
By loading the script, the author of the page is trusting the site hosting the script.
通过加载脚本，页面作者信任托管脚本的站点。
Do not embed JS from sites you do not trust.
不要从您不信任的站点嵌入 JS。
And, moreover, will the example above work also on HTTPS pages? (ex:
https://example.net/index.htmlloads the script fromhttps://example.com/myscript.js)
此外，上面的示例是否也适用于 HTTPS 页面？（例如：
https://example.net/index.html从 加载脚本https://example.com/myscript.js）
URLs with different schemes have different origins, just as URLs with different hostnames. The Same Origin Policy rules are the same as they are based on origin not particular features of origins.
具有不同方案的 URL 具有不同的来源，就像具有不同主机名的 URL。同源策略规则相同，因为它们基于起源而不是起源的特定特征。
Sometimes you will get additional restrictions where a page loaded over HTTPS will be forbidden from accessing content loaded over HTTP since that breaks the SSL security. This is a different security restriction that is unrelated to the Same Origin Policy.
有时您会得到额外的限制，禁止通过 HTTPS 加载的页面访问通过 HTTP 加载的内容，因为这会破坏 SSL 安全性。这是与同源策略无关的不同安全限制。
回答by ircmaxell
Isn't this a possible security issue?
这不是一个可能的安全问题吗？
Yes, this is called Cross-Site-Scripting (XSS).
是的，这称为跨站点脚本 (XSS)。
It is most definitely a security issue.
这绝对是一个安全问题。
Bottom line, neverinclude code, from any domain, that you don't trust. End of story.
最重要的是，永远不要包含来自任何域、您不信任的代码。故事结局。
If an attacker can get code running on your domain, it's game-over.
如果攻击者可以让代码在您的域上运行，那么游戏就结束了。
Shouldn't this trigger the same-origin-policy protection?
这不应该触发同源策略保护吗？
No.
不。
The same-origin-policy basically means that the script can only ever view/modify the DOM of the domain to which it was loaded. So you can't create an iframe to an arbitrary site and read that DOM from the parent unless CORS is on, or your script is running there too.
同源策略基本上意味着脚本只能查看/修改它加载到的域的 DOM 。因此，除非开启 CORS，或者您的脚本也在那里运行，否则您无法为任意站点创建 iframe 并从父站点读取该 DOM 。
Perhaps, are there user agents that prevents a Javascript, hosted on a different domain, to access elements in the page that executes the script?
也许，是否有用户代理阻止托管在不同域上的 Javascript 访问执行脚本的页面中的元素？
The only way to do this, is to sandbox that javascript inside of an iframe which is on a different domain.
唯一的方法是在不同域的 iframe 中沙箱该 javascript 。
So you could create a sandbox.example.comdomain, which generates a wrapper page which includes the javascript.
所以你可以创建一个sandbox.example.com域，它生成一个包含 javascript 的包装页面。
Then, instead of linking to the JS directly, create an iframe to the sandbox domain. The JS will have access to that domain, and everything in that DOM, but nothing outside of the iframe.
然后，不是直接链接到 JS，而是创建一个到沙盒域的 iframe。JS 将可以访问该域以及该 DOM 中的所有内容，但不能访问 iframe 之外的任何内容。
You still have to be careful to set cookies properly (don't do wildcard domains, etc). But it canhelp.
您仍然必须小心正确设置 cookie（不要使用通配符域等）。但它可以提供帮助。
