javascript - 外行术语中的同源策略

Question

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

这link似乎做了我发现的最好的工作。任何人都可以扩展吗？有人可以解释为什么存在此政策吗？

Answer 1

需要同源策略来防止CSRF .想象一下这个场景:

1. 银行经理 Joe Fatcat 在其银行的管理后台上有一个帐户。该帐户允许他访问在 TBtF 银行开户的任何人的 secret 帐户信息。他甚至可以重置某人的密码、转账、更改帐户所有权等。
2. 现在，TBtF 银行解雇了 ​​IT 专家 jack 。现在他是心怀不满的前 IT 人 jack ，他想报复他的前雇主。 jack 无权访问银行的管理后台，但他知道乔可以。
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. Joe 看到一封电子邮件，其中包含指向娜塔莉·波特曼 (Natalie Portman) 的照片的链接。所以他很自然地点击了它，打开了恶意网页。
3. 浏览器在页面上运行 JavaScript，并向 TBtF Bank 的管理后端站点发出 AJAX POST 请求。因为 Joe 已经登录到该站点并且有一个事件 session ，银行应用程序接受命令并将巨额美元电汇到 Jack 的离岸银行账户。

Jack 可以很容易地使用相同的技术来收集数千个帐号和个人识别码，或者银行经理 Joe 可以通过他的帐户访问的任何其他信息。

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