绿盟web应用漏洞扫描系统

第一次接触绿盟Web应用漏洞扫描系统（NSFOCUS WVS），绿盟是应用漏在一次内部安全自查里。当时开发同事甩过来一个登录接口，洞扫说“你随便测测”。描系手工试了SQL注入和XSS，绿盟半小时过去，应用漏只找到两个不痛不痒的洞扫反射型弹窗。后来把URL丢进WVS，描系二十分钟后报告出来，绿盟整整列了十七个问题——其中三个是应用漏高危的SQL注入，藏在分页参数和Cookie字段里，洞扫手工根本扫不到那么全。描系

这玩意本质上是绿盟个“爬虫+攻击库”的组合体。它先模拟正常用户去爬取目标站点的应用漏所有链接、表单、洞扫参数，把攻击面摸清楚。然后拿内置的几千条漏洞规则挨个试：SQL注入、XSS、命令执行、文件包含、CSRF、目录遍历……每一条规则对应一种具体的请求构造方式。比如检测SQL注入，它会往参数里塞单引号、and 1=1、sleep(5)这些payload，然后看响应状态码、页面内容变化、响应时间延迟。如果数据库报错信息回显了，或者页面返回了异常数据，就判定存在漏洞。

实际用下来，它的爬虫能力比想象中强。很多扫描器遇到JavaScript渲染的页面就歇菜，WVS支持配置代理和登录会话，能带着Cookie去爬。有次扫一个后台管理系统，需要先登录才能访问功能页。我在WVS里录入了登录请求的账号密码，它自动维持会话，把后台三十多个菜单全爬了一遍。不过也有翻车的时候——遇到前端用Vue做的单页应用，路由全靠hash跳转，爬虫只抓到一个入口页。这时候得手动导入URL列表，或者配合Burp Suite的站点地图一起用。

漏洞规则库更新挺勤。绿盟有个威胁研究团队，每周都会推新规则。去年Log4j2那个核弹级漏洞爆发后，第三天就收到了WVS的规则更新推送。扫描时能直接检测Log4shell，不用自己写POC。但规则多也有副作用：误报。特别是XSS检测，有些页面把用户输入原样输出在HTML里，但做了前端转义，WVS仍然会报“反射型XSS”。这时候得人工复核，看浏览器实际执行结果。我一般会把扫描报告导出成Excel，按“置信度”排序，先处理高置信度的，低置信度的批量标记为“待确认”。

扫描策略需要根据场景调。默认的“全量扫描”最彻底，但也最慢，一个中型站点跑两三个小时很正常。赶时间的话用“快速扫描”，只测高频漏洞，二十分钟出结果。如果是生产环境，一定要避开业务高峰期，并且把“拒绝服务检测”关掉——有些规则会发送大量请求，可能把老旧的Tomcat打挂。我习惯在测试环境先跑一遍全量，确认没有误杀后再对生产环境做快速扫描。

报告输出是它比较务实的地方。除了标准的HTML和PDF，还能生成XML和JSON格式，方便对接Jira或者内部的漏洞管理平台。每一条漏洞都带请求包和响应包，开发人员照着复现就行。有次给开发团队培训，直接拿WVS的报告当案例，指着里面的payload说“你看，这个单引号导致数据库报错，说明参数没过滤”。比空口讲OWASP Top 10直观多了。

要说缺点，界面确实有点老气，像是十年前的Web风格。扫描大站点时内存占用高，得给它单独分配4G以上堆内存。另外对WebSocket和GraphQL的支持还在完善中，遇到这类接口得靠手工补充。不过对于常规的HTTP/HTTPS应用，它仍然是性价比很高的选择——比Burp Suite Professional便宜，比AWVS的规则更贴近国内漏洞环境。

最后说个真实案例。某次扫描一个电商网站，WVS报了一个“任意文件读取”漏洞，参数是`?file=../../etc/passwd`。开发一开始不信，说“我们用了Spring Security，路径都过滤了”。结果我当场用curl复现，返回了系统用户列表。后来查代码发现，过滤逻辑只拦截了`..\`，没拦`../`。这种细节，手工测试很容易漏，但扫描器的规则库里有几百种路径穿越的变体。工具不能替代人，但能让人少犯懒。