网络漏洞检测记录表

上周三凌晨两点，网络我在一台对外服务的漏洞Web服务器上扫出一个SQL注入点。参数是检测记录?id=1'，返回的网络报错信息直接把数据库版本吐了出来——MySQL 5.7.38。这种错误页在2015年很常见，漏洞现在还能碰到，检测记录说明运维根本没做过基础加固。网络

我把这条记录写进检测表时，漏洞顺手翻了翻前几个月的检测记录存档。表格里躺着二十多条漏洞，网络高危的漏洞占了三分之一。有意思的检测记录是，同一个后台登录接口，网络三月份被扫出弱口令，漏洞六月份又出现在表里，检测记录只是换了台服务器。很多单位修漏洞就是打补丁式应付，修完不复查，也不做横向排查。

表里到底记什么

我的检测表结构不复杂，六列：发现时间、目标IP、漏洞类型、危险等级、验证方式、修复状态。有人喜欢加CVE编号，但实际工作中一半以上的漏洞没有正式编号——比如配置错误、目录遍历、敏感信息泄露。硬套编号反而拖慢记录速度。

危险等级我按实际可利用性来判。一个XSS漏洞如果只在后台自己页面弹窗，我标中危；能打到管理员Cookie的，直接高危。扫描器给的评分只能参考，它不知道业务逻辑。上个月某电商站点的订单查询接口，扫描器只报了信息泄露，我手工测了一下，改个订单号就能看到别人的收货地址和手机号。这种必须标高危，虽然扫描器只给了个“低风险”标签。

验证方式比漏洞类型更重要

表里“验证方式”这一列经常被忽略，但它决定了一条记录有没有实际价值。我见过太多检测报告只写“存在SQL注入”，不写怎么验证的。复现步骤缺失，开发人员拿到报告根本不知道从哪下手。

我的习惯是写清楚：请求方法、完整URL、Payload、返回特征。比如上面那条SQL注入，我记录的是“GET请求，参数id后加单引号，页面返回You have an error in your SQL syntax，且数据库版本泄露”。这样开发一看就明白。有些漏洞验证需要特定条件，比如需要登录态、需要特定Header，这些也得在表里备注。否则别人拿着表去复测，环境不对，还以为你误报。

修复状态别只写“已修复”

“已修复”三个字最害人。我要求自己写清楚修复动作和复测结果。比如“2024-06-12 开发已对id参数做整型强制转换，复测Payload返回空结果，确认修复”。这样下次再扫到类似问题，能快速判断是修复不彻底还是新出现的漏洞。

另外，修复状态要区分“已修复”和“已规避”。有些漏洞开发没改代码，只是在WAF加了条规则。这种情况我会标“已规避（WAF规则）”，因为一旦WAF策略调整，漏洞立刻复活。去年有个客户就是WAF规则被误删，三天后数据库被拖库。

表格之外的观察

检测表记录的是技术问题，但翻多了能看出管理问题。同一个开发团队负责的三个项目，漏洞类型高度相似——都是未过滤用户输入、都是硬编码密钥。这说明不是个人疏忽，是团队没有安全开发规范。我在表里加了一列“责任团队”，季度汇总时直接发给技术总监。比单条漏洞报告管用。

还有个小细节：我坚持用Excel而不是在线平台。在线平台导出麻烦，字段改不了，而且断网就抓瞎。Excel虽然土，但筛选、排序、加批注都顺手。唯一要注意的是加密存储，这表本身就是敏感信息——目标IP、漏洞详情、验证Payload，泄露出去等于给攻击者递刀子。

表里最近一条记录是昨天下午的。一个文件上传接口，只校验了Content-Type，改包就能传jsp。我标了高危，验证方式写的是“Burp抓包，修改filename为test.jsp，Content-Type改为image/jpeg，上传成功且可访问”。修复状态空着，等开发反馈。这种空着的格子，比填满的更让人睡不着觉。