一个扫描器把 http://test.com/product.php?id=1 扔进请求队列，然后它开始替换那个 id 参数的洞扫的原值。换成 1'，描器换成 1 AND 1=1，漏理换成 1 AND 1=2。洞扫的原服务器返回的描器页面长度变了——从 4523 字节变成 4517 字节。扫描器记下：这个参数可能有 SQL 注入。漏理整个过程不到两秒，洞扫的原没人手动点过任何按钮。描器

这就是漏理 web 漏洞扫描器最核心的动作：把请求当实验，把响应当证据。洞扫的原它不“理解”网站的描器业务逻辑，也不需要知道这个 product.php 背后是漏理查库存还是查订单。它只做一件事——发一个精心构造的洞扫的原请求，看服务器怎么回。描器回了异常，就标记；回了正常，就跳过。就这么简单，也这么粗暴。

但“异常”怎么定义？这里面的门道比想象中深。早期扫描器主要靠特征匹配，比如响应里出现 You have an error in your SQL syntax 这种 MySQL 报错，或者 Warning: include() 这种 PHP 警告，就直接判定漏洞存在。这招很灵，因为很多开发环境没关错误显示。可一旦网站把报错关了，返回一个干净的 500 页面，特征匹配就瞎了。

于是有了盲注检测的思路。扫描器不再依赖报错文本，而是看时间或布尔状态。举个例子：它发一个 1' AND SLEEP(5)--，如果响应真的卡了 5 秒，那就说明 SQL 注入成立。或者发两个请求，一个条件为真，一个条件为假，比较页面差异。这种“盲”检测慢得让人抓狂，但能挖出那些藏得很深的洞。

XSS 的检测逻辑又不太一样。扫描器会往参数里塞 <script>alert(1)</script>，然后去响应里找这段脚本是不是原样出现了。但光出现还不够——得判断它是在 HTML 正文里，还是在属性值里，有没有被转义。我见过一个扫描器把 <script> 这种已经转义的输出误报成 XSS，结果开发拿着报告找过来，场面一度很尴尬。

文件包含漏洞的扫描更有意思。扫描器会尝试 ?file=../../../../etc/passwd，然后看响应里有没有 root:x:0:0。这招在 Linux 上特别好使。但有些网站用了 include($_GET['file'].'.php')，你传 ../../etc/passwd 没用，得传 ../../etc/passwd%00——这是老版本 PHP 的截断技巧。扫描器的 payload 列表里要是没这条，就漏了。

扫描器还有一个隐蔽的活儿：爬虫。它得先知道网站有哪些 URL、哪些参数。一个电商网站可能有几千个带 id 参数的链接，扫描器不可能全测一遍，否则请求量爆炸。所以它要判断哪些参数“看起来可注入”——比如名字叫 id、page、file 的，优先级调高；叫 color、size 的，先放一放。这种启发式规则不完美，但比无差别轰炸聪明多了。

真正麻烦的是 误报和漏报。一个扫描器报了一百个 SQL 注入，可能九十个是假的——因为页面差异只是随机广告轮播导致的。反过来，一个需要特定 Cookie 或 Referer 头才能触发的漏洞，扫描器没带对头，就永远测不出来。我见过一个后台漏洞，只有登录后才存在，但扫描器没登录，扫了一整天什么也没发现。后来手动加了个 Cookie，三分钟就出来了。

所以现在的扫描器都在往“交互式”方向走。比如 IAST（交互式应用安全测试），在服务器里插个 Agent，扫描器发请求时，Agent 直接监控代码执行路径。SQL 语句拼接到没拼接、命令执行函数调没调用，Agent 全知道。这比黑盒猜响应准得多。但代价是得改服务器环境，很多生产系统不让装。

说到底，扫描器的原理就是自动化地做安全测试人员手动会做的事：构造恶意输入、观察异常输出、推断漏洞存在。它快、它不知疲倦、它能覆盖大量 URL。但它也笨——不懂业务、不会推理、容易被 WAF 骗。你把它当第一道筛子用，没问题；指望它挖出所有漏洞，那是做梦。