文章总结： 本文分析了远程MCP服务器的安全攻击面，探讨了Prompts、Resources和Tools三类服务可能存在的安全漏洞，如命令注入、SSRF和IDOR等，并介绍了MCPInspector和MCPtoHTTPBridge两种测试工具。文章指出虽然MCP为LLM与外部系统集成提供了新接口，但也引入了与传统Web应用类似的安全风险，安全人员需掌握相应的测试方法。 综合评分： 87 文章分类： AI安全,漏洞分析,安全工具,渗透测试

---

AI安全 – 远程 MCP 服务器的攻击面

原创

一个不正经的黑客 一个不正经的黑客

一个不正经的黑客

2026年3月6日 20:19 广东

AI安全 – 远程 MCP 服务器的攻击面

免责声明：

MCP 规范是一项新兴且仍在演进中的标准，未来很可能会发生变化，因此本文中提到的某些内容届时可能不再适用。

作为参考，本文撰写时依据的是该规范的 2025–06–18 版本。

MCP 简介

讨论 MCP 服务器的攻击面之前，我们认为有必要先简要说明一下 MCP 协议是如何工作的。

虽然这段快速说明已经足以帮助你理解本文后续内容，但我们仍强烈建议你阅读完整规范，以便全面了解该协议。

MCP（Model Context Protocol，模型上下文协议）是一种轻量级协议，用于让大语言模型和代理框架以相对安全的方式访问外部数据、工具和资源。

与其把所有内容都塞进单一的模型提示词，或依赖临时拼凑的 API，不如由 MCP 将这一过程规范化：

Host LLM 如何发现远程或本地服务器能够提供哪些能力（prompts、resources、tools）。

该规范定义了 3 个主要参与方：

• • Host：宿主 LLM，例如 Claude Desktop 或 Cursor IDE 中的 LLM。
• • Client：Host 用来与服务器通信的程序。每个服务器始终对应 1 个客户端，并且这些客户端之间应当彼此隔离。
• • Server：MCP 服务器本身，既可以部署在本地，也可以远程托管。

传输层基于 JSON-RPC 2.0：对于本地服务器，通过 STDIN/STDOUT 传输；对于远程服务器，则通过 SSE 或 streamable HTTP 传输。

下图展示了一个示例配置：

在了解完这些基础内容后，我们就可以进一步看看远程 MCP 服务器的具体细节了。

身份验证 / 授权

对于需要授权的远程服务器，MCP 在规范中采用了 OAuth2。

在这种情况下，MCP 服务器扮演的是资源提供方的角色，而由另一个独立服务充当身份提供方。

虽然这不在本文的讨论范围之内，但这也意味着远程 MCP 服务器可能会受到已知 OAuth 漏洞的影响。

在完成 OAuth 握手后，服务器会设置一个认证令牌，后续所有 MCP 请求都会使用该令牌。

值得注意的是，这个令牌不同于用于标识和跟踪某条连接的 Mcp-Session-Id 令牌；后者并不用于身份认证。

有关认证机制的完整说明可在此处查看:

https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization

攻击面

远程 MCP 服务器可以向客户端暴露 3 类基础服务：Tools、Resources 和 Prompts。

Prompts

服务器可以暴露供宿主 LLM 使用的 prompts。

这些 prompts 可以选择性地由用户填入参数，因此某种程度上相当于一个 prompt 模板表；这些参数中也可以包含资源 ID，而这些资源会被一并打包进 prompt 中。

下面是 prompts/list 操作的一个示例：

从安全角度来看，这部分可供攻击的点其实不多。

如果攻击者能够篡改传递给 prompt 调用的参数，理论上就可能实现 prompt injection；

但这通常要求攻击者能够在某个被引用的资源中植入 prompt injection 攻击，或者事先已经攻破 Host LLM / MCP Client，从而直接篡改相关参数。

Resources

Resources 是 MCP 的一项功能，允许服务器暴露可供客户端读取的数据和内容，并将其作为 LLM 交互时的上下文。

下面的请求展示了与 Resources 的交互方式。

首先，客户端会调用 resources/list 操作：

客户端随后就可以通过 URI 调用某个特定资源：

这显然是一个非常明确的 LFI 或 SSRF 漏洞利用向量。

如果服务器没有校验客户端传入的 URI 是否确实属于已列出的资源，那么攻击者就可能诱使服务器泄露内部文件或内部服务。

此外，对于那些会暴露与特定用户绑定资源的已认证 MCP 服务器来说，这也是测试类似 IDOR 漏洞的明确目标。

Tools

Tools 是 MCP 协议最核心的卖点，也是从安全角度看最有意思的部分，因为它们提供了一种让 LLM（或者我们自己）直接与服务器端代码交互的方式。

例如，下面是一个使用 Python 的 FastMCP 库定义的简单工具：

当客户端调用 tools/list 操作时，工具内容将按如下格式返回：

这会向客户端提供该工具期望的输入格式，以及它的功能描述。工具还可以带有可选参数，用于给客户端提供额外上下文，这些内容也会在这里定义。

随后，客户端会按照定义去调用该工具：

从本质上讲，tools 提供了一种直接与服务器端代码交互的简洁方式。

这意味着，对攻击者而言，它们最有可能成为发现漏洞的首要目标。

举例来说，Equixly 的研究发现，在他们测试的服务器中，有 43% 存在命令注入漏洞，以及其他一些安全问题。

值得强调的是，与远程 MCP 服务器交互，在本质上并不同于调用普通的 REST APIs，因此合理预期 MCP 服务器也会受到同类型漏洞的影响。

不过，与 REST APIs 不同，MCP 服务器使用的异步传输机制，使得 Burp Suite 之类的传统安全工具难以直接与其交互。

下面我们将介绍几种可作为替代方案的工具：

MCP Inspector

https://github.com/modelcontextprotocol/inspector

MCP Inspector 是 Anthropic 创建的一款用于测试和调试 MCP Server 的工具。它提供了一个简洁的 Web 用户界面，让我们可以与指定服务器进行交互：

它支持全部 3 种传输方式（STDIO，以及通过 SSE 或 streamableHTTP 的 HTTP），同时也支持 OAuth 授权。

它还提供了功能完整的 CLI 模式，适合用来构建自动化脚本：

这个工具对于初步理解和侦察 MCP 服务器非常有帮助，也适用于执行基础交互操作。

MCP to HTTP Bridge

https://github.com/nccgroup/http-mcp-bridge

正如其名称所示，这个由 NCC 编写的工具，是一个将 MCP SSE 协议桥接到 HTTP/1.1 协议的简单桥接器，旨在配合 Burp Suite 或 Caido 这类 Web 代理使用，本身并不提供花哨的界面或开箱即用的额外功能。

需要注意的是，截至本文写作时，这个工具只支持 SSE 传输，而不支持 streamable HTTP 传输。

SSE 传输已在规范 2025–03–26 版本中被弃用，但目前大多数公开可用的 MCP 服务器似乎仍然支持它。

启动该工具时，需要传入我们希望连接的 MCP 服务器 URL。

之后，它会创建一个监听端口，供我们的代理指向它：

由于这本质上就是一个原始代理，我们需要手动完成 MCP 连接握手，以获取一个有效的 session-id，之后才能与服务器通信。

相关说明可在该工具 GitHub README 页面中找到。完成之后，我们就可以通过构造相应的 JSON 消息与 MCP 服务器交互：

虽然这样做更麻烦一些，但它让我们能够完全控制客户端发送的消息，同时也能利用代理本身提供的自动化能力，例如 Burp Intruder。

thanks:

https://cybersecuritywriteups.com/assessing-the-attack-surface-of-remote-mcp-servers-92d630a0cab0?gi=8754c7b66a36

结论

MCP 规范为将 LLM 与外部系统集成带来了一种新的接口形式，但它也以一种新的表现形式引入了我们早已熟悉的风险。

远程 MCP 服务器呈现出清晰的攻击面，而这一攻击面与传统 Web 应用中常见的漏洞类型高度相似，例如命令注入、SSRF 和 IDOR。

随着 MCP 协议的采用不断增长（MCP Servers 的 GitHub 页面中已列出超过 500 个官方服务器！），作为安全研究人员，我们也将越来越有必要理解这一协议，并熟悉如何对其进行测试。

希望本文已经帮助你对该协议的内部工作机制建立起良好的初步认识，也为你开始开展相关测试提供了一个合适的起点。

文末点评

MCP 在消息层采用 JSON-RPC 2.0，这意味着客户端与服务器之间的交互，本质上是围绕请求、响应和通知这套标准化结构展开的

从发展过程来看，MCP 的传输机制大致经历了三个阶段：

1. stdio

这是最早、也最直接的传输方式，主要面向本地集成场景。

客户端通常将 MCP Server 作为本地子进程启动，再通过标准输入和标准输出交换 JSON-RPC 消息。它的特点是实现简单、依赖较少，适合桌面应用、IDE 插件和本地工具链等使用场景。

2. HTTP + SSE

随着 MCP 开始支持远程服务器， 2024-11-05 规范早期引入了基于 HTTP 与 SSE（Server-Sent Events）的通信方式。

这种方式的重点在于支持远程环境下的异步消息交互，使服务器不仅能够接收客户端请求，也能够以流式形式持续返回数据。相比 stdio，它更适合网络环境，但连接管理和交互流程也相对更复杂。

3. Streamable HTTP

在后续规范演进中， 2025 年 3 月 26 日，早期的 HTTP + SSE 方案被进一步整合为 Streamable HTTP。

这种方式延续了 HTTP 协议的兼容性，同时对流式响应、会话管理以及多连接处理等能力进行了统一，使远程 MCP 的交互模型更加规范，也更适合实际部署和生产环境使用。

整体来看，MCP 传输机制的演进路径比较清晰：

先通过 stdio 解决本地进程通信问题，再通过 HTTP + SSE 支持远程异步交互，最后以 Streamable HTTP 进一步统一远程场景下的传输模型。

站在安全研究的角度来说，这一演进过程也说明，MCP 虽然面向 LLM 生态，但其底层通信模式仍然与传统本地进程交互和 Web 服务接口有较强的连续性。

另外，目前BurpSuite的 MCP 协议支持还在完善中，未来应该会增加支持！

---

免责声明：

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

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

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

本文转载自：一个不正经的黑客 一个不正经的黑客 一个不正经的黑客《AI安全 – 远程 MCP 服务器的攻击面》