为什么用户脚本管理器仍然支持使用 unsafeWindow？答案

【问题标题】：Why do userscript managers still suport the use of unsafeWindow?为什么用户脚本管理器仍然支持使用 unsafeWindow？
【发布时间】：2023-03-02 23:40:02
【问题描述】：

unsafeWindow API 是为了让用户脚本可以与脚本执行的页面的变量和函数进行交互。但是，强烈建议不要这样做，因为网站可能会通过unsafeWindow 劫持用户脚本并使其执行恶意代码。但是，为什么unsafeWindow 甚至是必要的，为什么仍然使用它？在 Firefox 39 之前，用户可以使用位置黑客来替代unsafeWindow。由于 Firefox 39 中的更新修复了这个问题，这个黑客最终停止了工作。尽管如此，用户仍然可以在隔离的沙箱中使用 GM API，并通过这样的脚本标签插入代码：

const fnToRunOnNativePage = () => {
  console.log('fnToRunOnNativePage');
};

const script = document.body.appendChild(document.createElement('script'));
script.textContent = '(' + fnToRunOnNativePage.toString() + ')();';
// to use information inside the function that was retrieved elsewhere in the script,
// pass arguments above
script.remove();

我从这个 stackoverflow 帖子中得到了这段代码：How do I make my userscript execute code in isolated sandbox and unsafeWindow too?

那么为什么unsafeWindow 仍然可用？上面的代码几乎是unsafeWindow 的完美替代品。另外作为旁注，unsafeWindow 在 Greasemonkey 和 Tampermonkey 中的运行方式有什么不同吗？谢谢。

外部资源：

【问题讨论】：

标签： javascript browser sandbox execution userscripts

【解决方案1】：

让我们调用<script>标签的创建并将其插入到页面中脚本注入。

脚本注入有一些缺点。引用Brock Adams:

脚本，至少是注入的部分，不能使用GM_函数提供的增强权限（尤其是跨域）——尤其是GM_xmlhttpRequest()。

可能会导致副作用或与页面的 JS 冲突。

使用外部库会引入更多的冲突和计时问题。它远没有 @require 简单。
@require 还可以从本地副本运行外部 JS —— 加快执行速度，几乎消除了对外部服务器的依赖。

该页面可以查看、使用、更改或阻止脚本。

需要启用 JS。特别是 Firefox Greasemonkey 可以在 JS 被阻止的页面上运行。这对于臃肿、蹩脚和/或侵入性的页面来说可能是天赐之物。

因此，一些开发人员可能更喜欢使用unsafeWindow 而不是使用脚本注入。删除 unsafeWindow 会让他们更难。

unsafeWindow 通常可以正常工作，而且它比创建和注入脚本标签要简单。

另一个问题是，在网络上，向后兼容性经常是最重要的因素之一，即使有，也很少放弃。如果某些东西在 2015 版本中有效，则一般理念是它也应该在 2020 版本中有效，而不需要在 2015 版本上工作的人回来修复它（因为他们可能不再这样做了） . Related discussion here。虽然用户脚本管理器必须像网络上的其他东西一样关心向后兼容性，但同样的推理也适用 - 避免破坏当前工作的东西，除非你真的有一个 很好的理由。

【讨论】：

【解决方案2】：

除了CertainPerformance 的出色解释之外，unsafeWindow 被简单地实现为window.wrappedJSObject 的别名。

作为一名脚本管理器开发人员，我最初反对unsafeWindow 的实现，但后来为了兼容性不得不添加它。

出于安全原因，现代浏览器将扩展程序注入的 JavaScript 与网页 JavaScript 分开。

与扩展程序自己的脚本相比，Firefox 进一步使用专用的用户脚本 API 来进一步限制用户脚本（即第 3 方脚本）的访问。

在这些分离的范围/上下文（页面、扩展名、用户脚本）之间架桥会增加安全问题。

但是，有时需要这种交互来覆盖（不受欢迎的）页面 JavaScript，这可能是一件好事，或者获取存储在页面 JavaScript 中的数据。

总之，虽然unsafeWindow 会产生不安全网桥的可能性，但它并不是一个新网桥，window.wrappedJSObject 已经可以使用相同的访问权限。

【讨论】：