我对同源政策（SOP）感到困惑。
例如，http://bad.com/bad.html的{{1}}和bad.js的{{1}}。我使用两个标签（tab1和tab2）在我的chrome中打开两个网址。
在good.html（在tab2中打开）中，有一个元素http://good.com/good.html
现在问题是如果没有SOP ，是否可以使用某些代码（例如{{1}）从bad.html（在tab1中打开）中读取元素good.js值} <input id="token-id" type='text' name='token' value='123abc'>。
另一个问题是如果上述问题的答案是'不'，我无法理解维基https://en.wikipedia.org/wiki/Same-origin_policy#Security_Concerns中的这句话。
关于发送新交易，银行网站甚至CSRF保护也没有效果，因为脚本可以像用户那样做同样的事情
因为我们无法获得csrf令牌。为什么它不起作用。服务器可以通过验证csrf令牌来计算真实的帖子请求。
我是否误解了csrf保护或SOP本身？
谢谢，如果有人能帮助我弄清楚这些混乱。
答案 0 :(得分：1)
现在的问题是，是否没有SOP，是否可以通过一些代码来读取bad.html（在tab1中打开）中的元素输入值，例如document.getElementById（＆＃39; token-id＆ ＃39;）。bad.js中的value（）。
否 - 因为没有对其他标签的引用。
如果正在读取的选项卡是通过window.open从执行读取的选项卡（而不是手动）打开的，则可以读取令牌。
令人高兴的是，同源政策确实存在，所以我们不必担心这一点。
关于发送新交易，银行网站甚至CSRF保护也没有效果，因为脚本可以像用户那样做同样的事情
CSRF令牌包含仅供浏览器和友好站点使用的信息。
由于攻击网站无法读取令牌，攻击网站无法构建包含该令牌的请求。友好站点可以确定攻击站点构建的请求是不可信的，因为它不包含令牌。
如果同源策略不存在，则攻击站点可以读取令牌，这会使令牌无效。
由于同源政策确实存在，这不是一个问题。
答案 1 :(得分：0)
你误解了一些事情，SOP说如果你打开http://bad.com/bad.html并且该页面加载并执行bad.js，那javascript可以向bad.com发出一个AJAX请求，但任何请求除非good.com明确接受（使用CORS协议），否则将阻止指向good.com。
原因是对任何网站的任何请求都可能包含浏览器存储的与该网站相关的cookie，因此bad.com可以使用您未在good.com上关闭的会话来做有害的事情。
所以关于你的问题：不，选项卡不知道其他选项卡，除非它们是相关的（父 - 子），因此页面不能修改另一个选项卡的行为。并且SOP确保页面不能冒充另一个页面