内容摘要：上周五下午四点十七分，运维老周在监控大屏前差点把咖啡泼到键盘上。核心业务系统的漏洞扫描报告弹出了十七条高危告警，其中三条直接指向我们对外支付接口的SQL注入点。换句话说，只要有人愿意花点时间构造请求包

上周五下午四点十七分，漏洞运维老周在监控大屏前差点把咖啡泼到键盘上。修复核心业务系统的整改漏洞扫描报告弹出了十七条高危告警，其中三条直接指向我们对外支付接口的报告SQL注入点。换句话说，漏洞只要有人愿意花点时间构造请求包，修复数据库里的整改用户余额表就跟没锁门的金库一样。

漏洞修复这事儿，报告最怕的漏洞不是漏洞本身，而是修复响应流程里的官僚气。以前我们走整改流程，整改先要写申请单，报告再等安全组排期，漏洞最后运维窗口还得挑个凌晨三点。修复一套流程下来，整改漏洞早被攻击者利用八百遍了。所以这次我们换了个打法——先斩后奏。老周带着两个开发直接拉了紧急变更分支，在防火墙策略允许的范围内，先把注入点的参数校验补上，再回头补流程文档。事实证明，等所有审批签字画押再动手，黄花菜都凉了。

具体到修复动作，其实没那么玄乎。SQL注入的根子在于代码里用了字符串拼接查询，把用户输入当成了可执行代码的一部分。我们做的第一件事就是全局搜索select * from这种裸写SQL的地方，把所有动态拼接改成预编译绑定参数。改完以后用sqlmap跑了一遍，原来能拖库的payload全部失效，响应包里只剩报错日志。这里有个细节值得说——预编译不是银弹，有些老系统用的ORM框架版本太低，绑定参数时会有类型转换漏洞，所以升级驱动和框架版本必须同步做。

修复过程中最头疼的其实是那些没人维护的老模块。有个五年前离职同事写的报表导出功能，用的是存储过程动态执行，压根没法套用预编译。我们讨论了半天，最后决定在应用层加白名单校验，只允许数字和特定字符传参，但凡带引号、分号或者注释符的请求直接拦掉。这招土是土了点，但胜在立竿见影。后来测试发现，有些攻击者会尝试用十六进制编码绕过，我们又补了一层URL解码后的二次过滤。攻防对抗就是这样，你堵一个口子，对方就换条路，但每堵一次，系统的攻击面就小一圈。

报告提交那天，安全组的人问我：“你们怎么保证修复后没引入新问题？”我指了指测试环境里跑着的自动化回归脚本——一百多个核心交易用例，从下单到退款全链路覆盖，跑了三遍零失败。这不是什么高深技术，就是笨功夫。但漏洞整改最缺的往往就是这种笨功夫，很多人修完漏洞就以为万事大吉，结果改个参数校验把正常业务搞崩了，反而造成更大的事故。

这次整改从发现到全部修复上线，用了四天半。比公司规定的SLA提前了两天。不是我们效率有多高，而是被逼急了——那条支付接口每天要处理几十万笔交易，谁也不想半夜被叫起来处理数据泄露。漏洞修复的本质不是技术活，是风险管理。你得清楚哪些系统在裸奔，哪些攻击路径最容易被利用，然后集中火力先堵最要命的那个口子。至于那些低危的、理论性存在的风险，记入台账慢慢排期就行了，别指望一次性解决所有问题。