使用JavaScript Function构造器实现用户代码沙箱的可行性咨询

你的当前实现存在大量可被绕过的安全漏洞，完全不足以拦截恶意用户代码的逃逸行为，核心问题如下：

• 关键字黑名单检测完全不可靠：JS支持字符串动态拼接、编码转换等语法，比如恶意代码可以通过"th"+"is"、String.fromCharCode(116,104,105,115)等方式构造被你禁用的关键字，完全绕开静态检测逻辑。
• 全局对象遮蔽不完整且可绕过：你仅遮蔽了globalThis、window、document三个变量，还有上百个全局API（fetch、XMLHttpRequest、localStorage、Function等）完全暴露给用户代码，哪怕你补全了遮蔽列表，用户也可以通过原型链拿到原生构造器实现逃逸，比如通过{}.constructor.constructor就能拿到全局的Function构造器，自行构造恶意代码执行。
• 遮蔽逻辑本身存在漏洞：你写的const globalThis = window = document = {}赋值逻辑中，对原生window的赋值会因为原生对象不可写直接抛出错误，无法完成遮蔽效果。

可行的改进建议 #

• 优先使用浏览器原生隔离方案：创建设置了sandbox="allow-scripts"的独立iframe，禁用所有其他权限，且iframe加载独立的跨域页面，用户代码完全在iframe内运行，仅通过postMessage和主页面传递你允许交互的API数据，不要直接传递真实的API对象，从环境层面完全隔离主页面上下文。
• 不要自行实现沙箱逻辑：如果需要在当前上下文执行代码，选用业内成熟的沙箱库，这类库会从底层拦截对象访问、原型链操作，从根本上避免代码逃逸，远优于自行实现的黑名单+变量遮蔽逻辑。
• 彻底放弃关键字黑名单检测的思路：JS语法的灵活性决定了静态关键字检测不可能覆盖所有绕过方式，不要在这类逻辑上浪费开发精力。

内容的提问来源于stack exchange，提问作者toyknight