内容摘要：上周三凌晨两点十七分，我盯着屏幕上那条SQL注入告警，咖啡杯沿已经结了一层干涸的奶渍。攻击者用了一串编码过的UNION查询，试图从订单表里拖出用户手机号。这已经是本月第三次了，前两次被WAF拦下，这次

上周三凌晨两点十七分，网站我盯着屏幕上那条SQL注入告警，漏洞咖啡杯沿已经结了一层干涸的修复奶渍。攻击者用了一串编码过的网站UNION查询，试图从订单表里拖出用户手机号。漏洞这已经是修复本月第三次了，前两次被WAF拦下，网站这次绕过了规则集。漏洞我手动封了IP，修复但心里清楚，网站这不过是漏洞缓兵之计。

漏洞修复从来不是修复打补丁那么简单。多数人以为找到漏洞、网站部署补丁、漏洞重启服务就完事了，修复可现实里，每个漏洞背后都藏着一连串设计缺陷。比如这个注入点，根源是开发图省事，把查询参数直接拼进了SQL语句。补丁能过滤特殊字符，但下次换个编码方式，照样能穿透。真正的修复得改代码逻辑，用参数化查询，这活儿得拉着开发团队一起干，还得排期测试。

上周那个Java反序列化漏洞更典型。官方补丁出了，但业务系统用的框架版本太老，补丁根本打不上。升级框架意味着要重写部分接口，后端负责人一听就皱眉，说排期到下个月。我理解他的难处，可攻击者不会等你。最后折中方案是先在网关层加了条规则，拦截可疑的序列化数据流，同时让开发抽出两个人专门做框架迁移。那几天我每天下班前都要看一眼迁移进度，像盯着锅里煮的粥，怕糊底。

还有个常被忽略的坑——漏洞修复后的验证。很多人打完补丁就撒手，结果补丁本身引入新问题。上个月修一个文件上传漏洞，过滤了上传文件的后缀名，结果业务方说合法用户传的PDF全被拦了。因为检测逻辑写得太死，把包含空格的“.pdf ”也当成非法后缀。那天下午我一边改正则表达式，一边听着电话那头业务人员的抱怨，心想这活儿真不是人干的。

不过话说回来，也有让人踏实的时刻。上周五把那个存储型XSS修完后，我特意用攻击脚本跑了三遍，看着输出框里干干净净的纯文本，长舒了口气。那种感觉，像暴雨天修好漏水的屋顶，坐在屋里听着雨声，知道不会再滴答了。漏洞修复就是这种活儿，永远在跟时间赛跑，跟攻击者斗智斗勇，偶尔还得跟同事的惯性思维较劲。但每次看到系统日志里那些被阻断的攻击记录，心里还是会冒出一句：行，这波守住了。