Burp Suite 官方 MCP：把 AI Agent 接进 Web 安全测试工作台

原创

lidasimida
lidasimida

安全学习之路

2026年6月19日 09:49
广东

在小说阅读器读本章

去阅读

Burp Suite 官方 MCP：把 AI Agent 接进 Web 安全测试工作台

适用边界：本文只讨论授权 Web 安全测试、内部安全评估、团队工作流和工具治理；不提供真实目标攻击步骤、绕过技巧、payload 构造或未授权测试方法。

目录

先给结论：Burp MCP 的重点不是“自动攻击”，而是“可控使用 Burp”

一、先把连接跑通：Burp 扩展、SSE、stdio proxy 和客户端配置

二、真正开始用之前：三类权限必须先设好

三、工具应该怎么选：按任务而不是按工具名使用

四、从只读开始：让 Agent 整理 Proxy History 和 Organizer

五、交给人工验证：让 Agent 创建 Repeater / HTTP2 Repeater 工作台

六、受控执行：什么时候才让 Agent 发送请求

七、复杂场景手册：12 个可落地工作流

八、Prompt 模板：让 Agent 按证据工程输出

九、排障手册：连不上、工具不可见、审批被拒、结果太长怎么办

十、团队落地：从个人试用到安全团队规范

FAQ：读者最容易误解的 14 个问题

专业术语注释

参考资料

先给结论：Burp MCP 的重点不是“自动攻击”，而是“可控使用 Burp”

Burp 官方 MCP 的正确打开方式，不是让模型替人做渗透测试，而是让 Agent 在授权边界内调用 Burp 的工具能力：读取历史、筛选线索、创建 Repeater 标签页、整理 Scanner 发现、记录 Collaborator 证据、辅助配置治理和输出报告草稿。

如果只讲 MCP 原理，这篇文章就没讲到点上。真正要讲清楚的是：连接成功以后，面对复杂 Web 测试场景，应该让 Agent 调哪些 Burp MCP tools、按什么顺序调、输出什么材料、哪里必须人工确认、哪里绝对不能自动化。

图 1：Burp MCP 接入架构

一、先把连接跑通：Burp 扩展、SSE、stdio proxy 和客户端配置

PortSwigger 官方仓库是 PortSwigger/mcp-server，仓库描述为 MCP Server for Burp，主要语言是 Kotlin，许可证是 GPL-3.0。本文按 v1.3.0 写，release 时间为 2026-05-26T17:56:07Z，资产为 burp-mcp-all.jar，大小 18,817,739 bytes，digest 为 sha256:c4011245ee7da0cb901b9c0435aba3d8458ab5b0e2078e1a87fd025ed93c7892。企业环境建议固定版本、校验 digest，再加载扩展。

官方 README 给出的基础链路是：先把 Burp MCP 扩展加载进 Burp Suite，再在 Burp 的 MCP tab 中启用服务，最后让 MCP Client 连接 Burp 的 SSE 服务或 stdio proxy。默认监听地址是 http://127.0.0.1:9876，这意味着它默认适合本机 Burp 与本机 AI Client 协作，不应该随便暴露到不可信网络。

步骤	做什么	验收标准	常见问题
1. 获取扩展	从官方 release 下载 JAR，或从源码执行 ./gradlew embedProxyJar 构建。	JAR 来源固定，版本和 digest 有记录。	不要加载来源不明的 Burp 扩展。
2. 加载 Burp 扩展	Burp 的 Extensions 中选择 Java 扩展并加载 JAR。	Extensions 无报错，出现 MCP tab。	Java 版本、JAR 路径、Burp 扩展日志。
3. 启用 MCP server	在 MCP tab 打开 Enabled，确认 host/port。	默认 127.0.0.1:9876 可用。	端口冲突、防火墙、代理、客户端 URL 拼错。
4. 配置 Client	支持 SSE 的客户端直连；只支持 stdio 的客户端走 proxy。	客户端能看到 Burp tools。	Claude Desktop 常见模式是 stdio proxy 转 SSE。
5. 做最小验证	先让 Agent 只调用编码工具或只读工具。	能返回结果，不触发发包或配置修改。	不要一开始就让 Agent 发送请求。

手工配置 Claude Desktop 时，README 给出的形态是让 Claude 启动 Java proxy，再通过 --sse-url 指向 Burp MCP server。示意如下：

{

\"mcpServers\": {

\"burp\": {

\"command\": \"\",

\"args\": [

\"-jar\",

\"/path/to/mcp/proxy/jar/mcp-proxy-all.jar\",

\"--sse-url\",

\"http://127.0.0.1:9876\"

]

}

}

}

这里有一个容易忽略的工程判断：配置成功不等于可以放开使用。连接只是第一步，真正要配置的是权限。

二、真正开始用之前：三类权限必须先设好

从 v1.3.0 源码看，Burp MCP 不是完全裸奔。HTTP 请求发送会检查请求权限；HTTP history、WebSocket history、Organizer 读取会检查数据访问权限；配置写入默认由 configEditingTooling 控制。也就是说，它本身已经把“读数据”和“发请求”拆成了不同的审批面。

权限面	对应配置 / 行为	默认建议	为什么
数据访问审批	HTTP history、WebSocket history、Organizer 读取会触发数据访问确认。	新项目先 Allow Once，不要一上来 Always Allow。	History 里可能有 Cookie、Token、账号、内部接口和个人数据。
请求发送审批	send\_http1\_request / send\_http2\_request 会走 host/port 审批或自动批准名单。	只给授权测试环境加白名单。	发请求会影响真实系统，和只读整理不是一个风险等级。
配置编辑开关	Enable tools that can edit your config 控制配置写入工具。	默认关闭。	Burp 配置会影响代理、扫描、上游认证、项目行为和证据可信度。
凭据过滤	filterConfigCredentials 默认应保持开启。	开启。	v1.3.0 release 明确提到 credential filter 和 malformed JSON fail closed。
本地监听	host 默认 127.0.0.1。	不改成公网或泛地址。	Burp 工作台里是敏感安全测试上下文。

图 2：Burp MCP 权限边界

安全地使用 Burp MCP，可以把工具分成三层：第一层只读整理，第二层创建工作台入口，第三层受控执行。只读工具可以帮你省时间；工作台入口可以让 AI 和人协作；受控执行必须有授权、审批、日志和回滚。

三、工具应该怎么选：按任务而不是按工具名使用

v1.3.0 源码中最多注册 27 个 tools，其中 3 个只在 Burp Suite Professional edition 下注册。工具很多，但使用时不要从“我能调用什么”出发，而要从“我要完成什么工作”出发。

图 3：Burp MCP v1.3.0 工具全景

任务	首选工具	可选工具	不建议一开始用
编码/解码/临时字段	url\_encode, url\_decode, base64\_encode, base64\_decode, generate\_random\_string	get\_active\_editor\_contents	任何发请求工具
整理接口清单	get\_proxy\_http\_history, get\_proxy\_http\_history\_regex	get\_organizer\_items	send\_http1\_request, send\_http2\_request
整理 WebSocket 线索	get\_proxy\_websocket\_history, get\_proxy\_websocket\_history\_regex	Organizer 工具	自动构造消息重放
把线索交给人验证	create\_repeater\_tab, create\_repeater\_tab\_http2	set\_active\_editor\_contents	自动扩大测试范围
准备参数化测试	send\_to\_intruder	Repeater 工具	无人值守跑高频测试
读取扫描发现	get\_scanner\_issues	Organizer 工具	让 Agent 直接下最终漏洞结论
OOB 证据闭环	generate\_collaborator\_payload, get\_collaborator\_interactions	Scanner issue 关联	未授权目标上的外带验证
配置治理	output\_project\_options, output\_user\_options	set\_project\_options, set\_user\_options	默认开放配置写入
控制 Burp 状态	set\_proxy\_intercept\_state, set\_task\_execution\_engine\_state	当前编辑器工具	让 Agent 频繁切换影响人工操作

图 4：Burp MCP 使用决策树

这个决策树的核心是：让 Agent 先读和整理，再创建工作台入口，最后才考虑受控执行。大多数团队第一次接入时，第一周只应该使用只读和 Repeater 创建能力。

四、从只读开始：让 Agent 整理 Proxy History 和 Organizer

只读模式是最适合落地的第一步。你先用 Burp 正常代理授权测试流量，然后让 Agent 调用 history 和 Organizer 工具，把材料整理成测试清单、接口地图、证据索引和复核任务。

场景 1：从 Proxy History 生成接口资产清单

材料：授权测试期间经过 Burp Proxy 的 HTTP 请求和响应。

工具链：get\_proxy\_http\_history(count, offset) 分页读取；必要时用 get\_proxy\_http\_history\_regex(regex, count, offset) 缩小范围。

Agent 输出应该包含：host、method、path、status、content-type、是否登录后访问、是否包含敏感头、是否值得人工复核。不要输出完整 Cookie 和 Authorization 原文。

人工确认点：剔除第三方域名、静态资源、非授权目标和含个人数据的响应；确认接口是否属于本次授权范围。

可用提示词：

只使用 Burp 的只读 history 工具。请按授权目标范围整理接口清单：

1. 按 host / method / path / status 聚合。

2. 标记登录、上传、管理、支付、导出、回调、WebSocket 入口。

3. 不要调用 send\http1\_request、send\_http2\_request、send\_to\_intruder、set\\* 工具。

4. 不要输出 Cookie、Authorization、Set-Cookie 原文，只说明是否存在。

5. 最终输出：事实、推断、待人工确认问题、不能证明什么。

场景 2：用 regex 工具筛选高价值入口

材料：Proxy History 中已有请求。

工具链：get\_proxy\_http\_history\_regex，筛选登录、上传、导出、管理、回调、token、api 等线索。这里的 regex 是筛选，不是漏洞判断。

输出方式：每个候选入口必须写“为什么值得看”和“还缺什么证据”。比如“路径像导出接口”只能算线索，不能直接写成越权或数据泄露。

人工确认点：regex 命中的请求可能只是静态资源、前端路由或第三方服务，必须回到 request/response 和业务语义核对。

场景 3：用 Organizer 做测试任务板

材料：安全工程师在 Burp Organizer 里维护的请求、备注、状态和 id。

工具链：get\_organizer\_items(count, offset) 和 get\_organizer\_items\_regex(regex, count, offset)。

使用方式：让 Agent 把 Organizer 中的状态拆成“待验证、已复核、误报、待修复、待回归”，再为每个条目补齐证据编号和下一步动作。

人工确认点：Organizer 是协作状态，不是事实本身。Agent 可以整理状态，但不能因为 Organizer 备注里写了“疑似”就把它改写成“确认漏洞”。

五、交给人工验证：让 Agent 创建 Repeater / HTTP2 Repeater 工作台

真正高价值的用法，是让 Agent 把线索交回 Burp 工作台，而不是在聊天窗口里直接给结论。Repeater 标签页是人机协作最自然的边界：Agent 整理材料，人控制请求、观察响应、决定结论。

场景 4：HTTP/1.1 请求进入 Repeater

材料：一条授权范围内、值得人工复核的原始 HTTP/1.1 请求。

工具链：create\_repeater\_tab(tabName, content, targetHostname, targetPort, usesHttps)。

Agent 应该做：用清晰标签页命名，例如“待验证-订单详情-权限边界”；把原始请求放进 Repeater；同时在文本输出里说明为什么需要人工验证。

人工确认点：检查目标、端口、HTTPS、请求头、body、账号上下文和业务影响。Agent 不应该自动扩展到其他用户、其他目标或其他参数。

场景 5：HTTP/2 请求不要塞进 HTTP/1.1 模板

v1.3.0 新增 create\_repeater\_tab\_http2，这点很重要。HTTP/2 有 pseudo headers，例如 :method、:path、:scheme、:authority。源码里的工具说明也强调：HTTP/2 工具不要把 headers 放进 body。

工具链：create\_repeater\_tab\_http2(tabName, pseudoHeaders, headers, requestBody, targetHostname, targetPort, usesHttps)。

正确用法：pseudo headers 单独放，普通 headers 单独放，body 单独放。Agent 输出里要说明字段映射，而不是只说“已创建 Repeater”。

人工确认点：如果 HTTP/2 请求被错误降级或 header/body 混在一起，验证结果可能不可信。现代 Web、API 网关和移动端网关里，这个问题非常常见。

场景 6：当前编辑器内容辅助，而不是替人乱改

工具链：get\_active\_editor\_contents 和 set\_active\_editor\_contents。

适合场景：你在 Burp 的请求编辑器里选中或聚焦某个请求，让 Agent 读取当前内容，帮你解释字段、整理头部、生成注释或把格式修正成更清晰的版本。

边界：set\_active\_editor\_contents 会写当前可编辑区域。它适合格式整理和工作台协作，不适合让 Agent 在你没看见的情况下改请求并发送。

六、受控执行：什么时候才让 Agent 发送请求

send\_http1\_request 和 send\_http2\_request 是真实发请求能力，和读取 history 完全不是一个风险等级。源码里它们会走 HttpRequestSecurity.checkHttpRequestPermission：如果开启请求审批，会弹出目标确认；也可以对 host 或 host:port 做自动批准。

使用模式	是否建议	条件
本地靶场、内部测试环境、明确授权接口	可以谨慎使用	host/port 在授权范围内；请求目的明确；有日志。
生产环境单点复核	谨慎使用	人工确认目标、方法、参数、账号、业务影响。
未知目标批量探测	不建议	不符合授权边界，风险不可控。
让 Agent 自己决定下一批请求	不建议	容易扩大范围、改变业务状态或制造噪声。

send\_http2\_request 还要特别注意字段分层。工具参数中有 pseudoHeaders、headers、requestBody，这不是形式主义，而是避免把 HTTP/2 请求错误地编码成普通文本。

可用提示词：

你只能在我明确批准后调用 send\_http1\_request 或 send\_http2\_request。

每次准备发送前，先输出：

1. 目标 host、port、HTTPS。

2. 请求方法和路径。

3. 是否会改变服务端状态。

4. 为什么需要真实发送，而不是创建 Repeater 交给人工。

没有我回复“批准发送”，不得调用发送工具。

七、复杂场景手册：12 个可落地工作流

下面这部分是本文的重点。它不是攻击步骤，而是公开工具能力下的授权测试工作流：材料是什么、怎么让 Agent 使用 Burp MCP、人工在哪里接管、最后交付什么。

工作流 1：新项目接入后的“只读盘点”

材料：浏览器代理到 Burp 后的正常业务流量。

工具链：get\_proxy\_http\_history -> 去重聚合 -> 输出接口清单。

Agent 任务：按 host、path、method、status、content-type 做聚合；标记登录后接口、文件上传、导出、回调、管理路径、长响应和错误响应。

输出物：接口资产表、待复核入口、排除项、敏感字段摘要。

不能做：不要自动发请求，不要把 Cookie 原文写进报告，不要把“接口看起来敏感”写成“漏洞成立”。

工作流 2：授权范围核对

材料：授权目标清单和 Proxy History。

工具链：get\_proxy\_http\_history\_regex 用 host 或路径筛选。

Agent 任务：把 history 里的 host 与授权清单比对，列出授权内、授权外、无法判断三类。

输出物：范围核对表。授权外请求只用于提醒清理，不进入测试。

工作流 3：登录态与身份边界整理

材料：登录、退出、刷新 token、权限切换相关请求。

工具链：history regex 筛选 login、logout、token、session、auth 等关键词，再人工复核。

Agent 任务：整理身份链路：哪里发放会话，哪里刷新，哪里返回权限信息，哪些请求带认证头。

输出物：身份链路图和待复核问题。不要输出凭据原文。

工作流 4：前后端接口状态机梳理

材料：一段完整业务流程，例如创建订单、提交审批、导出报表、上传附件。

工具链：history 读取 + Organizer 状态整理。

Agent 任务：把请求按时间线还原成状态机：入口、前置条件、状态字段、后续动作、失败响应。

输出物：业务状态机草图、关键请求编号、人工验证清单。

工作流 5：把候选问题送到 Repeater

材料：被标记为“需要复核”的请求。

工具链：create\_repeater\_tab 或 create\_repeater\_tab\_http2。

Agent 任务：创建标签页，命名清楚，附带验证假设和不能证明的内容。

输出物：Repeater 标签页 + 验证说明。真正的修改请求、观察响应、判断影响由人完成。

工作流 6：HTTP/2 网关与移动端 API 复核

材料：HTTP/2 请求、伪头、普通头和 body。

工具链：create\_repeater\_tab\_http2，必要时才用 send\_http2\_request。

Agent 任务：把 pseudo headers 与普通 headers 分离，避免把 headers 写进 body；说明哪些字段来自原请求。

输出物：HTTP/2 Repeater 标签页、字段映射表和人工复核点。

工作流 7：WebSocket 业务线索整理

材料：WebSocket history。

工具链：get\_proxy\_websocket\_history 或 get\_proxy\_websocket\_history\_regex。

Agent 任务：按连接、方向、时间、消息类型、业务动作整理消息，不自动重放。

输出物：WebSocket 消息时间线、候选状态字段、人工验证点。

工作流 8：Scanner issue 归并和报告草稿

材料：Burp Suite Professional 的 Scanner issues。

工具链：get\_scanner\_issues(count, offset)。

Agent 任务：按资产、风险类型、严重性、置信度、重复路径归并；把每个 issue 拆成事实、证据、影响推断、待复核项和修复建议。

输出物：报告初稿和复核清单。不能做：只凭 Scanner issue 直接写“确认漏洞”，尤其是业务逻辑类问题。

工作流 9：Collaborator OOB 证据闭环

材料：授权测试中需要记录带外交互的场景。

工具链：generate\_collaborator\_payload -> 人工在授权场景中使用 -> get\_collaborator\_interactions(payloadId)。

Agent 任务：记录 payload ID、查询交互、按时间线整理 DNS/HTTP/SMTP 等交互信息。

输出物：OOB 证据链。必须写清“能证明发生过交互”，但不自动夸大成完整影响结论。

工作流 10：Intruder 准备，不是自动攻击

材料：授权测试环境中的参数化请求。

工具链：send\_to\_intruder。

Agent 任务：把请求送到 Intruder，标注候选参数位置和验证目的。

人工确认点：payload 来源、数量、速率、停止条件、账号、环境和业务影响全部由人决定。

输出物：Intruder 标签页和执行前检查单，而不是自动开始攻击。

工作流 11：Burp 配置快照与变更审计

材料：项目配置、用户配置、团队基线。

工具链：output\_project\_options、output\_user\_options；只有审批后才使用 set\_project\_options、set\_user\_options。

Agent 任务：导出配置、过滤凭据、生成 diff 摘要、标出会影响代理/扫描/认证/范围的变更。

输出物：配置快照、差异说明、审批记录、回滚路径。

工作流 12：交付报告前的证据索引

材料：history、Organizer、Repeater 标签、Scanner issues、Collaborator interactions 和人工复核记录。

工具链：只读工具 + Organizer 工具。

Agent 任务：把每个结论绑定到证据编号：请求编号、响应摘要、扫描 issue、OOB interaction、人工复核结论。

输出物：报告证据索引。没有证据编号的结论不能进入最终报告。

八、Prompt 模板：让 Agent 按证据工程输出

Burp MCP 最容易出问题的不是工具本身，而是你给 Agent 的任务太松。不要说“帮我测一下这个站”，应该说清楚允许的工具、禁止的工具、输出格式和人工闸门。

模板 1：只读接口盘点

你现在只能使用 Burp MCP 的只读工具：get\_proxy\_http\_history、get\_proxy\_http\_history\_regex、get\_organizer\_items。

禁止调用 send\http1\_request、send\_http2\_request、send\_to\_intruder、set\\*。

请输出：

1. 接口清单。

2. 授权范围外请求。

3. 候选高价值入口。

4. 每个入口为什么值得人工复核。

5. 不能证明什么。

不要输出 Cookie、Authorization、个人数据原文。

模板 2：创建 Repeater 交接

请从候选请求中选择最需要人工复核的 3 条。

你可以调用 create\_repeater\_tab 或 create\_repeater\_tab\_http2。

每个标签页命名格式：待验证-业务对象-验证假设。

创建后输出：原始证据、验证假设、人工需要观察的响应字段、不能证明什么。

不得调用 send\_http1\_request 或 send\_http2\_request。

模板 3：Scanner issue 归并

只读取 get\_scanner\_issues。

请按资产、漏洞类型、严重性、置信度归并。

对每一类输出：事实、证据、可能影响、误报可能、人工复核步骤、修复建议。

不要把 Scanner 发现直接写成最终确认结论。

模板 4：受控发请求审批

你准备调用发送请求工具前必须先停下来，输出待审批摘要：

目标 host/port/HTTPS、method/path、请求是否可能改变状态、为什么不能只创建 Repeater。

只有我明确回复“批准发送”后，才允许调用 send\_http1\_request 或 send\_http2\_request。

九、排障手册：连不上、工具不可见、审批被拒、结果太长怎么办

问题	可能原因	处理方式
Client 看不到 Burp tools	Burp 没开、扩展没加载、MCP server 未启用、stdio proxy 路径错误。	先在 Burp MCP tab 确认 Enabled，再核对 --sse-url 和 Java 路径。
SSE 连接失败	URL 是否需要 /sse、端口冲突、host 配置不一致。	尝试 http://127.0.0.1:9876 和 /sse 两种客户端口径。
读取 history 被拒	requireDataAccessApproval 开启，用户选择了 Deny。	在 Burp 弹窗里 Allow Once 或按项目决定 Always Allow。
发送请求被拒	目标 host/port 未审批，或不在 auto approve targets。	人工确认目标后 Allow Once、Always Allow Host 或 Always Allow Host:Port。
HTTP/2 请求异常	headers 被塞进 body，pseudo headers 没分离。	使用 create\_repeater\_tab\_http2 / send\_http2\_request 的结构化字段。
配置写入失败	configEditingTooling 默认关闭。	不要直接打开；先导出配置、审 diff，再临时开启。
返回内容被截断	源码对序列化结果有截断保护，长 history 需要分页。	使用 count / offset 分批读取，先聚合摘要。
当前编辑器为空	Burp 焦点不在可编辑 JTextArea 上。	先点击 Repeater 或可编辑请求区域，再调用 editor 工具。

十、团队落地：从个人试用到安全团队规范

团队不要一上来把全部工具交给 Agent。建议分三阶段推进。

阶段	打开的工具	禁止或审批的工具	验收标准
第一阶段：只读辅助	编码、history、Organizer、Scanner issue 读取。	send、Intruder、Collaborator、set options。	能整理清单，不泄露敏感数据，不误写结论。
第二阶段：工作台协作	create Repeater、HTTP/2 Repeater、当前编辑器辅助。	send、Intruder、配置修改仍需审批。	Agent 能把线索交给人工验证。
第三阶段：受控执行	特定测试环境里的 send、Collaborator 查询、配置快照。	生产环境无人值守执行、自动扩大范围。	每次执行都有审批、日志、证据编号和回滚。

落地时还要记录四件事：mcp-server 版本和 JAR digest、Burp 版本、MCP Client 版本、每次测试的授权范围。否则出了问题，很难复盘到底是模型误判、工具误用、配置错误，还是人为越权。

FAQ：读者最容易误解的 14 个问题

Burp MCP 是官方项目吗？

是。本文讨论的是 PortSwigger GitHub 组织下的 PortSwigger/mcp-server 仓库。

它是不是 Burp 桌面版内置功能？

本文不把它写成 Burp Desktop release 的内置新增功能，而是按 PortSwigger/mcp-server 官方仓库和 release 口径写。

它能不能自动完成安全测试？

不应该这样理解。它能调用 Burp 能力，但漏洞判断、授权范围、业务影响、速率控制和修复结论仍然要人负责。

Community 版能不能用？

基础工具可以使用；get\_scanner\_issues、generate\_collaborator\_payload、get\_collaborator\_interactions 按源码逻辑只在 Burp Suite Professional edition 下注册。

为什么读取 history 也要审批？

history 里可能包含 Cookie、Authorization、内部接口、账号信息和个人数据，所以它不是低敏数据。

为什么发请求要单独审批？

发请求会触达真实系统，可能改变状态或产生业务影响；这和读取已有历史不是一个风险等级。

Always Allow Host 和 Always Allow Host:Port 怎么选？

更稳妥的是 host:port。host 级别更宽，适合明确知道该 host 所有相关端口都在授权范围内的情况。

什么时候用 Repeater，什么时候用 send\_http？

默认先用 Repeater。只有在授权环境、目的明确、人工批准后，才让 Agent 直接 send。

HTTP/2 工具为什么要单独用？

HTTP/2 的 pseudo headers 和普通 headers/body 要分层，v1.3.0 专门新增 HTTP/2 Repeater 工具就是为了解决这个使用问题。

WebSocket 能不能让 Agent 自动重放？

本文不建议。更稳妥的做法是先读取和整理 WebSocket history，再由人工决定是否、如何在授权环境中复核。

Collaborator 结果能直接证明漏洞吗？

不能。它能证明出现过某类带外交互，但具体影响、触发链路和业务风险仍要人工复核。

Scanner issue 能不能直接进报告？

不能直接进最终结论。它应该先被归并、去重、复核误报，再绑定证据和修复建议。

配置写入工具应该开吗？

默认不开。需要变更 Burp 配置时，先导出、审 diff、审批，再临时开启写入。

最推荐的第一条实践是什么？

只读整理 Proxy History。它风险低、收益高，最容易让团队看见 MCP 的价值。

专业术语注释

MCP：Model Context Protocol，模型上下文协议，用于让 AI Client 通过统一接口访问工具、资源和上下文。

SSE：Server-Sent Events，一种服务器向客户端持续推送事件的 HTTP 机制。

stdio proxy：通过标准输入输出与 MCP Client 通信，再把请求转发给 Burp SSE MCP server 的代理进程。

Montoya API：Burp Suite 现代扩展 API，Burp MCP 通过它访问 Proxy、Repeater、Intruder、Scanner 等能力。

Repeater：Burp 中用于手动修改并发送单个请求、观察响应的工具。

Intruder：Burp 中用于参数化测试请求位置的工具，必须控制授权范围、速率和业务影响。

Scanner：Burp Suite Professional 的自动化扫描能力。

Collaborator：Burp 用于记录带外交互的服务能力，常用于授权测试中的 OOB 证据闭环。

OOB：Out-of-band，带外交互，指目标系统通过 DNS、HTTP、SMTP 等链路与测试方控制服务发生交互。

Organizer：Burp 中用于整理请求、状态、备注和测试任务的工作区能力。

Credential filtering：凭据过滤，导出配置或上下文时识别并过滤敏感凭据。

Auto approve target：Burp MCP 中用于自动批准特定 host 或 host:port 请求发送的目标名单。

参考资料

PortSwigger/mcp-server GitHub repository
https://github.com/PortSwigger/mcp-server

PortSwigger/mcp-server v1.3.0 release
https://github.com/PortSwigger/mcp-server/releases/tag/v1.3.0

Burp Suite MCP Server Extension README
https://github.com/PortSwigger/mcp-server/blob/main/README.md

PortSwigger MCP Proxy repository
https://github.com/PortSwigger/mcp-proxy

Model Context Protocol security best practices
https://modelcontextprotocol.io/docs/tutorials/security/security\_best\_practices

PortSwigger Burp Repeater documentation
https://portswigger.net/burp/documentation/desktop/tools/repeater

PortSwigger Burp Intruder documentation
https://portswigger.net/burp/documentation/desktop/tools/intruder

PortSwigger Burp Collaborator documentation
https://portswigger.net/burp/documentation/collaborator

---