凌晨两点十七分，漏洞我盯着那条漏洞报告，整改屏幕的反馈光把脸映得发青。一个SQL注入点，漏洞就藏在我们最不起眼的整改搜索框里。谁提交的反馈？不知道。但那个时间戳告诉我，漏洞对方花了整整四十分钟，整改绕过了三层WAF。反馈

整改通知下发的漏洞时候，开发组的整改老王还在改另一个更紧急的bug。他瞥了一眼邮件，反馈嘟囔了一句：“又是漏洞这种老掉牙的注入。”我理解他的整改烦躁，可老掉牙的反馈东西往往最致命。就像你家大门锁芯是二十年前的款式，小偷不费吹灰之力就能捅开——这跟技术新旧没关系，纯粹是懒。

所以第一件事，不是急着补代码，而是把那个搜索框的整个请求链路拉出来，从参数接收到数据库查询，一行行过。果然，问题不止一处。除了注入点，还有个隐藏的越权接口，能读到用户手机号。这就像你发现厨房水管漏了，拧开柜门一看，底下早就泡烂了一片。

修复本身并不复杂。参数化查询，加上白名单过滤，前后花了不到三个小时。但真正麻烦的是验证。你不能说“我改了，你测测”，然后就把报告丢回去。得自己先模拟攻击，拿同样的payload打一遍，确认它变成无害的字符串。我还特意试了试大小写混合、编码绕过，甚至塞了个超长的Unicode字符进去——全都挡在了门外。

可这事没完。第二天晨会上，我提了个问题：这个注入点是怎么活过代码评审的？没人接话。后来才知道，那段代码是外包同事写的，交付的时候没人仔细看，只测了功能通不通，没管数据安不安全。这不怪外包，怪我们自己的流程里有洞。就像你雇人装修，验收时只看墙刷得白不白，没检查电线有没有裸露。

于是我加了条规矩：所有涉及数据库查询的改动，必须附带参数化说明。不是形式主义，是逼着每个写代码的人多想一步——你写的这条where条件，用户能控制吗？能控制的话，你拦住了吗？

漏洞关掉的那一刻，系统日志安静得像什么都没发生过。但我知道，那只是暂时的。安全不是修完一个补丁就完事，它是个持续较劲的过程。也许下周，也许下个月，又会有个新玩意儿冒出来。到时候别抱怨，直接撸起袖子干就行。

反馈报告我写得简短：漏洞类型、影响范围、修复方案、验证结果、流程改进。五条，每行不超过二十个字。没必要长篇大论，真正要紧的是那个搜索框现在干净了，以及以后不会再因为同样的疏忽让它脏第二次。