Node.js 中的 `vm` 沙箱逃逸：为什么 `vm.runInNewContext` 不是完全安全的？

各位开发者朋友，大家好！今天我们来深入探讨一个在 Node.js 安全开发中经常被忽视但极其重要的主题——vm 沙箱逃逸问题。你可能听说过 vm 模块用于执行不受信任代码，比如用户提交的脚本、插件系统或动态配置逻辑。然而，如果你以为只要用了 vm.runInNewContext 就万事大吉了，那可就大错特错了。

警告：本文不鼓励也不支持任何恶意行为，而是为了帮助你理解潜在风险并采取正确防御措施。

一、什么是 `vm` 模块？它能做什么？

Node.js 提供了一个内置模块叫做 vm（Virtual Machine），它的设计初衷是让你在一个隔离的环境中运行 JavaScript 代码，从而避免这些代码污染主进程或访问敏感资源。

基础用法示例：

const vm = require('vm');

const script = new vm.Script('const x = 1 + 2; x;');
const context = { foo: 'bar' };

const result = vm.runInNewContext(script, context);
console.log(result); // 输出: 3

在这个例子中：

我们创建了一个脚本对象；
使用 runInNewContext 在一个干净的上下文中执行；
被限制只能访问我们显式传递给它的变量（如 foo）。

看起来很安全？别急，下面才是重点！

二、为什么说 `vm.runInNewContext` 不是“绝对安全”？

很多人误以为只要传入一个空对象作为 context，就能彻底隔离外部环境。但实际上，Node.js 的 vm 模块存在一些底层漏洞和设计缺陷，使得攻击者可以通过巧妙的方式突破沙箱限制。

核心原因总结如下：

原因	描述
原型链污染（Prototype Pollution）	攻击者可以修改全局对象的原型，进而控制所有对象的行为
`global` 对象暴露	即使没有显式绑定，某些操作仍会触发对全局对象的引用
内置函数劫持（Built-in Function Hijacking）	如 `Function.prototype.toString` 可以被重写，导致代码注入
非标准属性泄露（Non-standard Property Exposure）	如 `__proto__` 或 `constructor` 等隐藏属性可能被滥用

下面我们逐个分析这些漏洞，并附上真实可复现的代码演示。

三、案例一：原型链污染 —— 最常见也最危险的逃逸方式

这是目前最流行的 vm 沙箱逃逸手段之一。原理很简单：如果攻击者能修改某个对象的原型（例如 Object.prototype），那么后续所有通过该原型继承的对象都会受到影响，包括那些原本应该只存在于沙箱中的对象。

示例代码（模拟恶意输入）：

const vm = require('vm');

// 构造一个恶意脚本，试图污染 Object.prototype
const maliciousScript = `
  Object.prototype.constructor = function() {
    return global.process;
  };
  Object.prototype.toString = function() {
    return "malicious";
  };
`;

// 创建一个空的上下文
const context = {};

try {
  vm.runInNewContext(maliciousScript, context);

  // 现在尝试构造一个普通对象
  const obj = {};
  console.log(obj.constructor === global.process); // true ❗️

  // 如果攻击者知道这一点，就可以直接获取 process 对象
  const proc = obj.constructor;
  console.log(proc.version); // 输出 Node.js 版本信息，甚至可以调用 spawn 等方法

} catch (err) {
  console.error("Error:", err.message);
}

结果说明：

即使我们没有主动将 process 或其他全局对象放入上下文，攻击者仍然成功地将 Object.prototype.constructor 替换成了 global.process，这意味着任何新对象都会返回 process 实例！

这相当于打开了通往整个 Node.js 进程的大门。

✅ 结论：vm.runInNewContext 并不能阻止原型链污染，尤其是当上下文允许修改对象结构时。

四、案例二：利用 `global` 引用进行逃逸

虽然我们通常认为 vm.runInNewContext 是隔离的，但如果脚本中有类似以下代码：

global.process.exit(0);

或者更隐蔽地：

(function() {
  return this;
})().process.exit(0);

你会发现，这个脚本竟然可以直接访问到全局的 process 对象！

为什么？

因为在 V8 引擎中，this 在严格模式下默认为 undefined，但在非严格模式下会指向 global 对象。而 vm.runInNewContext 默认使用的是非严格模式（除非你明确指定 'use strict'）。

演示代码：

const vm = require('vm');

const dangerousScript = `
  var evil = this;
  if (evil.process) {
    console.log("Found global process!");
    evil.process.exit(1); // 直接退出当前 Node.js 进程！
  }
`;

const context = {};

try {
  vm.runInNewContext(dangerousScript, context);
} catch (err) {
  console.error("Caught error:", err.message);
}

⚠️ 注意：这段代码会在执行时导致 Node.js 主进程崩溃（因为 process.exit() 被调用了）。这就是所谓的“远程代码执行”风险！

📌 修复建议：

显式添加 'use strict'; 到你的脚本开头；
或者使用 vm.createContext() 来创建一个更干净的上下文（但仍不够保险）；

五、案例三：劫持 `Function.prototype.toString` 导致代码注入

这是一个非常隐蔽的问题。V8 引擎中，Function.prototype.toString 方法会被用来序列化函数内容。攻击者可以重写这个方法，让其返回任意字符串，从而伪造合法函数体。

示例：

const vm = require('vm');

// 攻击者篡改 toString 行为
const maliciousScript = `
  Function.prototype.toString = function() {
    return 'return process.env.HOME;';
  };

  const fn = new Function('return 42');
  console.log(fn()); // 你以为返回 42，其实返回的是 env.HOME
`;

const context = {};

try {
  vm.runInNewContext(maliciousScript, context);
} catch (err) {
  console.error("Error:", err.message);
}

此时，即使你没把 process 放进上下文，攻击者也能通过劫持 toString 返回敏感数据！

💡 注意：这种技巧常用于混淆或绕过静态检测工具（如 AST 分析器）。

六、如何真正构建一个“安全”的沙箱？

既然 vm.runInNewContext 不够安全，我们该怎么办？以下是几种推荐做法：

✅ 推荐方案 1：使用 `vm.createContext` + 白名单机制

const vm = require('vm');

function safeRun(code, allowedGlobals = {}) {
  const context = vm.createContext({
    ...allowedGlobals,
    Math: Math,
    Date: Date,
    JSON: JSON,
    setTimeout: setTimeout,
    clearTimeout: clearTimeout,
    // 避免暴露 process / require / fs 等敏感 API
  });

  try {
    const script = new vm.Script(code);
    return script.runInContext(context);
  } catch (err) {
    throw new Error(`Sandbox execution failed: ${err.message}`);
  }
}

// 使用示例
safeRun('Math.random()', {});

这种方式比 runInNewContext 更可控，因为你明确指定了哪些全局变量可用。

✅ 推荐方案 2：结合 `vm` 和 `worker_threads`（适用于复杂场景）

对于更高要求的安全性（如插件系统、在线编译器等），建议配合 worker_threads 使用，这样每个脚本都在独立线程中运行，物理隔离更强。

const { Worker } = require('worker_threads');

function runInWorker(code) {
  return new Promise((resolve, reject) => {
    const worker = new Worker(`
      const vm = require('vm');
      const script = new vm.Script(`${code}`);
      try {
        const result = script.runInNewContext({});
        postMessage({ success: true, result });
      } catch (err) {
        postMessage({ success: false, error: err.message });
      }
    `);

    worker.on('message', (msg) => {
      if (msg.success) resolve(msg.result);
      else reject(new Error(msg.error));
    });
  });
}

这种方法可以有效防止内存泄漏和跨线程污染。

⚠️ 不推荐方案：单纯依赖 `vm.runInNewContext` + 空对象

vm.runInNewContext('some risky code here', {}); // ❌ 危险！

这不是真正的安全，只是“看起来安全”。

七、对比表格：不同沙箱策略安全性评估

方案	是否隔离	是否可被原型污染	是否可访问全局对象	是否推荐
`vm.runInNewContext({}, {})`	❌ 否	✅ 是	✅ 是	❌ 不推荐
`vm.createContext({})` + 白名单	✅ 是	✅ 有限	✅ 有限	✅ 推荐
`worker_threads` + `vm`	✅ 强隔离	❌ 否	❌ 否	✅ 强烈推荐
`eval()` 或 `new Function()`	❌ 否	❌ 否	❌ 否	❌ 绝对禁止

八、总结与最佳实践建议

🔍 总结：

vm.runInNewContext 并不是万能的“安全盾牌”，它容易受到原型链污染、全局对象访问、函数劫持等攻击。
它的设计初衷是“轻量级隔离”，而非“强安全防护”。
如果你要处理不可信代码，请务必采用组合策略：白名单 + 上下文控制 + 必要时多线程隔离。

🛡️ 最佳实践清单：

类型	建议
输入验证	对用户提供的脚本做语法检查（如 AST 分析）
上下文限制	使用 `vm.createContext` 显式定义可用对象
函数保护	防止 `Function.prototype.toString` 被篡改（可通过 freeze 或代理拦截）
日志监控	记录每次沙箱执行的结果，便于事后审计
外部依赖	若需访问文件系统、网络等，应在沙箱外封装接口，而非开放权限
定期更新	Node.js 的 `vm` 模块也在持续改进，保持版本最新很重要

最后送给大家一句话：

“沙箱不是魔法，它是责任。”
—— 安全从来不是靠单一技术实现的，而是由架构设计、代码审查、持续测试共同构筑的防线。

希望这篇文章帮你看清了 vm 沙箱的真实边界。下次当你再考虑用 vm.runInNewContext 来跑用户脚本时，请先问自己：“我是否真的了解它的局限？”

谢谢阅读！

Node.js 中的 vm 沙箱逃逸：为什么 vm.runInNewContext 不是完全安全的？

一、什么是 vm 模块？它能做什么？