Node.js child_process模块执行命令的输入净化

在Node.js后端开发中，通过child_process模块调用系统命令是极其常见的需求，比如压缩图片、调用外部脚本、执行系统工具等。但一旦命令字符串中拼接了用户输入，风险就呈指数级上升。攻击者可以通过精心构造的输入注入额外命令，导致服务器沦陷、数据泄露。问题的核心不在于child_process本身，而在于开发者是否对传入的参数做了充分的净化。下面直接拆解具体的风险场景和可落地的防御方案。

child_process提供了exec、execSync、spawn、spawnSync、execFile、fork等API。其中exec和execSync默认启动一个shell来解析命令字符串，这意味着如果用户输入被直接拼接到命令里，shell元字符（如分号、管道符、反引号等）会被解析执行。spawn和execFile默认不启动shell，但如果options.shell设为true，同样面临注入风险。很多开发者误以为spawn天然安全，实际上如果参数数组中的某个元素被shell解析，或者命令本身由用户控制，风险依然存在。

假设一段代码接收用户输入的文件名，然后调用系统命令进行转换：

const { exec } = require('child_process');
const userInput = req.body.filename;
exec(`convert ${userInput} output.pdf`, (err, stdout, stderr) => {
  // 处理结果
});

如果userInput是"image.jpg; rm -rf /"，整个命令变为"convert image.jpg; rm -rf / output.pdf"，分号后的恶意指令会被执行。更隐蔽的攻击还可以使用反引号、$()进行命令替换，或通过&&、||链接命令。exec的shell解析特性使得任何未净化的用户输入都可能成为突破口。

spawn默认以参数数组形式传递，不经过shell解析，确实能防御大部分元字符注入。但如果开发者错误地将用户输入作为命令名，或者开启了shell选项，风险依然存在：

const { spawn } = require('child_process');
// 危险：用户控制命令名
const cmd = req.body.tool;
spawn(cmd, ['--output', 'result.txt']);

// 危险：开启shell
spawn('echo', [userInput], { shell: true });

当shell为true时，参数仍可能被shell解析。此外，某些命令自身可能存在参数注入，比如git、find等工具支持通过参数执行额外操作，这需要针对具体命令做白名单校验。

execFile直接执行可执行文件，不经过shell，比exec安全得多。但它要求命令路径是绝对路径或仅文件名（从PATH查找），且参数以数组传递。如果用户能控制命令文件路径，同样危险。execFile适合执行固定命令、仅参数变化的情况。

净化不是简单的黑名单过滤，而应该采用多层防御。第一层是严格的白名单校验，只允许符合预期的字符通过。第二层是参数化调用，避免拼接命令字符串。第三层是权限最小化，限制执行环境的能力。具体方法包括：

1. 对用户输入做严格的正则验证。例如文件名只允许字母、数字、下划线、连字符和点号，且长度限制在合理范围：

const isValidFilename = (input) => /^[a-zA-Z0-9_.-]{1,255}$/.test(input);

2. 使用path模块规范化路径，防止目录穿越。path.resolve或path.normalize可以消除"../"等相对路径符号，但需注意其不能完全防御，仍需配合白名单。

3. 转义shell特殊字符。如果必须使用exec，需要对用户输入进行转义。Node.js没有内置的shell转义函数，但可以使用第三方库如shell-quote，或手动用单引号包裹并转义内部的单引号。不过手动转义容易遗漏边界情况，不推荐作为主要方案。

4. 优先使用spawn或execFile，并确保不开启shell选项。将命令和参数严格分离，参数以数组形式传入。

当命令的参数值来自用户时，不要直接将用户输入作为参数，而是建立映射表。例如用户选择图片尺寸，后端维护一个允许的尺寸列表：

const ALLOWED_SIZES = {
  small: '300x300',
  medium: '600x600',
  large: '1200x1200'
};
const size = ALLOWED_SIZES[req.body.size] || 'medium';
spawn('convert', ['input.jpg', '-resize', size, 'output.jpg']);

这样即使攻击者传入任意值，也只会回退到默认值，不会注入恶意参数。对于更复杂的场景，可以将用户输入限制为枚举值，彻底杜绝注入可能。

执行外部命令时，应显式设置cwd和env选项，限制命令的工作目录和环境变量。不要继承完整的process.env，而是只传递必要的环境变量：

spawn('mycommand', args, {
  cwd: '/safe/directory',
  env: { PATH: '/usr/bin', HOME: '/tmp' }
});

这可以防止命令访问敏感文件或通过环境变量执行非预期操作。同时，设置timeout选项避免命令长时间挂起耗尽资源。

对于spawn和execFile，确保shell选项为false（默认值）。如果业务确实需要shell特性，考虑用更安全的替代方案。对于可能受参数注入影响的命令，需要额外校验参数内容。例如git log的--format参数可能被注入，应对参数值做严格正则匹配，或使用--结束选项解析：

spawn('git', ['log', '--format=' + sanitizedFormat, '--']);

双横线告诉命令后续内容不再作为选项解析，能有效防御选项注入。

社区已有成熟的安全执行库，如execa，它默认不启用shell，提供了更友好的API和更好的错误处理。execa还会自动转义参数，并支持Promise和流式输出。但即使使用execa，仍需注意命令本身和参数的白名单控制，不能完全依赖库的默认行为。

净化输入的同时，也要处理命令的输出。避免将命令的stdout或stderr直接返回给用户，可能泄露服务器路径、内部信息。对输出做脱敏处理，或仅返回必要的处理结果。另外，限制输出大小，防止命令输出大量数据撑爆内存：

const child = spawn('cmd', args, { maxBuffer: 1024 * 1024 });

即使应用层做了充分净化，仍建议将执行外部命令的服务运行在容器或沙箱环境中，并限制文件系统权限、网络访问和系统调用。结合Linux的seccomp、AppArmor或Docker的安全配置，可以构建纵深防御。一旦应用层防御被突破，系统级隔离能大幅降低损失。

记录所有通过child_process执行的命令及其参数，便于事后审计。监控异常命令执行模式，如短时间内大量命令、执行不常见的系统工具等。结合告警机制，及时发现潜在攻击。日志中应避免记录敏感信息，如密码、token等。

真实漏洞报告中，大量Node.js应用因未净化exec参数导致远程命令执行。例如某CMS系统的图片处理接口，将用户上传的文件名直接传入exec调用ImageMagick，攻击者利用文件名中的反引号执行任意命令，最终获取服务器控制权。这类漏洞的修复无一例外都是改用spawn+参数数组，并增加白名单校验。

1. 永远不要将用户输入直接拼接到命令字符串中。

2. 优先使用spawn或execFile，保持shell为false。

3. 对用户输入做严格白名单验证，限制字符集和长度。

4. 使用参数映射表代替直接传参。

5. 显式设置cwd、env和timeout，限制执行环境。

6. 结合容器隔离和系统级安全策略。

7. 记录审计日志，监控异常行为。

输入净化不是一次性工作，而是贯穿整个开发生命周期的安全实践。每次调用child_process时，都应该审视参数来源，确保没有给攻击者留下可乘之机。