上个月中旬，网络我们内部做了一次常规漏洞扫描，安全结果比预想的漏洞要糟。一个对外服务的整改接口，参数校验形同虚设，情况攻击者构造特殊请求就能读到数据库里其他用户的说明手机号和地址。发现的网络时候，日志显示已经有几个IP在试探性拉取数据了，安全量不大，漏洞但这事不能赌。整改

当天下午就把那个接口下线了。情况运维先切了流量，说明开发那边同步翻代码，网络定位到问题出在一个三年前写的安全查询方法上——直接拼接SQL，没做任何过滤。漏洞这种漏洞老得掉牙，但偏偏就活到了现在。修起来倒快，换成参数化查询，加了白名单校验，前后不到两小时。可真正麻烦的是确认影响面：哪些数据被访问过、访问了多少、有没有被存下来。查日志查了一整夜，最后确认那几个IP都是扫描器行为，没有针对性拖库的迹象。算运气好。

但光堵这一个口子不够。我们顺手把同一批上线的接口全过了一遍，又揪出两个问题：一个文件上传点没限制类型，理论上能传jsp；另一个后台接口的权限校验写在了前端，抓包改个参数就能越权。这两个没被利用过的痕迹，但跟前面那个SQL注入属于同一类毛病——开发图省事，安全靠自觉。说白了，就是没人觉得会出事。

整改分了三步走。第一步，所有对外接口的参数校验全部重写，统一走一个校验框架，不允许开发自己手写过滤逻辑。第二步，文件上传加后缀白名单和内容检测，后台权限校验从前端挪到网关层，每个请求都得带token验一遍。第三步，也是最费劲的——把代码扫描接进了CI流程，每次提交自动跑一遍规则，有高危问题直接卡住不让合并。这一步推的时候有阻力，开发嫌慢，说影响发版节奏。后来把扫描时间从八分钟压到两分钟，又加了增量扫描，只查改动的文件，才勉强通过。

有个细节值得记一笔。修完漏洞后，我们拿同样的扫描器又跑了一遍，发现之前那个SQL注入点确实没了，但同一个接口的另一个参数又冒出一个反射型XSS。当时就有点火大——修的时候只盯着报告里写的那一处，旁边同样的坑看都没看。这说明什么？说明整改不能只对着漏洞列表打勾，得顺着代码逻辑把同类问题一次清干净。后来我们定了个规矩：每个漏洞修完，必须把同一个文件、同一个模块的相似写法全部检查一遍，写进整改报告里。

现在过去三周了，CI里的扫描规则跑了大概两百多次提交，拦下来四个中危问题，都是新写的代码里带出来的。开发那边从最开始骂骂咧咧，到现在提交前自己先跑一遍本地扫描，习惯算是养成了。漏洞本身不可怕，可怕的是修完就忘，下次换个地方再犯。这次整改最大的收获不是修了那几个洞，是把检查动作嵌进了日常流程里，让安全不再是上线前才想起来的那道坎。

后续还有件事没做完：那批老接口里还有几个用了过时的加密库，暂时没发现可利用的点，但迟早得换。已经排进下个季度的技术债清单了，优先级中等。不急，但不能忘。