关于同源策略（sop）和 csrf 保护的混淆
A confusion about same origin policy(sop) and csrf protection
我对同源策略 (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，是否可以使用 bad.html（在 tab1 中打开）读取元素 input 的值bad.js.
中的一些代码，例如 document.getElementById('token-id').value()
另一个问题是如果上面问题的答案是'no'，我在wiki里看不懂这句话https://en.wikipedia.org/wiki/Same-origin_policy#Security_Concerns.
Regarding the sending of new transactions, even CSRF protections by the banking site have no effect, because the script can simply do the same as the user would do
因为我们无法获取 csrf 令牌。为什么它不起作用。服务器可以通过验证 csrf 令牌来确定真正的 post 请求。
我是否误解了 csrf 保护或 SOP 本身？
如果有人能帮我解决这些困惑，谢谢。
Now the question is if there is no SOP, whether it's possible to read the element input value from bad.html(opened in tab1) with some code like document.getElementById('token-id').value() in bad.js.
否 — 因为没有引用其他选项卡。
如果正在读取的选项卡是通过 window.open 从执行读取的选项卡（而不是手动）打开的，则可以读取令牌。
幸运的是，同源政策确实存在，所以我们不必担心。
Regarding the sending of new transactions, even CSRF protections by the banking site have no effect, because the script can simply do the same as the user would do
CSRF 令牌包含仅供浏览器和友好站点使用的信息。
由于攻击站点无法读取令牌，因此攻击站点无法构建包含它的请求。友好站点可以确定攻击站点构造的请求不可信，因为它不包含令牌。
如果不存在同源策略，则攻击站点可以读取令牌，这将使令牌变得无用。
由于同源策略确实存在，所以这不是问题。
您误解了一些事情，SOP 说如果您打开 http://bad.com/bad.html 并且该页面加载并执行 bad.js，那么 javascript 可以发出 AJAX 请求bad.com，但任何指向 good.com 的请求都将被阻止，除非 good.com 明确接受它（通过使用 CORS 协议）。
原因是对任何站点的任何请求都可能包含浏览器存储的与该站点相关的 cookie，因此 bad.com 可以使用您在 good.com 上未关闭的会话来做一些有害的事情。
所以关于你的问题：不，一个选项卡不知道其他选项卡，除非它们是相关的（父 - 子），所以一个页面不能修改另一个页面的行为。并且 SOP 确保一个页面不能冒充另一个页面
我对同源策略 (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，是否可以使用 bad.html（在 tab1 中打开）读取元素 input 的值bad.js.
document.getElementById('token-id').value()
另一个问题是如果上面问题的答案是'no'，我在wiki里看不懂这句话https://en.wikipedia.org/wiki/Same-origin_policy#Security_Concerns.
Regarding the sending of new transactions, even CSRF protections by the banking site have no effect, because the script can simply do the same as the user would do
因为我们无法获取 csrf 令牌。为什么它不起作用。服务器可以通过验证 csrf 令牌来确定真正的 post 请求。
我是否误解了 csrf 保护或 SOP 本身？
如果有人能帮我解决这些困惑，谢谢。
Now the question is if there is no SOP, whether it's possible to read the element input value from bad.html(opened in tab1) with some code like document.getElementById('token-id').value() in bad.js.
否 — 因为没有引用其他选项卡。
如果正在读取的选项卡是通过 window.open 从执行读取的选项卡（而不是手动）打开的，则可以读取令牌。
幸运的是，同源政策确实存在，所以我们不必担心。
Regarding the sending of new transactions, even CSRF protections by the banking site have no effect, because the script can simply do the same as the user would do
CSRF 令牌包含仅供浏览器和友好站点使用的信息。
由于攻击站点无法读取令牌，因此攻击站点无法构建包含它的请求。友好站点可以确定攻击站点构造的请求不可信，因为它不包含令牌。
如果不存在同源策略，则攻击站点可以读取令牌，这将使令牌变得无用。
由于同源策略确实存在，所以这不是问题。
您误解了一些事情，SOP 说如果您打开 http://bad.com/bad.html 并且该页面加载并执行 bad.js，那么 javascript 可以发出 AJAX 请求bad.com，但任何指向 good.com 的请求都将被阻止，除非 good.com 明确接受它（通过使用 CORS 协议）。
原因是对任何站点的任何请求都可能包含浏览器存储的与该站点相关的 cookie，因此 bad.com 可以使用您在 good.com 上未关闭的会话来做一些有害的事情。
所以关于你的问题：不，一个选项卡不知道其他选项卡，除非它们是相关的（父 - 子），所以一个页面不能修改另一个页面的行为。并且 SOP 确保一个页面不能冒充另一个页面