2026-06-21 05:32:37 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文详细介绍了BurpSuite官方MCP的集成方法与应用场景，强调其核心价值在于可控使用Burp工具而非自动攻击。文章系统阐述了连接配置、权限管理、工具选择策略，并提供了12个可落地工作流，重点指导如何通过只读整理、创建工作台和受控执行三个阶段安全地将AIAgent融入Web安全测试流程。 综合评分： 85 文章分类： WEB安全,安全工具,安全建设,渗透测试,安全运营

cover_image

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 官方 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 协作，不应该随便暴露到不可信网络。

手工配置 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 控制。也就是说，它本身已经把“读数据”和“发请求”拆成了不同的审批面。

图 2：Burp MCP 权限边界

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

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

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

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

图 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 工具。请按授权目标范围整理接口清单：

按 host / method / path / status 聚合。
标记登录、上传、管理、支付、导出、回调、WebSocket 入口。
不要调用 send_http1_request、send_http2_request、send_to_intruder、set_* 工具。
不要输出 Cookie、Authorization、Set-Cookie 原文，只说明是否存在。
最终输出：事实、推断、待人工确认问题、不能证明什么。

场景 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 做自动批准。

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

可用提示词：

你只能在我明确批准后调用 send_http1_request 或 send_http2_request。

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

目标 host、port、HTTPS。
请求方法和路径。
是否会改变服务端状态。
为什么需要真实发送，而不是创建 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_*。

请输出：

接口清单。
授权范围外请求。
候选高价值入口。
每个入口为什么值得人工复核。
不能证明什么。

不要输出 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。

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

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

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

落地时还要记录四件事：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

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全学习之路 lidasimida lidasimida《Burp Suite 官方 MCP：把 AI Agent 接进 Web 安全测试工作台》