漏洞扫描的漏洞测试报告

下午三点，我盯着屏幕上的扫描试报扫描结果，差点把咖啡泼在键盘上。漏洞一个内部系统的扫描试报漏洞扫描，居然拉出了17个高危项，漏洞其中三个是扫描试报可直接远程利用的RCE漏洞。开发组长在旁边嘟囔：“这系统上线前不是漏洞测过吗？”——测过，但测的扫描试报是功能，不是漏洞安全。这大概是扫描试报多数团队的真实写照。

写这份报告前，漏洞我翻了过往三个月的扫描试报扫描记录。有意思的漏洞是，每次扫描后修复率都超过90%，扫描试报可下个月再扫，漏洞新漏洞数量几乎持平。漏洞像韭菜，割一茬长一茬。我们不是在“修复漏洞”，而是在“追赶漏洞”。有个例子很典型：某次扫描发现SQL注入点，开发改了输入校验，但两个月后同一接口又出现相似的注入——因为新需求改了参数拼接方式，旧校验被绕过了。安全测试不是一次性的体检，更像持续的心电图监测。

说回这次测试。我用的是OpenVAS加手工验证组合，扫描目标是一个面向内部员工的考勤系统。自动化扫出47个条目，去重后真正有效的是23个。其中低危占大头，比如HTTP头部缺失、SSL证书弱加密算法——这些修复成本低，但容易被忽略。真正让我警觉的是两个中危：一个越权访问漏洞，普通员工能通过修改URL参数查看他人请假记录；另一个是文件上传点未限制类型，理论上可传webshell。手工验证后确认，越权漏洞确实存在，上传漏洞因服务器端有白名单过滤，风险降级为“需关注”。

报告里我特意用了“可复现步骤”而非“漏洞描述”，每个问题都附上截图和请求包。开发部反馈说，这让他们省去了猜测时间——以前报告写“存在XX漏洞”，他们还得自己琢磨怎么触发，现在直接照着步骤操作就能复现。修复优先级上，我没按常规的“高危-中危-低危”排序，而是按“暴露面大小×利用难度”重新排了序。那个越权漏洞排第一，因为它不需要任何前置条件，登录就能试，而RCE虽然危害大，但需要内网跳板机才能触达，实际风险反而低一些。

扫描报告交出去后，我加了句个人判断：“建议将漏洞扫描纳入CI/CD流水线，至少每周跑一次，而不是季度扫描。”这话带着点主观，但我是故意的——季度扫描的间隔里，系统可能被攻击者摸透好几轮了。有同事觉得我小题大做，说内部系统怕什么。我没反驳，只把去年某大厂内网被钓鱼攻击的新闻链接发到了群里，那事就是从内部考勤系统的一个越权漏洞撕开口子的。

修复确认是另一道坎。开发说“修好了”，不能直接信。我重新扫了那三个接口，越权漏洞确实堵上了，但新增了个参数校验错误——传入超长字符串会导致500报错，虽不是安全漏洞，却暴露了代码对异常输入处理不严谨。这类“次生问题”在修复过程中很常见，报告末尾我单独列了一栏“回归观察项”，提醒下个月扫描时重点跟踪。

写到最后，我习惯性想总结“本次扫描总体安全状况可控”，但删了。数据摆在那，17个高危项，可控个鬼。不如写句实在的：“本次扫描暴露的问题中，至少5个源于代码复用时的旧漏洞模式。建议团队做一次安全编码培训，比多买扫描工具管用。”工具能发现漏洞，但堵住漏洞的，最终还是写代码的人。