扫描网页漏洞软件

打开一个电商网站，扫描在搜索框里敲入一个单引号，网页页面突然弹出一段数据库报错——这是漏洞SQL注入最经典的入口。扫描网页漏洞的软件软件，干的扫描就是这种事：模拟攻击者的手法，把类似单引号这样的网页“探针”批量送进表单、URL参数、漏洞HTTP头，软件看目标会不会露出不该露的扫描马脚。

这类工具早就不止一种流派。网页一类是漏洞代理型，比如Burp Suite和OWASP ZAP。软件它们把自己架在浏览器和服务器之间，扫描你点哪里它记哪里，网页然后你手动改包、漏洞重放、插payload。用起来像拿着一把手术刀，精准但慢。另一类是自动化扫描器，像Acunetix、Netsparker，还有开源的Skipfish。填个域名，点开始，它自己爬链接、跑规则库、出报告。快是真快，误报也是真多。我见过一个政府站点被某商业扫描器标出“高危XSS”，点开详情一看，反射参数里确实出现了<script>，但服务器返回的Content-Type是text/plain，浏览器根本不执行。工具不懂上下文，只认字符串匹配。

真正有意思的是扫描逻辑本身。拿爬虫来说，多数工具靠正则提取href和action，遇到JavaScript动态生成的链接就瞎了。现代前端框架一上，路由全是#/user/123这种hash模式，传统爬虫直接卡死。所以现在稍微像样的扫描器都开始集成headless浏览器，用Puppeteer或者Playwright驱动一个真实内核去点按钮、填表单。代价是速度暴跌，扫一个中型站点从十分钟变成两小时。值不值？看你扫的是登录后的后台还是公开的静态页。

漏洞检测的规则库才是核心资产。SQL注入的payload从基础的' OR '1'='1进化到时间盲注的'; WAITFOR DELAY '0:0:5'--，再到利用编码绕WAF的%27%20OR%201%3D1。XSS更花哨，从<script>alert(1)</script>到<img src=x onerror=alert(1)>，再到javascript:alert(1)塞进href。规则写得好不好，直接决定漏报率。我试过用某开源工具扫一个已知存在存储型XSS的留言板，它没报——因为payload被存进数据库后，在页面渲染时经过了HTML实体编码，但工具只检查了请求响应，没做二次访问。存储型XSS的检测，必须带“提交后回访”的逻辑，很多轻量级扫描器省了这步。

误报和漏报永远在打架。调高敏感度，满屏红字，运维骂你狼来了；调低敏感度，真漏洞溜过去，甲方骂你废物。我的习惯是：自动化扫一遍，把结果当线索而不是结论。看到可疑点，手动用Burp重放一次，观察响应差异、时间延迟、数据库报错特征。工具负责广度，人负责深度。一个扫描器能发现70%的常见漏洞就算合格，剩下30%靠经验补。

别指望装个软件就能高枕无忧。上周我用ZAP扫自己搭的测试站，它报了个“CSRF token缺失”，但我明明在表单里加了hidden字段。查了半天发现是ZAP的爬虫没执行JavaScript，没拿到动态生成的token。换用带headless模式的扫描器，误报消失。工具是死的，场景是活的。扫之前先想清楚：目标用了什么框架、有没有WAF、哪些接口需要登录态。配置不对，再贵的扫描器也是废铁。

最后说个真事。某次帮朋友看一个WordPress站，用WPScan扫出插件漏洞，提示“Contact Form 7 < 5.3.2 存在 unrestricted file upload”。他吓得要死。我登进去一看，插件版本确实低，但那个上传功能被主题里的current_user_can('manage_options')卡死了，只有管理员能用。扫描器只比对版本号，不读代码逻辑。所以——工具给的是可能性，不是确定性。自己动手验证，比什么都强。