网络漏洞整改情况报告原因

去年十一月，网络我们一台对外提供API服务的漏洞服务器被人拖走了一个用户表。不是整改拖库，是情况接口没鉴权——测试环境的一个调试接口忘了关，直接暴露在公网上，报告参数里传个手机号就能返回对应的原因身份信息。安全扫描报告出来那天，网络整个后端组被叫去开会，漏洞气氛很难看。整改

这事说起来丢人。情况那个接口是报告两年前一个实习生写的，用来给前端联调提供mock数据。原因代码里留了注释：上线前删除。网络没人删。漏洞后来项目迭代了七八轮，整改代码review走了无数遍，所有人都默认那个路由已经下线了，实际上它还活着，安安静静地挂在/api/v1/debug/userinfo下面，谁都能访问。

排查花了两天。第一天查日志，发现异常请求来自三个境外IP，频率不高，每天几百次，持续了将近一个月。攻击者很克制，每次只取少量数据，像在试探。第二天确认了泄露范围：约四千条用户记录，包含手机号和脱敏后的身份证号。不算特别严重，但足够触发监管上报流程。

根因分析会上大家吵了很久。运维说代码部署时没做路由白名单，开发说安全扫描工具没覆盖到测试接口，测试说接口鉴权不在用例范围内。都有道理，但都没说到点子上。真正的问题是：我们从一开始就没有把“测试代码与生产代码分离”当回事。同一个代码仓库，同一套部署流程，靠开发者自觉在发布前注释掉调试代码——这本身就是个笑话。

整改分了三步走。第一步是止血，直接下线所有非业务必需的路由，加了一层网关级别的接口白名单，不在名单里的请求直接返回404。第二步是清理历史债务，把代码库里所有带debug、test、mock关键字的接口全部过了一遍，删掉了十七个类似的定时炸弹。第三步是改流程，测试环境和生产环境彻底拆成两个仓库，生产仓库的合并请求必须经过安全组的人工审核，自动化扫描工具也换了，新工具能识别Spring Boot的@RequestMapping注解，不会再漏掉隐藏路由。

整个过程用了三周。上线那天晚上我盯着监控看了两个小时，确认没有误杀正常请求。事后复盘时有人提了一句：如果当初那个实习生没写那个接口，或者写完之后有人删掉，这事就不会发生。但换个角度想，一个接口能安安静静活两年不被发现，说明我们的监控和审计机制本身就是失效的。漏洞只是症状，不是病因。

现在每次有新接口上线，我都会习惯性问一句：鉴权加了吗？路由在白名单里吗？日志里能看到调用记录吗？问多了同事嫌烦，但总比再出一次事故强。安全这事没什么一劳永逸，就是一遍一遍地查，一遍一遍地改，直到把侥幸心理磨干净为止。