Layman条款中的同源策略

Question

有人可以帮助我更好地理解同源政策。我已经看到几个网站描述它但我正在寻找一个更简单的解释，你会如何描述它？

这link似乎是我找到的最好的工作。谁能扩展？有人可以解释为什么这个政策存在吗？

Answer 1

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

1. 银行经理Joe Fatcat在其银行的行政后端有一个账户。此帐户允许他访问TBtF Bank银行的任何人的机密帐户信息。他甚至可以重置某人的密码，转账，更改账户所有权等。
2. 现在，TBtF银行推出了杰克IT专家。现在他是杰克这个疯狂的Ex-IT-Guy，他想报复他的前雇主。杰克无法访问银行的行政后端，但他知道乔会这样做。
3. 所以杰克给他的老板发了一封电子邮件，上面写着杰克创建的页面链接。在页面上，有一些像：




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. 第二天，乔到他的办公室，一如既往地登录他的行政帐户，并在后台打开标签。
2. Joe看到一封电子邮件，其中包含Natalie Portman用烫金布满的照片链接。所以他自然会点击它，打开恶意网页。
3. 浏览器在页面上运行JavaScript并向TBtF Bank的管理后端站点发出AJAX POST请求。由于Joe已经登录该站点并且有一个活动会话，因此银行应用程序接受该命令并将大量美元汇入Jack的离岸银行账户。

杰克可以轻松地使用相同的技术来收集数千个账号和引脚或银行经理通过他的账户访问的任何其他信息。

幸运的是，同源策略大多数时候都保护我们免受这些类型的攻击，因为Jack的恶意页面托管在与银行应用程序不同的域中，因此不允许将XHR发送到银行应用程序。虽然恶意页面仍然可以包含向银行应用程序发出GET请求的图像，但重要的是不会通过GET请求启动带副作用的操作，并且应用程序检查他们收到的请求的引用者标头并利用反CSRF代币。

Answer 2

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

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

此策略的存在是因为将一个链接注入到另一个域上的javascript文件（例如一些注入此类文件的链接的javascript代码）太容易了。这是一个安全风险 - 您实际上只希望来自您所在站点的代码执行，而不仅仅是那里的任何代码。