网站安全漏洞排查台账

上周三下午，网站我打开后台的安全访问日志，发现一条来自冰岛IP的漏洞POST请求，指向我们一个早已停用的排查测试接口。那接口连着的台账数据库里存着两万条用户手机号。查了一下，网站漏洞是安全三个月前那次功能迭代留下的——开发把旧接口直接注释掉了，没删路由。漏洞

这种事见得多了。排查很多公司所谓的台账“安全排查”，不过是网站等出了事才翻日志。真正有效的安全台账，应该从代码提交那一刻就开始记。漏洞我手里的排查这本，分四栏：漏洞描述、台账发现时间、影响范围、处置状态。别小看这四栏，每栏都得写人话，别堆术语。

先说漏洞描述。别写“存在SQL注入风险”，要写“登录框的username参数未过滤单引号，用' or 1=1 -- 能直接绕过密码验证，实测于Chrome 120版本复现”。这样任何人接手都能立刻懂。上个月我排查一个文件上传漏洞，原描述就五个字“上传有bug”，结果开发小哥花了两小时才搞明白是后缀名白名单漏了`.php5`。

发现时间这栏，我习惯精确到分钟。因为有些漏洞是定时触发的，比如每周一凌晨的定时任务会重置某个临时密钥。如果你只记到日期，下次排查时根本对不上号。有次我们平台半夜被人刷了三千条垃圾评论，靠的就是台账里“2024-03-18 02:13”这个时间点，反查到漏洞是当天凌晨的缓存刷新逻辑没做权限校验。

影响范围最容易被低估。很多人只写“用户表”，但实际影响可能牵扯到支付回调、短信验证码服务。我吃过亏——某次漏洞只标记了“前台搜索功能”，结果黑客通过搜索接口的报错信息摸到了后台管理员的密码重置链接。现在我会强制要求写清楚：涉及哪些接口、哪些数据表、是否影响第三方对接。宁肯多写两行，别漏掉一个关联系统。

处置状态是活账。别写完“已修复”就完事。我见过太多“修复”其实是把报错提示从英文改成中文，漏洞原封不动。正确做法是写三步：临时止损动作（比如先关掉那个接口）、根因修复（改代码还是改配置）、验证方法（用同样的攻击手法再试一次）。上周处理一个越权漏洞，临时方案是加IP白名单，根因是改了session校验逻辑，验证方式是拿普通用户cookie去访问管理员接口，返回403才算过。

台账不是写给检查的人看的，是写给自己下次出事时翻的。我每季度会把台账里所有“已修复”的漏洞重新扫一遍——不是疑心重，而是很多修复只挡了当时那种攻击方式。比如上次修了XSS，只过滤了`