burpsuite进行漏洞扫描

Burp Suite 的行漏 Scanner 模块在 Professional 版里躺了很多年，但真正把它当日常漏洞扫描主力的洞扫人并不多。多数人还是行漏习惯把 Burp 当抓包改包工具，扫漏洞交给 AWVS 或 Xray。洞扫我一开始也这么干，行漏直到有一次目标站点上了 WAF，洞扫AWVS 的行漏请求被拦得七零八落，而 Burp 里手动爬过的洞扫流量直接丢进 Scanner，反而扫出了两个存储型 XSS。行漏从那之后，洞扫我的行漏流程就改成了：Burp 负责“懂业务”的扫描，外部扫描器负责“广撒网”。洞扫

先说清楚一件事，行漏Burp Scanner 的洞扫扫描能力分两块：主动扫描和被动扫描。被动扫描是行漏默认开着的，你浏览网站时它就在后台比对参数、检查响应头、找信息泄露，不额外发请求，隐蔽性高。主动扫描要手动触发，会对每个参数注入 payload，动静大但覆盖深。很多人只盯着主动扫描，忽略了被动扫描其实经常能捡到便宜——比如某个接口返回了 X-Powered-By: PHP/5.3，或者 cookie 里没设 HttpOnly，这些被动扫描都会记下来。

真正让 Burp Scanner 区别于其他工具的是它和 Proxy、Repeater、Intruder 的联动。你在 Proxy 里看到一条可疑请求，右键 Do active scan，它就直接拿这条请求去扫，连 cookie、token、自定义 header 都原样带上。这一点很关键。很多扫描器要你重新配认证，配完还不一定对。Burp 不用，你浏览器里怎么登的，它就怎么扫。我扫过一个前后端分离的后台，登录靠 JWT 放在 Authorization 头里，AWVS 配了半天没搞定，Burp 这边选中请求直接扫，十分钟出结果。

扫描配置里有几个地方值得调。Scan configuration 里可以选 Audit checks 的强度，默认是 Normal，遇到复杂业务建议调成 Thorough，但请求量会翻几倍。还有个容易被忽略的选项：Scan speed 里的 Throttle。目标站性能差或者有频率限制，把并发降下来，不然扫到一半 IP 被封，前面的活白干。我一般把并发控制在 5 到 10 之间，宁可慢点。

报告这块 Burp 做得不算漂亮，但够用。扫描完在 Scanner 标签页里能看到按严重程度分组的漏洞列表，点进去有请求响应、修复建议。导出报告支持 HTML 和 XML，HTML 版给开发看比较直观。有个小技巧：导出前在 Issue 里把误报标记成 False positive，报告会干净很多。Burp 的误报率不算低，尤其是 SQL 注入和路径遍历，扫出来先手动验证一遍再写进报告，不然开发那边测完发现是误报，下次你说什么他们都不信了。

最后说个实际场景。有次扫一个电商站，Burp 报了个 OS command injection，在某个图片处理接口的参数上。手工测了一下，确实能执行 sleep 5，但只能执行系统命令，读不到文件——权限卡得很死。这种漏洞算不算高危？按 CVSS 评分不低，但实际危害有限。Burp 不会帮你判断业务上下文，它只告诉你“这里有问题”。所以扫描结果永远只是起点，真正花时间的是验证和评估。工具再顺手，也替代不了人盯着响应包琢磨的那几分钟。