一、问题描述

4月15日晚间，安全渗透测试人员通过构造 userId=1 AND SLEEP(5) 的隐患请求，发现接口响应延迟稳定在5.2秒左右，处置而正常请求仅需0.1秒。结果确认存在时间盲注，反馈可逐字符拖出数据库信息。网站该接口未做参数化查询，安全且未限制单IP请求频率——哪怕是隐患个新手黑客，拿sqlmap跑一个晚上，处置整个用户表的结果手机号和密码哈希就全没了。

二、反馈根因分析

翻代码时发现，网站这个接口是安全三个月前一个实习生写的。他在联调阶段图省事，隐患直接用字符串拼接SQL，后来上线时没走代码评审流程。更麻烦的是，数据库账号权限给得过大——这个接口居然能访问 information_schema 和所有业务库。说白了，不是技术多高深，纯粹是流程漏洞叠加了人的惰性。

三、处置措施（按时间顺序）

4月15日 23:40：收到测试报告后，我先在防火墙上临时封禁了该接口的异常请求模式（基于WAF规则），防止漏洞被外部利用。同时联系了值班DBA，把应用账号的权限从 SELECT, INSERT, UPDATE, DELETE 收窄到仅 SELECT 且限定单表。

4月16日 09:30：开发团队提交了修复补丁，改用MyBatis的 #{ } 预编译占位符，并删掉了那个实习生写的原始拼接方法。补丁经过两轮code review，确认没有其他遗漏的拼接点。

4月16日 14:00：我在测试环境复现了原注入payload，响应时间恢复正常（0.08秒）。同时跑了100条自动化注入测试用例，包括报错注入、布尔盲注和联合查询，全部拦截。

4月16日 18:20：生产环境灰度发布，先切了5%流量观察1小时，无异常后全量上线。

四、验证结果

复测结果：使用原漏洞利用脚本，注入语句全部失效，接口返回正常数据或参数错误提示。用AppScan扫描整个站点的注入类漏洞，清零。另外，我额外检查了同批次上线的其他两个接口，发现也有类似的字符串拼接写法——顺手一起改了，虽然它们目前没暴露注入点，但留着就是定时炸弹。

五、经验与改进项

这次事故最讽刺的地方在于：安全测试报告其实提前两周就发给了项目负责人，但对方一直没排期处理，直到我拿着“高危漏洞”的标签去拍桌子才动起来。后来查了流程，发现漏洞管理平台里这类“已报告未修复”的条目居然积压了47个。我已经要求安全组每周五下午发一封催办邮件，直接抄送技术总监，并给所有开发组组长开了数据库权限最小化的专项培训——上次培训还是去年十一月的事。

另外，那个实习生没被处分，但给他配了导师，所有SQL必须过导师review才能合代码。我私下跟他说，这不算坏事，谁没在线上摔过跟头呢。

六、遗留风险

目前仍有少量管理后台接口使用HTTP明文传输，计划在六月底前全站切换HTTPS。还有，测试环境的数据库备份文件存在一个可公开访问的OSS桶里，这个已经加了访问白名单，但彻底清理历史快照需要等月底运维窗口。

填表人：李工（安全运维组） ｜ 审核人：王总 ｜ 抄送：研发部、测试部、运维部