网络安全风险漏洞整改情况的反馈

上周三凌晨两点，网络运维群里弹出一条告警：某业务系统数据库的安全响应时间从80毫秒飙到4秒。值班同事以为是风险慢查询，登上去一看，漏洞连接池里趴着三百多个来自境外IP的整改空闲会话，每个都在反复尝试执行SELECT * FROM users WHERE id=1 AND SLEEP(5)。情况典型的网络SQL注入盲注。攻击者没拖走数据，安全但把连接池占满了，风险业务直接半瘫。漏洞这事要是整改发生在白天，客服电话能被客户打爆。情况

天亮之后我们拉了复盘会。网络问题出在一个三年前上线的安全老接口上，参数直接拼进SQL，风险连预编译都没用。开发当时图快，测试也没覆盖到这块。更麻烦的是，这个接口挂在公网上，没做任何限流和IP白名单。漏洞扫描报告其实半年前就标了“高危”，但整改单在OA里流转了四个月，最后卡在“排期冲突”上。说白了，大家都觉得不会那么巧被盯上。

整改动作分了三块。第一块是止血：当天上午把那个接口从公网摘下来，加了WAF规则拦截SLEEP、BENCHMARK这类关键字，同时给数据库连接池设了硬上限。第二块是修复：把拼SQL的代码全部改成参数化查询，顺手把接口的鉴权逻辑从“只验token存在”改成“验token+验用户权限”。第三块是补流程：以后扫描报告里的高危漏洞，整改期限从“建议30天”改成“强制7天”，超期自动升级到技术总监。

有个细节值得说。修复的时候发现，同一个服务里还有另外两个接口用了类似的拼接写法，只是没被扫描器扫出来。开发同事自己都忘了写过这些。这说明什么？漏洞整改不能只盯着报告上的那一条，得顺着同一种编码习惯往回捋。我们后来定了个规矩：每修一个注入漏洞，必须把整个模块的SQL调用全过一遍，用工具扫一遍AST，确认没有漏网的。

再讲个反面例子。隔壁团队上个月修一个XSS漏洞，直接在上游网关加了个正则过滤<script>。结果测试环境没问题，生产环境一上，用户昵称里带“script”这个词的全都报错。更糟的是，攻击者用<img src=x onerror=alert(1)>照样能弹窗。这就是典型的“打补丁式整改”——只堵报告里那个payload，没解决输出编码的根本问题。后来他们老老实实回到模板层做HTML实体转义，才算收场。

我自己的判断是，漏洞整改最怕两种心态。一种是“扫描器没报就是没有”，另一种是“加个WAF就算修了”。前者是掩耳盗铃，后者是把安全责任推给设备。真正有效的整改，得落到代码层、配置层和流程层三个地方。代码层改写法，配置层收紧权限和网络策略，流程层保证同类问题不再漏掉。缺一个，过两个月同样的漏洞换个接口又冒出来。

这次事件之后，我们把所有公网接口的入参做了统一校验，长度、类型、白名单字符，能卡的都卡住。数据库账号也拆了权限，业务账号只给CRUD，DDL全部走单独的运维通道。慢查询日志里再出现SLEEP，直接触发告警。上周又扫了一遍，那个老接口的评分从“高危”变成了“低危”。但没人敢松口气——攻击面这东西，你今天关了一扇窗，明天可能又开了一道门。保持盯着，比什么整改报告都实在。