关于网站漏洞处置情况说明

昨天下午四点十七分，关于安全运维群里炸了锅。网站监控系统弹出一条红色告警——我们部署在华东区的漏洞客户管理系统，被人用SQL注入的处置方式拖走了三万多条用户手机号。数据是情况上午十一点左右被分批次导出的，对方手法很老练，说明每次只取五百条，关于绕过了我们设置的网站单次查询上限。

我第一时间登录服务器看了访问日志，漏洞攻击源指向一个波兰的处置IP段，但用爬虫反查了一下，情况更像是说明通过Tor出口节点中转的。典型的关于黑产操作，不留真实痕迹。网站

漏洞出在一个老接口上。漏洞去年年底做系统升级时，开发同事重写了大部分代码，但有个用于导出报表的功能模块因为业务方催得急，沿用了几年前写的拼接SQL语句。当时测试环境里没查出问题，因为测试库的数据量小，响应速度正常。生产环境数据量大，这个接口平时调用频率低，也一直没触发异常。

修复过程不算复杂。先把这个接口紧急下线，然后花了三个小时把里面所有动态参数改成预编译语句，加了输入校验。同时把数据库账号权限做了最小化调整——之前那个接口用的账号居然有整个库的查询权限，这明显是历史遗留问题，早该改的。

真正让我觉得后背发凉的是后续的排查。我们翻了一个月的数据库操作日志，发现这个漏洞其实早就有被探测的痕迹。两周前就有来自不同IP的多次试探性请求，传参里带着明显的单引号和注释符。当时运维值班同事看到了异常告警，但因为在可接受的风险范围内，没有上报，就这么滑过去了。

这件事暴露了两个层面问题。技术层面，代码审查流程形同虚设，老代码没人愿意动，测试只覆盖新功能，回归测试根本没做。管理层面更严重——告警分级制度有，但执行的人凭经验判断，觉得“小探测不算事”。安全这事，怕的就是这种“应该没事”的侥幸。

数据泄露后我们启动了应急预案，联系了公安网安部门报备，也发了短信通知受影响用户。补偿方案是送半年免费的信用保护服务，预计成本在四十万左右。这比修复漏洞本身贵多了——那个接口的修复工作量，一个中级工程师干一天就能完成。

写这份说明的时候，我让团队把这次漏洞的完整时间线、修复记录、后续整改措施都整理成了文档，并且把那个老接口的开发责任人、当时审批上线的负责人、还有值班没上报的同事，一起拉进了复盘会议。会上没怎么骂人，但气氛很压抑。有人问了一句：如果这次拖走的是身份证号和银行卡信息，我们现在还能坐在这里复盘吗？没人接话。

下周开始，所有对外接口的代码审查会改成双人交叉复核，数据库账号权限每季度自动审计一次，告警规则也重新调了阈值——宁可误报十次，不能漏过一次。这些措施不一定能防住所有攻击，但至少能把类似这种“低级漏洞+人为疏忽”的组合拳，挡在门外。