企业官网建设流程全解析

• AI 技能
• AI 插件

导读

burpsuite-project-parser是 agentic-awesome-skills（AAS）仓库中一个面向安全审计场景的社区技能，它让 Agent 能够通过命令行对 Burp Suite 的项目文件（.burp）进行结构化检索：按正则搜索响应头与响应体、提取安全审计发现（audit items）、转储代理历史（proxy history）与站点地图（site map）数据。本文围绕该技能的 SKILL.md 展开，完整讲解其前置条件、包装脚本用法、子组件过滤器、输出容量管控、调查工作流与结果解读方法，帮助读者掌握一套"在受控上下文内安全检索大型 HTTP 流量数据"的实战方案。读完本文，你将能够基于 Burp Suite Professional 对历史项目文件进行高效的只读分析，并避免因数据量过大而撑爆 Agent 上下文窗口的经典陷阱。

技能定位：何时使用本技能

技能元数据（frontmatter）给出了清晰的边界：allowed-tools仅包含Bash与Read，risk标记为critical，source为community，date_added为2026-09-04。从源码结构看，该技能在仓库中同时存在于 plugins/agentic-awesome-skills-claude/skills/burpsuite-project-parser/SKILL.md 与 skills/burpsuite-project-parser/SKILL.md 两处（后者为前者的镜像部署），内容一致。

适合使用本技能的典型任务包括：

• 使用正则表达式检索响应头或响应体；
• 从 Burp 项目中提取安全审计发现；
• 转储代理历史或站点地图数据；
• 分析 Burp 项目文件中捕获的 HTTP 流量。

换言之，当任务目标聚焦于"对既有的.burp项目文件做离线、只读的取证式检索"时，本技能就是最贴合的工具；而在主动扫描、漏洞利用等场景下，则应交给仓库中的 pentest-tools 等主动安全技能处理。

工作原理与前置条件

委托解析：技能本身不解析.burp文件

关键前提：本技能将解析工作委托给 Burp Suite Professional，而不是自行解析.burp二进制/序列化格式。这意味着运行环境必须满足两项硬性要求：

1. Burp Suite Professional已安装；
2. burpsuite-project-file-parser 扩展已安装，它提供了 CLI 功能入口。

扩展安装步骤

在 Burp Suite 中按以下流程加载扩展 JAR：

1. 从 burpsuite-project-file-parser 项目下载扩展包；
2. 打开 Burp Suite，进入Extender → Extensions → Add；
3. 选择下载的 JAR 文件完成加载。

由于整个链路最终通过 Java 启动 Burp Suite 的burpsuite_pro.jar并以无头（headless）模式解析项目文件，因此本技能对运行环境的 Java 与 JAR 路径有强依赖，下文"平台配置"会给出三套系统的标准路径。

快速上手：包装脚本与平台配置

统一入口burp-search.sh

技能推荐通过包装脚本统一调用：

{baseDir}/scripts/burp-search.sh /path/to/project.burp [FLAGS]

其中{baseDir}表示技能安装目录（即scripts/burp-search.sh所在目录，随技能部署到本地 Agent 环境）。脚本通过两个环境变量定位 Burp 运行时，以保证跨平台兼容：

• BURP_JAVA：Java 可执行文件路径；
• BURP_JAR：burpsuite_pro.jar路径。

三平台环境变量配置

macOS

export BURP_JAVA="/Applications/Burp Suite Professional.app/Contents/Resources/jre.bundle/Contents/Home/bin/java" export BURP_JAR="/Applications/Burp Suite Professional.app/Contents/Resources/app/burpsuite_pro.jar"

Windows（PowerShell）

$env:BURP_JAVA = "C:\Program Files\BurpSuiteProfessional\jre\bin\java.exe" $env:BURP_JAR = "C:\Program Files\BurpSuiteProfessional\burpsuite_pro.jar"

Linux

export BURP_JAVA="/opt/BurpSuiteProfessional/jre/bin/java" export BURP_JAR="/opt/BurpSuiteProfessional/burpsuite_pro.jar"

建议将这些导出语句写入 shell 配置文件（.bashrc、.zshrc等）以便持久生效。

手动调用方式

如果不使用包装脚本，也可以直接调用底层命令（注意-Djava.awt.headless=true用于无头环境）：

"$BURP_JAVA" -jar -Djava.awt.headless=true "$BURP_JAR" \ --project-file=/path/to/project.burp [FLAGS]

子组件过滤器：永远不要整包转储

技能反复强调一条铁律：完整转储proxyHistory或siteMap可能返回数 GB 数据，必须改用子组件过滤器（sub-component filters），只取所需字段。这是控制上下文占用、避免 Agent 上下文溢出的第一道防线。

可用过滤器一览

默认策略：从头开始，而不是从 body 开始

正确的检索顺序是"先头后体"：

# 正确做法——仅取头部，安全 {baseDir}/scripts/burp-search.sh project.burp proxyHistory.request.headers | head -c 50000 {baseDir}/scripts/burp-search.sh project.burp proxyHistory.response.headers | head -c 50000 # 错误做法——完整记录包含 body，可能达到 GB 级 {baseDir}/scripts/burp-search.sh project.burp proxyHistory # 永远不要这样做

只有先通过头部找到感兴趣的具体 URL 后，才针对性地抓取 body，并且必须截断：

# 第一步：先从响应头中筛选出感兴趣的 URL（例如 text/html 页面） {baseDir}/scripts/burp-search.sh project.burp proxyHistory.response.headers | \ jq -r 'select(.headers | test("text/html")) | .url' | head -n 20 # 第二步：用定向正则搜索 body——body 必须截断到 1000 字符以内 {baseDir}/scripts/burp-search.sh project.burp "responseBody='.*specific-pattern.*'" | \ head -n 10 | jq -c '.body = (.body[:1000] + "...[TRUNCATED]")'

硬性规则：超过 1000 字符的 body 内容严禁进入上下文。如果用户确实需要查看完整 body，应引导其在 Burp Suite 的 UI 中查看，而不是让 Agent 拉取全文。

正则搜索操作

搜索响应头：responseHeader

基本形式：

responseHeader='.*regex.*'

该操作会在所有响应头中执行正则匹配，输出格式为{"url":"...", "header":"..."}。

示例——查找服务器签名：

responseHeader='.*(nginx|Apache|Servlet).*' | head -c 50000

搜索响应体：responseBody

基本形式：

responseBody='.*regex.*'

强制要求：响应体内容最多截断到 1000 字符。每个响应体可能高达数 MB，稍有不慎就会耗尽上下文窗口。

# 规定格式——始终截断 .body 字段 {baseDir}/scripts/burp-search.sh project.burp "responseBody='.*<form.*action.*'" | \ head -n 10 | jq -c '.body = (.body[:1000] + "...[TRUNCATED]")'

永远不要检索完整 body 内容。如果需要查看更多特定响应，请用户在 Burp Suite 的 UI 中打开查看。

其他操作：审计项与两大禁区

提取审计项：auditItems

auditItems

返回所有安全审计发现，输出字段包括：name、severity、confidence、host、port、protocol、url。

注意：审计项本身很小（不包含 body），用head -n 100即可安全检索。

转储代理历史：proxyHistory（避免）

proxyHistory

绝不要直接使用。应使用子组件过滤器替代：

• proxyHistory.request.headers
• proxyHistory.response.headers

转储站点地图：siteMap（避免）

siteMap

绝不要直接使用，应使用子组件过滤器替代。

输出限制：上下文保护的强制流程

关键警告：检索数据前必须先检查结果规模。一次宽泛搜索可能返回数千条记录，而每条记录可能高达数 MB，这将导致上下文窗口溢出。技能为此设计了严格的三步流程。

第一步：永远先检查规模

任何搜索之前，必须同时检查记录数与字节数：

# 检查记录数与总字节数——这一步不可跳过 {baseDir}/scripts/burp-search.sh project.burp proxyHistory | wc -cl {baseDir}/scripts/burp-search.sh project.burp "responseHeader='.*Server.*'" | wc -cl {baseDir}/scripts/burp-search.sh project.burp auditItems | wc -cl

wc -cl的输出格式为<字节数> <行数>。例如524288 42表示 42 条记录、共 512KB。

结果解读——两个指标都必须达标：

特别提醒：单条 10MB 的响应可能只有 1 行，此时行数指标会"骗人"，字节数指标才能兜底捕捉。

第二步：收窄过宽的搜索

如果计数/规模过高，按以下优先级收窄：

1. 改用子组件过滤器（见上文表格）：

   # 替代方案：proxyHistory（GB 级） # 改用：proxyHistory.request.headers（KB 级）

2. 收窄正则模式：

   # 过宽（匹配一切）： responseHeader='.*' # 更好——定向匹配具体头部： responseHeader='.*X-Frame-Options.*' responseHeader='.*Content-Security-Policy.*'

3. 先经 jq 过滤再检索：

   # 只取特定内容类型 {baseDir}/scripts/burp-search.sh project.burp proxyHistory.response.headers | \ jq -c 'select(.url | test("/api/"))' | head -n 50

第三步：始终截断输出

即使已经收窄，仍需经截断管道处理：

# 始终用 head -c 限制总字节数（上限 50KB） {baseDir}/scripts/burp-search.sh project.burp proxyHistory.request.headers | head -c 50000 # 对 body 搜索，逐条截断每个 JSON 对象的 body 字段： {baseDir}/scripts/burp-search.sh project.burp "responseBody='pattern'" | \ head -n 20 | jq -c '.body = (.body | if length > 1000 then .[:1000] + "...[TRUNCATED]" else . end)' # 同时限制记录数与字节数： {baseDir}/scripts/burp-search.sh project.burp auditItems | head -n 50 | head -c 50000

必须强制执行的硬性限制：

• 所有输出统一使用head -c 50000（50KB 上限）；
• .body字段截断到 1000 字符——强制执行，无任何例外：

  jq -c '.body = (.body[:1000] + "...[TRUNCATED]")'

未经"先计数 + 再截断"就运行的禁区命令：

• proxyHistory/siteMap（完整转储——始终改用子组件过滤器）；
• responseBody='...'搜索（每个 body 可能数 MB）；
• 任何宽泛正则，如.*或.+。

调查工作流：六步取证式分析

技能给出了一套经过实践验证的六步调查流程，从宏观发现逐步收敛到微观证据：

1. 界定范围——明确要找什么（具体漏洞类型、端点、头部模式）。

2. 先查审计项——从 Burp 自身的安全发现开始：

   {baseDir}/scripts/burp-search.sh project.burp auditItems | jq 'select(.severity == "High")'

3. 核查置信度——筛选可行动的发现：

   ... | jq 'select(.confidence == "Certain" or .confidence == "Firm")'

4. 提取受影响 URL——摸清攻击面：

   ... | jq -r '.url' | sort -u

5. 检索原始流量作为上下文——检查实际的请求/响应：

   {baseDir}/scripts/burp-search.sh project.burp "responseBody='pattern'"

6. 人工验证——Burp 的发现只是"指标"而非"证据"，每一条都要验证。

理解结果：严重度、置信度与数据陷阱

严重度 vs 置信度

Burp 同时报告严重度（High/Medium/Low）与置信度（Certain/Firm/Tentative）。分流处置时必须两者结合：

一个"高严重度 + 不确定置信度"的发现经常是误报。不要仅凭严重度就下结论。

代理历史为何不完整

代理历史只包含 Burp 实际捕获到的流量，可能因以下原因缺失：

• 作用域过滤器排除了某些域名；
• 拦截设置丢弃了部分请求；
• 浏览器流量未经过 Burp 代理。

如果找不到预期流量，应回到原项目中检查 Burp 的 scope 与代理设置。

HTTP body 编码陷阱

响应体可能经过 gzip 压缩、chunked 分块或使用非 UTF-8 编码。在明文上有效的正则可能在编码响应上静默失败。若搜索结果远少于预期：

• 检查响应是否被压缩；
• 尝试更宽泛的模式，或先搜头部；
• 使用 Burp 的 UI 对比原始响应与渲染响应。

需要拒绝的常见"合理化借口"

技能专门列出了一些常见捷径及其错误原因，这些捷径往往导致漏报或误报：

输出格式与实战示例

所有输出均为JSON，每行一个对象，可管道到jq格式化：

{baseDir}/scripts/burp-search.sh project.burp auditItems | jq .

也可以配合 grep 过滤：

{baseDir}/scripts/burp-search.sh project.burp auditItems | grep -i "sql injection"

技能内置的四个代表性示例（均带有容量限制）：

搜索 CORS 相关响应头（带字节上限）：

{baseDir}/scripts/burp-search.sh project.burp "responseHeader='.*Access-Control.*'" | head -c 50000

提取全部高严重度发现（审计项很小，但仍需限制）：

{baseDir}/scripts/burp-search.sh project.burp auditItems | jq -c 'select(.severity == "High")' | head -n 100

仅提取代理历史中的请求 URL：

{baseDir}/scripts/burp-search.sh project.burp proxyHistory.request.headers | jq -r '.request.url' | head -n 200

搜索响应体（body 必须截断到 1000 字符）：

{baseDir}/scripts/burp-search.sh project.burp "responseBody='.*password.*'" | \ head -n 10 | jq -c '.body = (.body[:1000] + "...[TRUNCATED]")'

局限与使用边界

• 仅在任务明确落入上文所述范围内使用本技能；
• 输出不能替代针对特定环境的验证、测试或专家评审；
• 若缺少必要的输入、权限、安全边界或成功标准，应停下来向用户澄清。

结合技能元数据中的risk: critical与allowed-tools仅含 Bash/Read 的设计，可以看出该技能刻意保持"只读检索 + 结果截断"的克制姿态：它把解析能力委托给 Burp Suite Professional，把数据安全交给wc -cl预检与jq截断两道闸门，从而让 Agent 可以在大型历史流量数据上安全、高效地完成取证式检索——这正是本技能在 AAS 安全技能体系中不可替代的价值所在。

• AI 技能
• AI 插件