关于同源策略（sop）和 csrf 保护的混淆答案

【问题标题】：A confusion about same origin policy(sop) and csrf protection关于同源策略（sop）和 csrf 保护的混淆
【发布时间】：2017-03-23 03:01:53
【问题描述】：

我对同源政策 (SOP) 感到困惑。

例如，http://bad.com/bad.html 带有 bad.js，http://good.com/good.html 带有 good.js。我用两个选项卡（tab1 和 tab2）在我的 chrome 中打开两个 url。

good.html(在tab2中打开)中有一个元素<input id="token-id" type='text' name='token' value='123abc'>

现在的问题是如果没有SOP，是否可以使用@987654329 中的document.getElementById('token-id').value() 之类的代码从bad.html（在tab1 中打开）中读取元素input 值@。

另外一个问题是如果上面的问题的答案是'否'，我在wikihttps://en.wikipedia.org/wiki/Same-origin_policy#Security_Concerns这句话看不懂。

关于新交易的发送，即使是银行网站的 CSRF 保护也没有效果，因为脚本可以简单地像用户一样做

因为我们无法获得 csrf 令牌。为什么它不起作用。服务器可以通过验证 csrf 令牌来确定真正的 post 请求。

我是否误解了 csrf 保护或 SOP 本身？

感谢谁能帮我解决这些困惑。

【问题讨论】：

标签： javascript same-origin-policy csrf-protection

【解决方案1】：

现在的问题是，如果没有 SOP，是否可以使用 document.getElementById('token-id').value() 之类的代码从 bad.html（在 tab1 中打开）读取元素输入值坏.js。

否 - 因为没有引用另一个选项卡。

如果正在读取的选项卡是通过 window.open 从正在读取的选项卡中打开的（而不是手动），则可以读取令牌。

幸运的是，同源政策确实存在，因此我们无需担心。

关于新交易的发送，即使是银行网站的 CSRF 保护也没有效果，因为脚本可以简单地像用户一样做

CSRF 令牌包含仅对浏览器和友好站点可用的信息。

由于攻击站点无法读取令牌，因此攻击站点无法构造包含它的请求。友好站点可以确定攻击站点构造的请求是不可信的，因为它不包含令牌。

如果不存在同源策略，那么攻击站点可以读取令牌，这会使令牌变得无用。

由于确实存在同源政策，这不是问题。

【讨论】：

首先，非常感谢。因此，只有一种情况是我通过单击http://bad.com 中的链接打开http://good.com/good.html。然后令牌将被bad.js 在http://bad.com 中读取。如果没有这种情况，即使没有 SOP，令牌也应该有用。对吗？

【解决方案2】：

您误解了一些事情，SOP 说如果您打开 http://bad.com/bad.html 并且该页面加载并执行 bad.js，则 javascript 可以向 bad.com 发出 AJAX 请求，但任何指向 good.com 的请求都会除非good.com 明确接受（通过使用 CORS 协议），否则将被阻止。

原因是对任何站点的任何请求都可能包含浏览器存储的与该站点相关的 cookie，因此 bad.com 可能会使用您未在 good.com 上关闭的会话来做一些有害的事情。

所以关于你的问题：不，一个标签不知道其他标签，除非它们是相关的（父 - 子），所以一个页面不能修改另一个页面的行为。并且 SOP 确保一个页面不能冒充另一个页面

【讨论】：

"任何指向 good.com 的请求都将被阻止" — 不正确。只有复杂的请求才会被阻止。简单的请求会通过，但响应会被 JS 拒绝。
@Pablo 首先，非常感谢。相关标签是否意味着一个标签被另一个标签通过window.open函数打开？
@VincentQiu 是的，就是这样。