外行术语中的同源策略

Question

谁能帮助我更好地理解同源政策。我看过几个描述它的网站，但我正在寻找一个更简单的解释，你会如何向孩子描述它？

这个link 似乎做得最好。任何人都可以扩展吗？有人可以解释为什么存在这项政策吗？

Answer 1

需要同源策略来防止CSRF。想象一下这种情况：

1. 银行经理 Joe Fatcat 在其银行的管理后端有一个帐户。该帐户使他可以访问在 TBtF 银行开户的任何人的机密帐户信息。他甚至可以重置某人的密码、转移资金、更改帐户所有权等。
2. 现在，TBtF 银行解雇了 ​​IT 专家杰克。现在他是愤愤不平的前 IT 人杰克，他想报复他的前雇主。 Jack 无权访问银行的管理后台，但他知道 Joe 可以。
3. 因此，Jack 向他的老板发送了一封电子邮件，其中包含指向 Jack 创建的页面的链接。在页面上，有一些 JavaScript，例如：

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

1. 第二天，Joe 到达他的办公室并像往常一样登录到他的管理帐户，并在后台保持选项卡处于打开状态。
2. 乔看到一封电子邮件，其中包含指向娜塔莉·波特曼 (Natalie Portman) 的照片的链接。所以他很自然地点击它，打开了恶意网页。
3. 浏览器在页面上运行 JavaScript 并向 TBtF 银行的管理后端站点发出 AJAX POST 请求。由于 Joe 已经登录到该站点并且有一个活动会话，因此银行应用程序接受了该命令并将大量美元汇入 Jack 的离岸银行账户。

Jack 可以同样轻松地使用相同的技术来获取数千个帐号和密码或银行经理可以通过其帐户访问的任何其他信息。

幸运的是，同源策略在大多数情况下都可以保护我们免受此类攻击，因为 Jack 的恶意页面托管在与银行应用程序不同的域中，因此不允许对银行应用程序进行 XHR。尽管恶意页面仍可能包含向银行应用程序发出 GET 请求的图像，但重要的是不要通过 GET 请求启动具有副作用的操作，并且应用程序检查它们收到的请求的引用标头并利用反CSRF 令牌。

Answer 2

基本上这意味着 - 只有来自同一域的脚本才能不受限制地访问彼此的对象和属性（因此，如果您有一个定义了命名函数的 .js 文件，您可以从托管的任何其他文件调用它同一个域）。

因此，如果您从不同域限制提供脚本请应用。

之所以存在此政策，是因为很容易将链接注入到不同域中的 javascript 文件（例如一些注入此类文件链接的 javascript 代码）。这是一个安全风险 - 您真的只希望执行来自您所在站点的代码，而不仅仅是任何外部代码。