ScriptCat沙盒环境下window与unsafeWindow的行为差异分析

ScriptCat沙盒环境下window与unsafeWindow的行为差异分析

scriptcat 脚本猫，一个可以执行用户脚本的浏览器扩展 项目地址: https://gitcode.com/gh_mirrors/sc/scriptcat

在ScriptCat脚本管理器的开发过程中，我们发现了一个关于沙盒环境下window与unsafeWindow对象访问行为的有趣问题。这个问题涉及到脚本管理器如何隔离用户脚本与页面原生环境的交互，是脚本安全机制中的重要一环。

问题背景

在用户脚本开发中，unsafeWindow是一个特殊对象，它允许脚本绕过沙盒限制直接访问页面的原生window对象。而普通的window对象则应该被沙盒代理，只能访问脚本管理器提供的安全环境。

然而在ScriptCat的早期实现中，我们发现即使用户脚本声明了@grant unsafeWindow，通过window对象仍然可以访问到页面原生的全局变量（如示例中的Quill对象），这与主流脚本管理器的行为表现不一致。

技术分析

预期行为

在标准的用户脚本环境中，沙盒机制应该保证：

1. 当脚本未声明unsafeWindow时，window对象完全被沙盒代理
2. 当脚本声明unsafeWindow后：
   • unsafeWindow指向页面原生window对象
   • window仍然保持沙盒代理状态，不应直接暴露原生环境

ScriptCat的原始实现问题

通过测试发现，ScriptCat的原始实现存在以下问题：

1. 在沙盒环境中，即使声明了unsafeWindow，通过window对象仍能访问到页面原生属性
2. 更奇怪的是，直接访问全局变量（如Quill）也能绕过沙盒限制获取到原生对象
3. 这种行为可能导致安全风险，因为脚本可能无意中绕过沙盒保护

主流脚本管理器对比

我们对几种主流脚本管理器进行了对比测试：

1. 主流管理器A：表现符合预期，window保持沙盒状态
2. 主流管理器B：在同步代码中表现与主流管理器A一致，但在setTimeout等异步代码中行为有所不同
3. ScriptCat原始版本：window和unsafeWindow都能访问原生环境

解决方案

ScriptCat团队通过修改沙盒实现，确保了以下行为：

1. 严格区分window和unsafeWindow的作用域
2. 确保window始终指向沙盒代理对象
3. 只有通过unsafeWindow才能访问页面原生环境
4. 修复了直接访问全局变量绕过沙盒的问题

技术实现要点

这个修复涉及到ScriptCat沙盒机制的核心部分：

1. 改进了作用域链的处理方式
2. 确保全局变量访问被正确拦截
3. 保持了与主流管理器的行为一致性
4. 通过完整的单元测试验证修改的正确性

对开发者的影响

对于ScriptCat用户脚本开发者来说，这一变更意味着：

1. 脚本行为将更加符合预期
2. 需要明确区分安全环境(window)和危险环境(unsafeWindow)
3. 提高了脚本的兼容性和可移植性
4. 增强了脚本的安全性

总结

这个问题的修复体现了ScriptCat团队对脚本安全机制的重视。通过确保沙盒环境的严格隔离，ScriptCat为用户脚本提供了更安全、更可靠的执行环境，同时也保持了与主流脚本管理器的行为一致性。这对于提升ScriptCat的整体质量和开发者体验具有重要意义。

scriptcat 脚本猫，一个可以执行用户脚本的浏览器扩展 项目地址: https://gitcode.com/gh_mirrors/sc/scriptcat