web漏洞扫描器

凌晨两点，洞扫某电商平台的描器告警群里炸了锅。安全工程师老周盯着屏幕，洞扫数据库里多出了几万条用户手机号——攻击者用的描器是个老掉牙的SQL注入点，藏在搜索框的洞扫参数里。这套系统上线前，描器甲方拍着胸脯说“扫过，洞扫没问题”。描器可他们扫的洞扫是首页和登录接口，没人去碰那个没人维护的描器旧版搜索模块。

这就是洞扫漏洞扫描器的尴尬：它像个体检医生，你说哪儿疼它查哪儿，描器但你没说的洞扫地方，它默认没事。描器可真正的洞扫攻击者从来不按体检表来。

市面上的扫描器分两类。一类是黑盒的，模拟黑客从外部发请求，看响应判断有没有漏洞。另一类白盒的，直接看源代码，像代码审计的自动化版。黑盒的误报率能到40%，漏报率也不低——它看不见逻辑漏洞，比如“验证码发到旧手机号”这种业务缺陷。白盒的准一些，可你得有源码，还得让开发配合部署环境，落地成本高得吓人。

我见过最离谱的案例：某银行用商业扫描器跑了三个月，报告显示“零高危”。结果渗透测试团队用两天时间，在一个文件上传接口里塞了个图片马，直接拿到服务器权限。问题出在哪儿？扫描器只测了常规的`Content-Type`校验，可人家服务端压根没检查文件头。这种“配置与代码不匹配”的盲区，机器测不出来，得靠人猜。

所以现在稍微靠谱点的团队都在搞“扫描器+人工验证”的混合模式。机器跑完出清单，安全工程师挑重点手工复测。但人工成本高，一天也就测十几个点。有个取巧的办法：把扫描器接进CI/CD流水线，每次代码提交自动触发，只扫变更的部分。这样漏网之鱼会少很多，但前提是开发愿意改代码——你扫出问题，他们得修，修慢了业务上线就卡住。这活儿不好干，容易得罪人。

更糟的是，扫描器本身也会被攻击。去年有个开源的扫描器爆出RCE漏洞，攻击者构造恶意请求，反手把扫描器所在的内网机器给控制了。你想抓贼，结果贼顺着你的棍子爬进你家。所以用扫描器的人得记住：它只是个工具，不是信任边界。扫出来的结果要当参考，不能当圣旨。

说回老周那个案子。事后复盘发现，那个旧搜索模块是三年前外包团队写的，代码注释里还留着测试用的调试接口，密码是`admin123`。扫描器没扫到，是因为这个接口没在路由表里注册，直接通过硬编码的URL访问。这种“影子资产”才是真正的雷。你连系统里有多少个入口都不知道，扫描器再强也是瞎的。

我的建议是：先梳理资产，把所有子域名、IP段、接口文档翻出来，建个清单。然后让扫描器带着清单去跑，比裸跑强十倍。要是连资产都理不清，那就别急着上扫描器——先花钱请人做次渗透测试，把底儿摸透了再说。工具永远替代不了思考，就像CT机替代不了医生。扫描器能告诉你哪儿可能有病，但要不要做手术，还得人来判断。