把命令执行漏洞的命令修复方案摆在一张桌子上，最显眼的执行最差那张纸写着“输入过滤”。我见过太多团队把宝押在这上面，漏洞结果被现实抽得鼻青脸肿。防段中这玩意儿不是护手没用，而是效果它的失效方式太有欺骗性——你以为堵住了，其实侧门全开着。命令

拿个真实案例说事。执行最差某电商平台的漏洞后台，程序员写了段代码过滤用户提交的防段中IP，把分号、护手管道符、效果反引号全替换成空字符串。命令测试时输入127.0.0.1;ls，执行最差确实被干掉了，漏洞日志干干净净。上线三个月后被人打穿，攻击者提交的payload是127.0.0.1$IFS$9ls——Linux的$IFS是内部字段分隔符，默认包含空格，$9是空变量，拼接起来就是空格。过滤逻辑只盯着分号和管道，压根没考虑环境变量展开。最后攻击者用curl把/etc/passwd传走了。那哥们儿后来在复盘会上说了句大实话：“我以为过滤了危险字符，结果人家用的是合法字符的非法组合。”

为什么输入过滤效果最差？核心逻辑就一条：它假设攻击者会按你预设的“危险列表”出牌。可命令执行漏洞的本质是拼接——用户输入进入系统命令的上下文，而系统命令的语法复杂度远超任何黑名单能覆盖的范围。空格能绕，引号能绕，换行符能绕，甚至${ IFS}这种环境变量都能当空格用。你写一百条过滤规则，攻击者只需要找到第一百零一种合法字符组合。这跟打地鼠一样，永远慢半拍。

更恶心的是过滤逻辑本身会引入新漏洞。有些团队为了堵空格，把用户输入中的所有空格删掉，结果合法路径/opt/my app/script.sh直接被改坏，系统报错，攻击者反而从报错信息里摸到了目录结构。还有一种常见操作是转义特殊字符，但转义后的字符串如果再次进入eval或system函数，可能被二次解析——转义符本身成了可利用的注入点。我见过一个案例，过滤函数把单引号替换成\'，结果攻击者输入\';id;，转义后的字符串在bash里恰好构成闭合引号加新命令。过滤逻辑亲手递上了刀。

有人会反驳：那用白名单啊，只允许数字和点。这确实比黑名单强，但白名单本身也扛不住逻辑漏洞。比如某路由器管理页面允许用户填ping的IP，白名单校验通过了，可后端代码把IP直接拼进ping -c 4 { input}。攻击者填127.0.0.1%0acat /etc/shadow——百分号编码的换行符在部分环境会被解码，白名单校验的是解码前的字符串，执行时却是解码后的内容。校验和执行的脱节，让白名单形同虚设。

真正该做的，是彻底抛弃拼接思路。用subprocess的参数列表形式传参，或者把命令执行封装成独立的微服务，用强类型接口限制输入。但很多团队嫌重构成本高，宁可继续打补丁。说白了，输入过滤是最便宜的心理安慰——写几行正则，跑个测试用例，看起来像那么回事。可攻击者不按你的测试用例出牌，他们按bash的语法手册出牌。

最后说句难听的：如果你只能选一种防护手段，千万别选输入过滤。它适合当第一道缓冲，但绝不配当防线。真正的防线是禁用命令执行函数、最小化权限、强制使用参数化API——这些听着麻烦，但至少不会让你在凌晨三点被电话叫醒，看着日志里那行;rm -rf /发呆。