一个命令执行漏洞，信息系统让运维半夜两点爬起来

去年冬天，高危一家做跨境电商的漏洞朋友半夜给我打电话。他们的整改运维在巡检时发现，公司对外的信息系统订单查询系统里，有一个接口能直接执行系统命令——攻击者不需要登录，高危构造一个特定参数就能让服务器返回/etc/passwd的漏洞内容。CVSS评分9.8，整改高危，信息系统利用门槛几乎为零。高危他问我：现在怎么办？漏洞

这不是“先报告领导再开会讨论”的时候。漏洞已经暴露在公网，整改每多开放一分钟，信息系统被扫描器抓到的高危概率就翻一倍。整改的漏洞第一步永远是先止血，再治病。

先切断攻击路径，别急着修代码

很多人一听说有漏洞，第一反应是打开IDE去改代码。方向错了。代码修复要测试、要回归、要走发布流程，快则几小时，慢则一两天。这段时间系统裸奔，风险不可控。

正确的顺序是：在WAF或反向代理层加一条规则，把包含命令拼接特征的请求直接拦截。比如那个接口的参数里出现了;、|、$(这类字符，先一刀切掉。误杀正常请求？有可能，但比服务器被拿shell强。同时把该接口的访问日志单独拉出来，看过去72小时有没有异常IP在频繁试探。有，就封IP段；没有，也别侥幸，继续往下走。

如果漏洞接口不是核心业务，直接下线是最省事的做法。朋友那套订单查询系统，凌晨访问量几乎为零，他们临时把接口从网关路由里摘掉，业务侧只影响几个内部报表，完全扛得住。

定位根因，别只修表面

止血之后，才轮到看代码。那个接口的问题很典型：接收用户输入的单号，拼接到一个shell命令里去做文件查找。开发图省事，用了Runtime.getRuntime().exec("grep " + orderId + " /data/orders.log")。攻击者传; cat /etc/passwd，命令就串起来了。

修复方式不是简单加个黑名单过滤分号。黑名单永远绕得过去。正确做法是消除命令拼接：用Java的ProcessBuilder传参数数组，或者干脆不用shell，直接读文件再在应用层过滤。如果非要调外部命令，参数必须经过白名单校验——单号只允许数字和字母，长度固定，其他一律拒绝。

这里有个细节：很多团队修完这个接口就收工了。但同一个项目里，其他接口有没有类似的拼接？全局搜一遍exec、Runtime、ProcessBuilder，大概率还能揪出两三个同源问题。我见过一个系统，修了订单接口，漏了物流接口，三天后又被同一个扫描器打穿。

验证与回归，别自己骗自己

改完代码，部署到测试环境。别只用正常参数跑一遍就点通过。把原来的攻击payload原样打进去，看返回是不是变成了400或500，且没有命令执行结果。再用; whoami、| id、`ls`、$(sleep 5)变种各试一遍。时间盲注那种，看响应时间有没有异常延迟。

有条件的话，用Burp Suite的主动扫描或者开源的commix跑一遍。工具不能代替人工，但能覆盖你没想到的编码绕过方式，比如URL双重编码、Unicode变形。

上线之后，别把这事翻篇

生产环境发布后，盯24小时监控。重点看WAF拦截日志里有没有新的绕过尝试，看应用日志里有没有异常的命令执行报错。朋友那套系统上线后第二天，果然有IP尝试用%3B编码绕WAF，被规则挡住了。

最后做一件事：把这次漏洞的payload、修复代码、验证步骤写成一页纸，放到团队wiki里。下次谁再写类似功能，先搜一下。安全漏洞从来不是修完就完，它暴露的是开发习惯的问题。一个命令执行漏洞背后，往往藏着十个没被发现的拼接点。修一个，搜十个，才算真正整改到位。

(责任编辑：娱乐)