什么是Javascript的沙箱环境_如何安全地执行第三方Javascript代码?

JavaScript沙箱本质是隔离执行上下文,通过切断隐式访问路径实现安全,vm2是Node.js中最成熟的方案,而浏览器端仅能尽力防护。

JavaScript 沙箱环境的本质是隔离执行上下文

它不是浏览器内置的“沙箱 API”,而是通过语言机制人为构造一个没有访问全局对象(windowglobalThis)、无 DOM、无 eval、无 Function 构造器的受限执行环境。真正的安全不靠“禁用某几个函数”,而在于切断所有默认隐式访问路径。

vm2 创建可配置的 Node.js 沙箱

vm2 是目前最成熟、持续维护的沙箱库,比原生 vm 模块更严格(原生 vm 存在原型污染绕过风险)。关键点在于:必须显式传入白名单对象,且不能让沙箱内代码拿到任何原始引用。

  • 安装:npm install vm2
  • 禁止 requireprocessglobal 等所有危险全局项
  • 若需提供工具函数(如 JSON.parse),必须深拷贝或重写,避免原型链泄露
  • 设置超时:timeout 参数防死循环,但注意它无法中断正在执行的同步长任务(需配合 maxHeapSize 限制内存)
const { VM } = require('vm2');
const vm = new VM({
  timeout: 1000,
  sandbox: {
    console: { log: (...args) => console.log('[sandbox]', ...args) },
    Math,
    JSON
  }
});

try {
  vm.run('console.log(JSON.stringify({a: 1})); Math.random()'); // ✅ 安全
  vm.run('process.exit()'); // ❌ 报错:ReferenceError: process is not defined
} catch (e) {
  console.error(e.message);
}

浏览器端无法真正沙箱化,只能降级为“尽力防护”

浏览器没有等价于 vm2 的安全机制。iframe + sandbox 属性看似可行,但第三方脚本仍可通过 postMessage 与父页通信,且一旦获得 documentwindow 引用,隔离即失效。

  • 禁止 DOM 访问,但脚本仍可执行计算、发起 fetch(若未加 allow-network 则失败)
  • 不要信任 eval + with 的手工沙箱——ES6 之后 with 在严格模式下被禁用,且极易被 Object.prototype.constructor 绕过
  • 若必须解析表达式(如公式引擎),用专用 parser(如 expr-eval),而非执行任意 JS

为什么不用 Web Workers

Worker 确实隔离了 DOM 和 window,但它仍共享 self(即 WorkerGlobalScope),而该对象包含 importScriptsfetchatob 等高危 API,且无法像 vm2 那样精细控制暴露哪些属性。更重要的是:Worker 无法拦截或重写 Function 构造器,恶意代码仍可动态生成并执行字符串代码。

真正难处理的从来不是语法层面的“执行”,而是如何阻止对宿主状态的读写——比如一段代码不报错、不发请求,却悄悄把 localStorage 里的 token 复制到 self.x = localStorage.token,再通过 postMessage 带出去。这类侧信道行为,没有运行时深度监控就无法防御。