网站漏洞处理报告

凌晨两点十七分，网站监控邮件把我从沙发上拽起来。漏洞告警内容很简单：/api/v2/user/info 接口返回了异常数据包——里面带着另一个用户的处理手机号。

这不是报告猜测，是网站实锤。攻击者用了一个极其低级的漏洞技巧：遍历user_id参数，从1数到5000，处理就把我们库里的报告用户信息全拖走了。没有SQL注入，网站没有复杂的漏洞payload，就靠一个没做鉴权的处理接口。

我盯着日志看了十分钟，报告后背发凉。网站那个接口是漏洞三个月前为了给某个内部工具临时加的，测试完忘了删。处理代码注释里还写着“TODO：加权限”，后来就没人管了。

漏洞处理的第一步不是打补丁，是止血。我立刻在防火墙上封了所有非白名单IP对该路径的访问，同时把接口下线。但这只是缓兵之计——攻击者可能已经拿到了数据，封IP拦不住他继续利用别的路径。

接着排查数据泄露范围。日志显示攻击者从凌晨一点开始，以每秒5个请求的速度跑了整整42分钟，共拉走约12000条记录。好在数据库里存的不是明文手机号，是加盐哈希。但问题来了——盐值写在配置文件里，而配置文件恰好躺在同一个服务器上。这等于把钥匙挂在锁旁边。

那天夜里我做了三个决定：第一，强制重置所有受影响用户的登录令牌；第二，写邮件给安全团队说明情况，措辞尽量不吓到法务；第三，把那个临时接口的删除流程写进部署脚本，以后任何接口上线超过30天无调用自动告警。

第二天早上，团队复盘时有人问：“为什么不直接回滚到昨天的数据库备份？”——问得好，但没用。攻击者拿到的数据是实时的，回滚只能恢复我们自己的数据，不能抹掉他手里的副本。所以真正的重点是：假设数据已泄露，然后设计应对方案。

处理过程里最麻烦的不是技术，是沟通。运营同事反复问“要不要通知用户”，产品经理担心影响口碑，领导问“是不是开发偷懒”。我最后拍板：先通知，但措辞只说“检测到异常访问，已加强防护”，不主动提数据泄露细节。等法务确认完法律义务再决定是否升级披露。

补漏洞本身只花了半小时。真正花时间的是写复盘报告、改开发流程、给所有接口加统一鉴权中间件。顺手还删了另外两个类似的“临时接口”——它们都藏在代码里，注释写着“仅测试用”。

四天后，攻击者换了个IP又来试了一次，被WAF拦了。他大概以为我们没发现。实际上我们已经在蜜罐里放了个假接口，记录了他用的工具指纹，那是某个开源扫描器的变种。

这事过去两个月了。现在每次有人提交代码，CI流水线都会自动检查API路由是否包含temp或test字样，有就直接拒绝合并。代价是开发流程慢了大概10%，但没人抱怨——那个凌晨的告警邮件，谁都记得。

网站漏洞从来不是技术问题，是管理问题。代码是人写的，流程是人定的，疏忽也是人造成的。技术手段能堵住已知的洞，但堵不住懒惰、匆忙和侥幸。真正的修复，是把“临时”两个字从开发文化里彻底删掉。