用命令行搜索 Burp Suite 项目文件中的 HTTP…

当需要从 .burp 项目文件中按正则搜索响应头/响应体、提取安全审计项、导出代理历史或站点地图数据时，用包装脚本调用 Burp 解析扩展进行查询。

适用场景

解决思路

1. 确认前置条件：安装 Burp Suite Professional，并从 github.com/BuffaloWill/burpsuite-project-file-parser 下载扩展，在 Burp 的 Extender → Extensions → Add 中加载该 JAR 文件。
2. 配置环境变量 BURP_JAVA（Java 可执行文件路径）和 BURP_JAR（burpsuite_pro.jar 路径）；macOS 用 /Applications/Burp Suite Professional.app/Contents/Resources/jre.bundle/Contents/Home/bin/java 与 .../app/burpsuite_pro.jar，Windows 用 C:\Program Files\BurpSuiteProfessional\jre\bin\java.exe 与 ...\burpsuite_pro.jar，Linux 用 /opt/BurpSuiteProfessional/jre/bin/java 与 .../burpsuite_pro.jar，并写入 shell profile 持久化。
3. 用包装脚本执行查询：{baseDir}/scripts/burp-search.sh /path/to/project.burp [FLAGS]；若不使用脚本，可直接运行 "$BURP_JAVA" -jar -Djava.awt.headless=true "$BURP_JAR" --project-file=/path/to/project.burp [FLAGS]。
4. 始终检查退出码：0 表示有输出可继续；1 表示用法错误或文件/Java/JAR 缺失，读消息修路径；3 表示完全无输出，不可当作“未找到”，需跑对照查询区分；4 表示输出非 JSON，说明扩展未加载、Burp 忽略了参数，需先安装扩展。
5. 遇到退出码 3 时运行对照查询：{baseDir}/scripts/burp-search.sh project.burp proxyHistory.request.headers | head -c 2000；若返回行说明解析器正常、窄查询确实无匹配；若仍退出 3 说明扩展未加载或项目无代理历史，需确认项目文件正确且非空，并请用户确认 Burp 的 Extensions 中已加载 burpsuite-project-file-parser；若退出 4 说明扩展未加载，不要对流量下结论。
6. 管道中不要依赖 $? 判断退出码（管道返回最后一个命令的状态）；改用 stderr 中的 'Error: the parser produced no output.' 或 'Error: Burp produced output, but not one JSON object' 判断，或使用 set -o pipefail 后读 $?，或读 ${PIPESTATUS[0]}。
7. 始终使用子组件过滤器而非完整转储：proxyHistory.request.headers、proxyHistory.request.body、proxyHistory.response.headers、proxyHistory.response.body、siteMap.request.headers、siteMap.request.body、siteMap.response.headers、siteMap.response.body；默认从 headers 开始，避免 response.body（体积巨大）。
8. 仅在查看 headers 后针对特定 URL 获取 body，且必须截断：先用 proxyHistory.response.headers 配合 jq 筛出感兴趣 URL，再用 responseBody='.*pattern.*' 搜索并截断 body。
9. 执行正则搜索：responseHeader='.*regex.*' 搜索响应头，输出 {"url":"...","header":"..."}；responseBody='.*regex.*' 搜索响应体，必须用 jq -c '.body = (.body[:1000] + "...[TRUNCATED]")' 截断到 1000 字符。
10. 提取审计项：运行 auditItems，返回 name、severity、confidence、host、port、protocol、url；审计项较小，可用 head -n 100 安全获取。
11. 检索前先用 wc -cl 检查记录数与字节数：行数 <50 安全、50-200 需收窄、200+ 过宽、1000+ 停止；字节 <50KB 安全、50-200KB 需收窄、200KB+ 过宽、1MB+ 停止；单条 10MB 响应会表现为高字节但仅 1 行，字节检查可捕获。
12. 若结果过宽则收窄：改用子组件过滤器、缩小正则（如用 .*X-Frame-Options.* 或 .*Content-Security-Policy.* 代替 .*）、用 jq 先过滤（如 select(.url | test("/api/"))）。
13. 始终截断输出：所有输出加 head -c 50000（最大 50KB），body 字段强制截断到 1000 字符；组合使用 head -n 50 | head -c 50000 同时限制记录数与字节数。
14. 按调查工作流执行：先明确目标（漏洞类型、端点、头模式），再查 auditItems 并按 severity 过滤，再按 confidence（Certain/Firm）过滤，再提取受影响 URL（jq -r '.url' | sort -u），再搜索原始流量获取上下文，最后人工验证每条发现。
15. 理解严重性与置信度组合：High + Certain 优先调查；High + Tentative 常为误报需先验证；Medium + Firm 值得调查但可能需人工验证；不要仅凭 severity 报告发现。
16. 注意代理历史可能不完整：可能因 scope 过滤、intercept 设置丢弃请求、浏览器流量未走 Burp 代理而缺失；找不到预期流量时检查原项目的 scope 与代理设置。
17. 注意 HTTP body 编码：响应体可能 gzip 压缩、chunked 或非 UTF-8，正则可能静默失败；若结果少于预期，检查是否压缩、改用更宽模式或先搜 headers、用 Burp UI 查看原始与渲染响应。
18. 拒绝常见错误捷径：不要凭“正则看起来没问题”就下结论（先在样本上验证）；不要认为 High severity 就必须修（看 confidence）；不要认为所有审计项都相关（按威胁模型过滤）；不要认为代理历史完整；不要认为 Burp 找到就是漏洞（需人工验证）；不要因搜索无结果就断定流量不存在（先看退出码，只有 0 才能说“未找到”）。
19. 输出为每行一个 JSON 对象，可用 jq 格式化（... | jq .）或用 grep 过滤（... | grep -i "sql injection"）。

适用边界 · 注意事项

• 未安装 Burp Suite Professional 或未加载 burpsuite-project-file-parser 扩展时不可用（退出码 4 即表示此情况）。
• 不要直接转储完整 proxyHistory 或 siteMap（可能达数 GB），也不要无截断地检索 responseBody。
• 不要将退出码 3 或 4 的空结果报告为“未找到匹配流量”，那是把工具问题误报为干净结论。