Layman条款中的同源策略

Question

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

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

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

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

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

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

Answer 2

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

因此，如果您要从其他域限制中提供脚本，请应用。

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