假设你正在维护一个文件转换服务，用户上传图片后，后端需要调用ImageMagick执行格式转换。最简单的实现可能是把文件名拼进命令字符串：convert user_upload.jpg output.png。如果用户把文件名改成了test.jpg; rm -rf /，而代码里用的是system()或exec()，系统会把分号后面的内容也当作命令执行。这类问题就是命令注入，本质上是不可信数据进入了shell解释器的控制流。
很多人第一反应是过滤特殊字符，比如把分号、管道符、反引号都替换成空字符串。但现实中的shell语法非常复杂，换行符、环境变量引用、通配符、命令替换$(...)都能绕过简单过滤。更麻烦的是Windows下的cmd和PowerShell又有另一套转义规则，想靠黑名单堵住所有可能永远追不上攻击者的想象力。正确的方向不是跟shell语法对抗，而是让数据永远不进入shell语法层。
命令注入的根源：shell解析与字符串拼接
绝大多数编程语言都提供了两种执行外部程序的方式。一种是把整个命令字符串交给shell处理，比如C的system()、Python的os.system()、Node.js的child_process.exec()。这些函数内部会启动一个shell进程（Linux上是/bin/sh -c，Windows上是cmd /c），然后由shell负责解析引号、管道、重定向、命令分隔符等。用户输入只要包含shell元字符，就可能改变命令的解析结果，造成注入。
另一种方式是直接通过参数数组启动进程，不经过shell。比如C的execve()、Python的subprocess.run()配合列表参数、Node.js的child_process.spawn()或execFile()。这类函数把第一个参数当成可执行文件路径，把后续参数当成独立的argv元素，直接交给操作系统内核，shell元字符不会再被解释。同样的用户输入test.jpg; rm -rf /，在这种方式下只会变成一个完整的文件名参数，不会执行rm。这就是参数化的核心思想：数据和指令彻底分离。
SQL注入的解决方案里，参数化查询把SQL语句结构和用户数据分开，数据库驱动负责转义或使用预编译语句。命令注入里的参数化原理完全相同，只不过转义工作交给了进程创建机制本身。但有个重要区别：SQL有通用的参数化接口，而命令执行没有统一的标准化参数化方案，不同语言、不同平台的API差异很大，开发者需要显式选择不带shell的调用方式。
参数化实践：绕开shell，用参数数组传递数据
以Node.js为例，exec()会启动shell解析字符串，而execFile()和spawn()默认不启动shell，除非显式传入{ shell: true }选项。下面这段代码是有注入风险的写法：
const { exec } = require('child_process');
const filename = req.body.filename; // 用户可控
exec('convert ' + filename + ' output.png', (err, stdout, stderr) => {
// 如果 filename 是 "a.jpg; rm -rf /"，系统会执行 rm
});
改成参数数组就安全得多：
const { execFile } = require('child_process');
const filename = req.body.filename;
execFile('convert', [filename, 'output.png'], (err, stdout, stderr) => {
// filename 只会作为 convert 的第一个参数，即使包含分号也不会被 shell 解释
});
Python 里有同样的问题。os.system()和subprocess.call()传入字符串时会经过shell解析。安全写法是subprocess.run()或subprocess.Popen()，第一个参数传列表，并且不设置shell=True。
import subprocess
filename = "a.jpg; rm -rf /"
# 危险写法
subprocess.call("convert " + filename + " output.png", shell=True)
# 安全写法
subprocess.call(["convert", filename, "output.png"], shell=False)
这里有一个常见的坑：开发者以为传了列表就自动安全，但如果在某些语言或框架里，列表会被重新拼接成一个字符串再交给shell，比如PHP的escapeshellarg()配合字符串拼接虽然能降低风险，但不如直接使用proc_open()的数组参数形式可靠。所以每次调用系统命令前，都应该查阅文档确认该API是否真的绕过了shell。参数化只是第一道防线，它无法防止用户传入--interlace这种合法但可能被滥用的参数，也无法阻止用户指定一个危险的命令名。这就是白名单要解决的问题。
白名单策略：只允许预设的命令与参数组合
参数化解决了shell元字符注入，但攻击者仍然可以操纵参数的内容。比如用户可以选择图片格式，后端需要把format变量拼进命令参数。如果只做了参数化，用户传format=png; cat /etc/passwd虽然不会执行cat，但可能诱发ImageMagick的某个漏洞，或者利用参数注入如--compress=zip触发额外的文件读取。更糟的是，如果业务需要根据用户输入选择不同的命令，比如convert、ffmpeg、gs，直接映射用户字符串到命令名等于打开了任意命令执行的窗口。
白名单的做法是在代码里维护一个允许的命令集合和参数模式。命令名只能从固定列表中选择，比如：
const allowedCommands = new Set(['convert', 'ffmpeg', 'identify']);
function runCommand(cmdName, args) {
if (!allowedCommands.has(cmdName)) {
throw new Error('Command not allowed: ' + cmdName);
}
// 额外对 args 进行格式校验
return execFile(cmdName, args);
}
对于参数，白名单可以更细粒度。比如只允许图片格式参数是png、jpg、webp三个枚举值，任何不在列表中的输入直接拒绝，而不是尝试转义或清理。如果参数必须包含路径，则先对路径做规范化，然后检查是否位于允许的目录范围内，同时禁止..和绝对路径穿越。
import os
import subprocess
ALLOWED_FORMATS = {'png', 'jpg', 'webp'}
UPLOAD_DIR = '/var/app/uploads'
def convert_image(source_name, target_format):
if target_format not in ALLOWED_FORMATS:
raise ValueError('unsupported format')
source_path = os.path.abspath(os.path.join(UPLOAD_DIR, source_name))
if not source_path.startswith(os.path.abspath(UPLOAD_DIR) + os.sep):
raise ValueError('invalid path')
target_path = source_path.rsplit('.', 1)[0] + '.' + target_format
subprocess.run(['convert', source_path, target_path], check=True)
白名单的优势是逻辑简单、可审计性强。代码审查时一眼就能看出哪些命令和参数是允许的，新增支持项时需要显式修改白名单。缺点是灵活性受限，某些场景下用户输入确实需要很大的自由度，比如自定义报表生成器允许用户传一段表达式给awk或perl。这种情况下白名单很难枚举所有合法表达式，更好的办法是把这类功能放到沙箱里执行，限制文件系统访问和网络权限，或者干脆改写成内部实现而不是调用外部命令。
结合使用：分层防御与输入校验
参数化和白名单不是二选一的关系，而是应该同时存在。参数化负责防止数据被解释成命令结构，白名单负责控制到底执行什么命令、什么参数。一个健壮的实现流程通常是这样：先检查用户请求的命令是否在白名单中，再对每个参数做格式和范围校验，最后使用不带shell的进程创建API执行。
以Go语言为例，标准库os/exec的Command函数天然使用参数数组，不会经过shell，除非手动把命令拼成字符串再调用bash -c。结合白名单可以这样写：
package main
import (
"fmt"
"os/exec"
)
var allowedCommands = map[string]bool{
"git": true,
"curl": true,
}
func runAllowed(cmdName string, args ...string) error {
if !allowedCommands[cmdName] {
return fmt.Errorf("command %q is not allowed", cmdName)
}
if cmdName == "curl" {
// 对 curl 的参数做额外限制，比如只允许 -sS -o 以及 https URL
for _, arg := range args {
if arg == "-d" || arg == "--data" {
return fmt.Errorf("curl data flag is not allowed")
}
}
}
cmd := exec.Command(cmdName, args...)
return cmd.Run()
}
除了这两项，还有一些辅助措施值得注意。环境变量清理很重要，执行外部命令时不要继承当前进程的全部环境变量，避免攻击者通过LD_PRELOAD、PATH等变量注入恶意库或替换命令路径。应显式构造一个最小化的环境变量集合，或者至少把PATH设置为绝对路径列表。另外，使用命令的绝对路径，例如/usr/bin/convert而不是convert，可以防止PATH劫持。
权限最小化也同等重要。运行系统命令的进程应当使用低权限账号，限制文件系统写入范围，最好配合Linux的seccomp、AppArmor或容器技术做系统调用级隔离。即使参数化和白名单被绕过，攻击者能造成的破坏也会被大幅限制。
常见误区与验证案例
一个很常见的误区是把escapeshellarg()当成万能药。PHP的escapeshellarg()会给参数加上单引号并转义内部单引号，它确实能降低命令注入风险，但前提是只适用于Linux shell。在Windows上，单引号的行为完全不同，escapeshellarg()并不能可靠防止注入。此外，如果开发者在拼接命令时忘了给某个参数调用转义函数，或者使用了escapeshellcmd()这种对整体字符串进行转义的函数，效果会大打折扣。escapeshellcmd()会转义&、;、`等字符，但它转义后的结果仍然可能被shell重新解释，且容易遗漏新语法。正确的做法仍然是尽可能避免shell。
另一个误区是“只校验输入格式就安全”，而忽略了参数注入。比如只允许用户输入数字作为文件名的一部分，攻击者传1; rm -rf /确实被过滤掉了，但如果业务里类似user_id的整数被拼进awk '{print $1}'这种脚本，单引号内的内容也可能跳出。输入格式校验必须与参数化、白名单配合，不能单独作为防线。
验证参数化是否生效，可以写一段测试代码，给参数传入包含分号、管道符、反引号、$(...)的字符串，观察外部命令是否尝试执行额外操作。例如在Linux上，可以传入hello; touch /tmp/pwned，然后检查/tmp/pwned文件是否被创建。如果文件出现了，说明命令仍然经过shell解析。自动化安全测试中可以把这个检测集成到CI流水线里，每次改动都跑一遍注入测试用例。
最后要强调的是，命令注入不仅仅是Web应用的专利。运维脚本、构建工具、CI/CD流水线、桌面应用调用外部程序时都可能踩坑。解决思路完全一致：避免字符串拼接、使用参数数组、维护命令白名单、限制权限。把这三件事养成习惯，命令注入风险会下降一个数量级。