漏洞处理情况报告

下午三点十七分，漏洞运维群里炸了锅。处理有人贴出一张截图，情况后台管理系统的报告登录页面上，密码框下方多了一行灰字：“欢迎使用，漏洞管理员账号已锁定。处理”没人点过锁定功能。情况我立刻拉出审计日志，报告发现凌晨两点到四点之间，漏洞有人用admin账号尝试了四百多次登录，处理IP段来自境外。情况这不是报告第一次了，但这次不一样——我们刚上线了新的漏洞支付模块，漏洞可能已经被人摸透了。处理

先说结论：这次漏洞的情况直接原因是密码重置接口没做频率限制，攻击者用暴力破解的方式撞开了弱口令。但根子不在这。我翻了代码仓库，发现三个月前有人提交过一次“优化密码校验逻辑”的改动，把原本的延迟重试机制删了，理由是“影响用户体验”。当时没人反对，因为测试环境跑起来确实快了不少。谁也没想到，这个“优化”会在生产环境捅出这么大篓子。

处理过程没什么戏剧性。发现问题的当天下午，我们先把admin账号强制下线，然后临时封禁了那个境外IP段，接着紧急回滚了密码重置接口的代码，重新加回了延迟限制和验证码。整个过程大概四十分钟，期间业务没停，但支付模块的接口我们主动降级了——宁可让用户多等两秒，也不能让数据再暴露一秒。事后复盘时，团队里有人嘀咕：“要是当初测试用例里多写一条‘连续密码错误十次’的场景就好了。”这话听着简单，但真做起来，往往被排期和优先级挤到角落。

漏洞的根源，说穿了是人。技术手段只是最后一道防线。我们公司有个不成文的习惯：新功能上线前，产品经理会催着开发“快点发”，测试人员有时连回归测试都做不全。这次出问题的密码重置接口，测试用例里确实有“输入错误密码”的用例，但只测了三次，因为“正常用户不会错那么多次”。可攻击者不是正常用户，他们会用脚本跑一万次。这个认知差，比任何代码漏洞都致命。

修复之后，我做了个有点“土”的决定：把这次漏洞的完整时间线、攻击者的手法、以及我们回滚的代码diff，全部打印出来，贴在工位上方的白板上。不是为了示众，是想让每个人路过时都看一眼——尤其是那些刚入职的年轻开发，他们总觉得安全是安全团队的事。实际上，一个看似无害的“优化”，可能就是别人撬开大门的杠杆。

报告写到最后，我想说点主观的。漏洞永远补不完，今天堵住密码重置，明天可能冒出文件上传的坑。但真正让人后怕的不是漏洞本身，而是我们对待漏洞的态度。如果每次修复都只是打个补丁，而不去问“为什么这个漏洞会存在”，那下次换个入口，照样会栽。这次之后，我们定了个规矩：任何涉及认证、授权的代码改动，必须过安全评审，哪怕多花半天时间。规矩可能有点死板，但比起半夜被电话吵醒、看着用户数据可能被拖走的那种心慌，我宁可死板一点。