blocks|key|1692187|text|基本上，这意味着-只有来自相同域的脚本才能不受限制地访问彼此的对象和属性(因此，如果您有一个定义了命名函数的.js文件，则可以从同一域中托管的任何其他文件中调用它)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1692188|因此，如果您提供的是来自不同域的脚本，请务必应用限制。|1692189|该策略之所以存在，是因为在不同的域中插入指向某个javascript文件的链接太容易了(比如，一些javascript代码会注入指向这样一个文件的链接)。这是一个安全风险-你真的只想要来自你要执行的站点的代码，而不是任何存在的代码。|1692190|entityMap^0|1I|3|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|K|$]]

Basically it means - only scripts that are served from the same domain can access each others objects and properties without restriction (so if you have a <code>.js</code> file with named functions defined, you can call it from any other file hosted on the same domain).

So, if you are serving a script from a different domain restriction do apply.

This policy exists because it is too easy to inject a link to a javascript file (say some javascript code that injects a link to such a file) that is on a different domain. This is a security risk - you really only want code that comes from the site you are on to execute and not just any code that is out there.

blocks|key|3329246|text|需要使用同源策略来防止CSRF。想象一下这样的场景：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3329247|3329248|银行经理Joe+Fatcat在他的银行管理后端有一个帐户。此帐户允许他访问任何在TBtF银行开户的人的机密帐户信息。他甚至可以重置某人的密码、转账、更改帐户所有权等。现在，TBtF银行解雇了IT人员|ordered-list-item|3329249|。现在他是心怀不满的“前IT人杰克”，他想要向他的前雇主报仇。杰克没有访问银行管理后台的权限，但他知道乔有。|3329250|，所以杰克给他的老板发了一封电子邮件，里面有一个指向杰克创建的页面的链接。在页面上，有一些JavaScript，比如：|3329251|3329252|var+xhr+=+new+XMLHttpRequest(),
++++data+=+"from="%2BvictimAccount
+++++++++++%2B+"&to="%2BjacksAccount
+++++++++++%2B+"&amt=a%2Bgazillion%2Bdollars";
xhr.open("POST",+"http://tbtfbank.tld/accounts/wiretransfer.aspx",+true);
xhr.send(data);|code-block|syntax|javascript|3329253|3329254|第二天，乔到达他的办公室，像往常一样登录到他的管理帐户，并在background.|3329255|Joe中打开了选项卡，看到了一封电子邮件，其中包含到娜塔莉·波特曼满身滚烫的粗粉的照片的链接。所以他很自然地点击了它，打开了恶意网页。|3329256|浏览器在页面上运行JavaScript并向TBtF银行的管理后端站点发出AJAX+POST请求。因为Joe已经登录到该站点并且有一个活动会话，所以银行应用程序接受命令并将数十亿美元电汇到Jack的离岸银行帐户。|3329257|3329258|而Jack也可以很容易地使用同样的技术来获取数千个帐号和pins，或者银行经理Joe通过他的帐户可以访问的任何其他信息。|3329259|幸运的是，同源策略在大多数情况下可以保护我们免受这些类型的攻击，因为Jack的恶意页面托管在与银行应用程序不同的域上，因此不允许对银行应用程序进行XHR。尽管恶意页面可能仍然包含向银行应用程序发出GET请求的图像，因此重要的是不要通过GET请求启动有副作用的操作，并且应用程序要检查它们收到的请求的referrer头，并利用反CSRF令牌。|3329260|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Cross-site_request_forgery^0|B|4|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@$A|1C|B|1D|1|1E]]|C|$]]|$1|D|3|-4|5|6|7|1F|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1G|8|@]|9|@]|C|$]]|$1|H|3|I|5|G|7|1H|8|@]|9|@]|C|$]]|$1|J|3|K|5|G|7|1I|8|@]|9|@]|C|$]]|$1|L|3|-4|5|6|7|1J|8|@]|9|@]|C|$]]|$1|M|3|N|5|O|7|1K|8|@]|9|@]|C|$P|Q]]|$1|R|3|-4|5|6|7|1L|8|@]|9|@]|C|$]]|$1|S|3|T|5|G|7|1M|8|@]|9|@]|C|$]]|$1|U|3|V|5|G|7|1N|8|@]|9|@]|C|$]]|$1|W|3|X|5|G|7|1O|8|@]|9|@]|C|$]]|$1|Y|3|-4|5|6|7|1P|8|@]|9|@]|C|$]]|$1|Z|3|10|5|6|7|1Q|8|@]|9|@]|C|$]]|$1|11|3|12|5|6|7|1R|8|@]|9|@]|C|$]]|$1|13|3|-4|5|6|7|1S|8|@]|9|@]|C|$]]]|14|$15|$5|16|17|18|C|$19|1A]]]]

Same-origin policy is needed to prevent <a href="http://en.wikipedia.org/wiki/Cross-site_request_forgery" rel="noreferrer">CSRF</a>. Imagine this scenario:

<ol>
<li>Bank manager Joe Fatcat has an account on his bank's administrative backend. This account lets him access confidential account info for anyone who banks at TBtF Bank. He can even reset someone's pin number, transfer funds, change account ownership, etc.</li>
<li>Now, TBtF Bank lays off Jack the IT Guy. Now he's Jack the Digruntled Ex-IT-Guy, and he wants to take revenge on his former employer. Jack doesn't have access to the bank's administrative backend, but he knows Joe does.</li>
<li>So Jack sends his boss an email with a link to a page Jack created. On the page, there's some JavaScript like:</li>
</ol>

 

<pre><code>var xhr = new XMLHttpRequest(),
 data = "from="+victimAccount
 + "&amp;to="+jacksAccount
 + "&amp;amt=a+gazillion+dollars";
xhr.open("POST", "http://tbtfbank.tld/accounts/wiretransfer.aspx", true);
xhr.send(data);
</code></pre>

<ol start="3">
<li>The next day, Joe arrives at his office and logs into his administrative account as he always does and leaves the tab open in the background.</li>
<li>Joe sees an email containing links to pictures of Natalie Portman covered in hot grits. So naturally he clicks on it, opening the malicious webpage.</li>
<li>The browser runs the JavaScript on the page and makes an AJAX POST request to TBtF Bank's administrative backend site. Because Joe is already logged into the site and has an active session, the bank application accepts the command and wires a gazillion dollars to Jack's offshore bank account.</li>
</ol>

And Jack could have just as easily used the same technique to harvest thousands of account numbers and pins or any other information Joe the bank manager has access to via his account.

Luckily, the same-origin policy protects us from these types of attacks most of the time, since Jack's malicious page is hosted on a different domain from the bank application, it's not allowed to make XHRs to the bank application. Though the malicious page could still contain an image that makes a GET request to the bank application, so it's important that actions with side effects are not initiated via GET requests and that applications check the referrer header of requests they receive and take advantage of anti-CSRF tokens.

Can someone help me to better understand the Same Origin Policy. I've seen several websites describing it but I'm looking for an explanation much more simple, how would you describe it to a kid?

This <a href="https://developer.mozilla.org/En/Same_origin_policy_for_JavaScript" rel="noreferrer">link</a> seems to do the best job that I've found. Can anyone expand? Can someone explain why this policy exists?

Same Origin Policy in Layman Terms

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

有没有人可以帮我更好的理解同源策略。我已经看过几个描述它的网站，但我正在寻找一个更简单的解释，你会如何向一个孩子描述它？这个似乎是我发现的最好的。任何人都可以扩展吗？有没有人能解释一下为什么会有这个政策？

问Layman术语中的同源策略
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Layman术语中的同源策略EN