软件漏洞整改报告

3月17日凌晨两点，软件运维群里弹出一条告警：用户中心接口响应时间从80ms飙到4.2秒。漏洞我爬起来连上VPN，整改看了眼日志，报告心里咯噔一下——有人在用SQL注入批量拉取用户手机号。软件攻击者没绕弯子，漏洞直接构造了UNION SELECT，整改而我们的报告代码居然照单全收。

问题出在一个两年前写的软件查询接口。当时为了赶版本，漏洞开发直接用字符串拼接SQL，整改参数过滤只做了前端校验。报告后端代码里那行String sql = "SELECT * FROM users WHERE id = " + userId;，软件像一颗埋了很久的漏洞雷。攻击者甚至没用什么高级工具，整改sqlmap跑了一遍就找到了入口。我盯着屏幕上的请求日志，后背发凉——数据库里躺着八十万条用户记录，包括手机号、身份证号和绑定邮箱。

凌晨三点，我们切了流量，封了IP，临时把接口下线。天亮后拉了个紧急会，决定当天完成整改。方案不复杂：把所有拼接SQL的地方换成参数化查询，MyBatis的#{ } 替换掉${ }，同时加一层WAF规则拦截明显注入特征。但真正动手才发现，类似的拼接点在全项目里有十七处，分散在六个模块。有些是历史遗留，有些是新人照抄旧代码写出来的。

整改过程比预想麻烦。参数化查询改完后，有两个接口的排序字段失效了——因为ORDER BY后面不能用占位符。只能改成白名单校验，把允许的字段名硬编码进去。另一个接口用了动态表名，同样得手工过滤。这些细节在漏洞扫描报告里不会写，只有真正改代码的人才知道疼。

下午四点，测试环境验证通过。我们补了三条单元测试，专门覆盖注入场景，又加了一条CI检查规则：任何新提交的代码里出现${ 且不在XML映射文件中的，直接构建失败。这招有点狠，但比事后救火强。晚上八点，生产环境灰度发布，监控面板上的响应时间回到90ms，注入告警归零。

事后复盘，我发现一个挺无奈的事实：这个漏洞两年前就被扫描器报过，但当时优先级被标成“低”，因为“利用难度高”。可实际上，攻击者只用了一个下午就拿到了数据。安全漏洞的优先级不该由开发拍脑袋定，得看数据敏感度和暴露面。用户中心接口对外网开放，又直接连核心库，这种地方不该有任何侥幸。

另外，代码审查环节形同虚设。那行拼接SQL的代码在PR里躺了三天，三个评审人都点了通过。不是他们不负责任，是大家默认“业务逻辑没问题就行”，安全靠后站。后来我们改了规则：涉及数据库查询的PR，必须有一名安全组成员参与评审。人力不够就轮岗，但这条线不能松。

现在再回头看这次整改，技术手段其实不新鲜——参数化查询、白名单、WAF，都是老生常谈。真正难的是让团队把安全当成写代码的一部分，而不是上线前扫一遍就完事。漏洞不会因为你赶进度就消失，它只会在某个凌晨两点，用一条告警把你叫醒。

(责任编辑：娱乐)