安全漏洞整改报告

上周三凌晨两点，安全运维群里弹出一条告警：某台边缘节点的漏洞CPU飙到98%，持续了十五分钟。整改我爬起来连上VPN，报告发现一个不该存在的安全进程正以root权限往外传数据。那一刻我就知道，漏洞之前那个被标记为“低危”的整改注入漏洞，已经被人吃透了。报告

事情得从三个月前说起。安全安全团队做常规扫描时，漏洞在用户头像上传接口发现一处SQL注入点。整改当时的报告评估结论是“利用难度高，需认证后才可触发”，安全于是漏洞排期排到了下个迭代。现在回头看，整改这个判断错得离谱。攻击者根本不需要登录——他们绕过了前端校验，直接构造multipart请求，把恶意payload塞进文件名的EXIF字段里。那个接口调用了旧版ORM，拼接SQL时没做参数化，就这么被撕开了口子。

更麻烦的是权限配置。上传目录居然挂载在web根目录下，且运行账户对/etc/passwd有读权限。攻击者先写了个webshell进去，然后通过提权脚本拿到root。整个过程不到四十分钟。从日志看，他们甚至没用什么高级工具，就是sqlmap加一个公开的Linux提权exp。这让我想起去年那起供应链攻击——同样是因为一个被忽视的“低危”漏洞，最后演变成全量数据泄露。

修复方案其实不复杂。第一，把上传接口的数据库操作全部换成预编译语句，这个当天就改完了。第二，重新划分目录权限，上传目录独立挂载，运行账户降权到nobody，并且禁掉shell。第三，加了一层文件内容检测，不光看扩展名，还解析文件头，发现异常直接丢弃。这些做完，又花了三天做全量回归测试。但真正让我头疼的是历史数据的清理——攻击者留了三个后门账户，还有一个定时任务每半小时回连C2。清除这些花了整整一周。

事后复盘，最该骂的不是开发。开发确实写了不安全的代码，但代码评审时没人指出来，安全扫描报告被当成噪音忽略，运维的权限管理也过于宽松。每个环节都差了一点点，叠加起来就是一条完整的攻击链。我后来在内部技术分享会上说，安全不是某个团队的事，是每个提交代码、每个配置服务器的人都要绷紧的弦。你写一行拼接SQL，可能觉得“就这一次”，但攻击者只等这一次。

现在那个接口的代码里还留着一行注释：// 2024-06-12 注入修复，勿动。每次有人想重构这块，我都会把这次的日志截图发过去。效果比任何安全培训都好。漏洞本身不吓人，吓人的是那种“应该没事”的侥幸。我们后来把漏洞评级标准改了，凡是涉及数据读写且无需认证的，一律按高危处理。宁可误报，不可漏报。毕竟半夜被叫醒的滋味，实在不好受。