漏洞整改回复函

上午十点，漏洞对方安全团队的整改邮件弹了进来，附件里躺着那份熟悉的回复函漏洞报告——高危，两个，漏洞中危四个，整改低危若干。回复函说实话，漏洞看到“高危”那两个字，整改心里还是回复函咯噔了一下。哪怕我们上个月刚做过一轮渗透测试，漏洞该来的整改还是来了。

这次的回复函问题出在登录接口上。报告写得很清楚，漏洞参数没有做完整性校验，整改理论上可以绕过前端限制直接改请求包。回复函我拿他们给的PoC试了一下，五分钟就复现了。那一刻挺沮丧的，因为这个问题其实在代码评审阶段就该被拦住——但当时赶版本，测试环境只验证了正常流程，异常输入压根没覆盖到。

整改方案不能只堵这一个洞。我拉上后端和运维开了个短会，定了三层处理逻辑：第一层，在网关层统一加签名校验，所有非白名单的请求直接拒绝；第二层，把登录接口的参数校验从“黑名单”改成“白名单”，只允许特定格式的字段值；第三层，把这次触发的异常日志接进监控告警，下次有人再试这种畸形请求，我们能第一时间看到。

代码改动其实不大，麻烦的是联调。因为我们内部有十几个服务互相调用，网关加签名后，其他团队也得跟着改配置。那两天我基本泡在会议室里，挨个跟各服务负责人对签名算法，有人嫌麻烦，问能不能只给登录接口单独加个filter。我说不行，安全整改最怕的就是“单点修补”，你只堵这一个口子，旁边还有一堆类似的洞等着被捅。

中危的那几个问题相对好办——一个是静态资源路径暴露了版本号，一个是错误提示信息太详细，直接告诉攻击者“用户名不存在”。前者把版本号从URL挪到响应头里，后者把错误信息统一改成“用户名或密码错误”。改起来快，但测试得细致，尤其要确认改了提示语之后，前端密码找回流程不会误判。

低危项里有一条挺有意思，说我们某个管理后台的Session过期时间设成了8小时。说实话，这当初是为了方便运营同事操作，省得老让他们重新登录。但安全团队说得对——后台权限高，session留太久，万一有人离开工位忘锁屏，风险就大了。最后折中了一下，改成4小时，并且加了“空闲超过30分钟自动锁定”的提示。

整个整改花了四天。第四天下午，我把复测截图和代码diff链接整理好，写回复函时特意附上了每条漏洞的修复时间点。他们那边复核也快，当天晚上就回了邮件，确认所有高危和中危已闭环，低危里那条session建议也采纳了。

事后复盘，我最大的感受是：漏洞报告不可怕，可怕的是把它当成一张“需要填写的表格”。如果你只是照着描述改代码，不去想攻击者为什么会盯上这个点，那下个月可能又会有类似的洞冒出来。这次之后，我们把代码评审的checklist里加了一条“所有用户输入必须经过统一校验层”，并且要求每次上线前跑一遍自动化扫描，虽然多花二十分钟，但比事后熬夜改强多了。

回复函发出去的那一刻，我反而松了口气。安全整改不是零和博弈，对方帮你找出问题，你认真修掉，双方都踏实。下次再收到他们的报告，我希望自己能更从容一点——最好是在他们发现之前，我们自己就先看见了。