命令执行漏洞修复

某天凌晨两点，命令某电商平台的执行订单系统突然开始疯狂报错。运维工程师盯着监控屏，漏洞发现数据库里多出几千条垃圾数据，修复每条都带着一段诡异的命令Base64编码。后来查明，执行是漏洞攻击者通过商品搜索框注入了一条命令，让服务器把用户表整个导出来发到了境外IP。修复修复过程并不复杂——过滤输入、命令参数化查询、执行升级组件版本，漏洞但事后复盘时大家后背发凉：这个漏洞在代码里躺了三年，修复每年代码审计都没发现。命令

命令执行漏洞的执行本质，是漏洞程序把用户的输入当成了系统命令的一部分。最常见的是Java的Runtime.exec()、Python的os.system()、PHP的system()这类函数。开发者图省事，把前端传过来的参数直接拼进命令行，比如一个ping功能，用户提交IP地址，代码就执行"ping " + ip。攻击者提交"127.0.0.1; cat /etc/passwd"，分号后面的命令就被执行了。就这么简单，不需要什么高深技巧。

修复的第一道防线是白名单校验。拿ping举例，只允许输入IPv4地址格式，用正则严格匹配，不是纯数字加点的字符一律拒绝。这比黑名单过滤靠谱得多——黑名单永远堵不完，你可以过滤分号、管道符、$符号，但攻击者用换行符、用%0a编码、用反引号，总有漏网之鱼。白名单直接掐死了非预期字符的进入路径。

但白名单不是万能药。有些场景必须接收复杂输入，比如文件上传功能需要处理文件名。这时候就该用参数化方式，把命令和参数分开。Java里用ProcessBuilder代替Runtime.exec，Python用subprocess.run传入列表而不是字符串。拿文件重命名功能举例，ProcessBuilder("mv", originalName, newName)会把两个参数原样传给系统，用户输入再刁钻，也只是被当作文件名处理，永远不会被解析成命令。

还有一类隐蔽的坑：间接命令执行。某内部系统用Python的eval()处理数学公式计算，用户提交"__import__('os').system('rm -rf /')"就能让服务器自毁。修复这类问题没有捷径，只能排查所有动态执行代码的函数，逐一改成安全替代方案。eval()换成ast.literal_eval()，正则替换掉危险的函数调用。这活儿枯燥，但必须做。

去年帮一家物流公司做安全评估，发现他们的快递单打印接口用了老旧的Apache Commons Text库，版本停留在1.9，存在CVE-2022-42889漏洞。攻击者只要在收件人姓名里构造特定字符串，就能让服务器执行任意命令。修复方案很简单——升级到1.10.0以上版本。但运维团队拖了两周才动手，理由是"业务系统不能随便重启"。结果第三周，该接口就被扫描到并被入侵，整个内网沦陷。事后查日志，攻击者利用这台服务器当跳板，在内网横向移动了三天，差点把核心ERP系统也拖下水。

修复命令执行漏洞，三分靠技术，七分靠管理。技术手段无非那么几招：输入校验、参数化、最小权限、及时升级。但真正难的是让团队形成条件反射——每次写代码时都问一句"这个输入如果被恶意构造会怎样"。很多开发者的思维惯性是"功能能跑就行"，等到出事了才追悔莫及。

建议每个团队都把命令执行漏洞的修复案例写进代码评审checklist。不是那种挂在wiki上没人看的文档，而是每次pull request时强制勾选的项。如果用了任何执行系统命令的函数，必须注明为什么不能用替代方案。这规矩看着繁琐，但能拦住九成以上的低级错误。剩下的，就靠定期渗透测试和日志监控来兜底了。毕竟，没有绝对安全的系统，只有不断加固的过程。