远程执行代码漏洞修复

去年冬天，远程我负责维护的执行一个内部管理系统被扫出了高危漏洞。扫描报告上写着“远程执行代码（RCE）”，代码评分9.8。漏洞那会儿我正端着咖啡，修复差点没拿稳。远程这个系统跑在内网，执行但谁都知道，代码内网从来不是漏洞安全岛。

漏洞出在一个文件上传接口。修复用户上传头像时，远程后端只是执行简单校验了扩展名，然后把文件丢进了一个可被Web访问的代码目录。更糟的漏洞是，这个目录配置了脚本执行权限。修复攻击者上传一个伪装成图片的PHP文件，访问它，服务器就乖乖执行任意代码。听起来像2010年的老套路，可它就这么真实地躺在我负责的代码里。

修复过程比想象中麻烦。第一反应是加白名单，只允许jpg、png、gif。但业务方说，用户偶尔要传zip格式的素材包。那就得换方案：把上传文件存到Web根目录之外，通过一个代理脚本读取，并且强制设置Content-Type和Content-Disposition。这样即使文件里有恶意代码，也不会被服务器解析。

改完代码，我盯着那段逻辑看了很久。问题根源不在校验函数，而在架构设计——把用户可控的文件放在可执行路径下，本身就是原罪。后来我翻了一些开源项目，发现不少CMS至今还在用类似模式。有人觉得“内网无所谓”，可一旦边界被突破，这种漏洞就是攻击者的高速公路。

另一个案例来自朋友的公司。他们的API网关有个反序列化接口，接收Base64编码的Java对象。攻击者构造恶意序列化数据，触发链式调用，最终执行系统命令。修复时，他们没敢直接上白名单，因为老客户端还在用。折中方案是加了一层签名校验，并且限制反序列化的类路径。朋友说，那两周他几乎没睡好觉，每次看到日志里出现异常Base64字符串，心跳就加速。

RCE修复有个特点：你很难一次改到位。攻击面可能藏在文件上传、模板渲染、表达式解析、反序列化、甚至日志格式化里。我习惯用“污点分析”的思路手动过一遍：用户输入从哪进来，经过哪些函数，最终有没有到达危险操作（exec、eval、include、反序列化）。这个过程很枯燥，但比依赖扫描器靠谱。扫描器会漏报，也会误报。有一次它报了一个“命令注入”，我查了半天，发现只是字符串拼接后传给了日志函数，根本没执行。

修复之后，我加了两条规则。第一，任何执行系统命令的代码必须走统一封装，并且记录调用栈。第二，上传目录永远不挂载可执行权限，用Nginx的location明确禁止。这两条写进了团队规范。后来新来的同事问为什么，我就把那次漏洞的PoC发给他看。他看完说：“原来这么简单就能拿到shell。”对，就是这么简单。

现在每次上线前，我会跑一个自定义脚本，扫描代码里有没有直接拼接用户输入到eval或system的调用。误报不少，但总比漏报强。安全这事，没有银弹。RCE修复更像是在跟自己的懒惰和侥幸心理打架。你多花十分钟想清楚数据流，可能就少一次半夜被叫起来应急的机会。

最后说个观察：很多RCE漏洞的修复补丁，其实只有几行代码。但找到那几行，需要你对整个系统有足够深的了解。别指望自动化工具帮你搞定一切。工具能告诉你哪里有火，但灭火还得自己拎水桶。