网页是否有可能检测或以其他方式了解同一浏览器中的其他选项卡，甚至其他浏览器中的其他打开网页正在执行或传输的操作？
我非常了解 cookie，以及它们存储网络开发人员放置的信息以供本地使用的能力。这个链接和这个链接也很有帮助，虽然我不是特别喜欢 Chrome，而且我不仅仅是在询问扩展。我也知道，使用受感染的机器或浏览器，一切皆有可能。
我担心的是，由于营销和所有其他促进广泛信息收集（合法或其他）的原因，网站可能希望通过到达其浏览器选项卡之外尝试收集有关任何和所有使用的信息，可以这么说. 使用沙盒标签，这似乎不太可能，但我相信有办法解决这个问题（如果尚未发现）。对于一家公司来说，定期这样做肯定会被认为是邪恶的，并且可能是非法的，但这并没有阻止许多公司尽其所能获得优势，或利用用户的无知。明确一点：我并不是指对用户浏览器的全面实时主动黑客攻击。只是数据“泄露”，可以这么说。
有时我更喜欢在一个浏览器中进行银行业务并在另一个浏览器中购物，因为担心中央软件（浏览器）可能会允许某种类型的串扰。我认为这可能是不必要的。如果无法做到这一点，请描述浏览器中除了沙盒之外还有哪些安全措施。如果可能的话，我正在寻找软件级别的详细信息，或者除了我在上面发布的链接之外的任何其他相关信息……但不想在另一个 SE 网站上发布，例如StackO。谢谢你。
浏览器和选项卡之间的信息传输
信息安全
网页浏览器
脆弱性
沙盒
2021-08-19 23:15:57
2个回答
很难回答，因为我们在这里可以有很多视野。
简短的回答：
我将以您的银行为例。
假设您打开一个新标签并在 your-bank.com 上输入。
如果您的银行没有明确开发任何代码来与其他选项卡进行通信，则没有其他选项卡可以说明您正在浏览您的银行以及您在那里做什么。*
EXCEPT如果恶意标签使用浏览器漏洞（0天），这是非常昂贵的，罕见的，极其非法的。
- 我不认为您通过其他网站点击了 your-bank.com，并且我认为您的计算机中没有任何浏览器扩展程序/插件或恶意软件。
(...) 请描述浏览器中除了沙盒之外还有哪些保护措施
同源政策（SOP）：
“在计算中，同源策略是 Web 应用程序安全模型中的一个重要概念。该策略允许在源自同一站点的页面上运行的脚本（方案、主机名和端口号1的组合）访问彼此的 DOM没有特定限制，但阻止访问不同站点上的DOM。1同源策略也适用于 XMLHttpRequests，除非服务器提供 Access-Control-Allow-Origin (CORS) 标头。值得注意的是，WebSockets 不受相同-原产地政策。
这种机制对于广泛依赖 HTTP cookie 来维护经过身份验证的用户会话的现代 Web 应用程序具有特殊的意义，因为服务器基于 HTTP cookie 信息来显示敏感信息或采取改变状态的操作。客户端必须严格区分无关站点提供的内容，以防止丢失数据机密性或完整性。”
来自维基百科 ( http://en.wikipedia.org/wiki/Same-origin_policy )。
编辑：
关于这篇文章的注意事项（我将再次以您的银行为例）：
document.domain 方法
在这里我们可以假设 subdomain.attacker.com 可以与 subdomain.attacker.com 和attacker.com 对话。但是 subdomain.attacker.com 不可能与 your-bank.com 甚至 subdomain.your-bank.com 对话。
为什么？attack.com 无法将其 document.domain 设置为 your-bank.com。
跨域资源共享方法
在这里，您的银行需要明确允许与攻击者.com 进行跨域资源共享，因为默认情况下不允许。
易受攻击域的设置：
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, DELETE, PUT
window.postMessage 方法（或 JSONP 等）
同样，您的银行需要明确允许通过 javascript postMessage 进行通信。
我的结论：
如今，同源政策非常可靠，但就像任何事情一样，它并非完美无缺。
但如果你能在 Chrome 或 Firefox 的同源策略实现中发现任何缺陷（如 U-XSS 等），你将获得丰厚的奖励。
因此，要找到错误并不容易。
Mozilla 和 Chrome 漏洞赏金计划：
http://www.google.com/about/appsecurity/chrome-rewards/
https://www.mozilla.org/en-US/security/bug-bounty/
关于一些旧的同源政策弱点的文章：
http://powerofcommunity.net/poc2008/kuza55.pdf
这是防止标签/浏览器串扰的唯一浏览器内机制/防御吗？
是的，它（同源策略）是防止跨域对话的唯一机制。
编辑2：
您在上面详述的漏洞是在浏览器关闭期间持续存在，还是仅影响同时连接？
两个都！我们可以有持久性和非持久性的漏洞利用。
三年前，Daniel Divricean 报告了这种非持久性漏洞利用。攻击者可以读取其他网站的信息，例如您的银行余额，但前提是您之前曾登录过您的银行。在这种情况下，关闭恶意站点将阻止攻击。
一年前，我向谷歌报告了这个持续存在的漏洞。攻击者可以使用它在受害者的浏览器上安装恶意扩展，而无需用户交互和知识。在这种情况下，关闭恶意站点不会阻止攻击。
那么登录银行网站 -> 注销 -> 关闭浏览器 -> 打开漏洞利用站点 -> 关闭浏览器 -> 登录银行...现在安全吗？
更安全，而不是完全安全。
除了Lucas NN的出色回答之外，还有Cross Site Request Forgery的威胁。
CSRF 不需要在浏览器中打开当前选项卡，只需要有效会话。因此，如果您登录 Facebook 并且 Facebook 恰好包含 CSRF 漏洞，并且您碰巧访问了利用此漏洞的恶意网站，那么您的 Facebook 帐户可能会被盗用。这是在另一个浏览器或隐身选项卡中打开敏感站点的好案例，该选项卡不与普通浏览器选项卡共享身份验证机制（例如身份验证 cookie）。即便如此，人们仍希望银行网站能够抵御此类攻击。