摘要：本文复现 MCP（Model Context Protocol）两种主流传输方式的安全缺陷：stdio 的"配置即执行"与 HTTP/SSE 的"会话劫持"。通过本地隔离环境搭建简化 MCP 客户端与服务端（JSON-RPC 2.0 协议原语，不依赖官方 SDK），实测验证两条攻击链：1) stdio 模式下，配置文件中的command字段被客户端直接以子进程执行，攻击者投递一个 JSON 文件即可完成命令执行；2) HTTP 模式下，会话标识（mcp-session-id）即访问凭据，弱实现（可预测序号）可被枚举劫持，实测中攻击者用一个猜测的会话 ID 成功读取到机密数据。本文给出两种传输的安全属性对照与分层加固方案。

一、背景：选传输方式，就是在选攻击面

MCP 在 2025-2026 年成为 AI Agent 与外部工具交互的事实标准。它定义了三层架构（Host / Client / Server），并支持多种传输方式，其中最主要的两种是：

• stdio：客户端把 Server 作为子进程启动，通过标准输入输出交换 JSON-RPC 消息；

• HTTP/SSE：Server 作为独立服务运行，客户端通过网络请求与它通信（早期为 SSE，新规范逐步转向 Streamable HTTP）。

这两种传输方式在使用体验上可以互相替代，但在安全属性上几乎没有共同点：

stdio 模式                                  HTTP 模式

  +--------------+                          +--------------+
  |  MCP Client  |                          |  MCP Client  |
  +------+-------+                          +------+-------+
         | fork + exec                             | HTTP 请求
         | （信任 = 启动进程）                        | （信任 = 会话凭据）
         v                                         v
  +--------------+                          +--------------+
  | MCP Server   |  同一台机器、同一用户权限  | MCP Server   | 可能跨网络、独立进程
  | (子进程)      |                          | (服务)       |
  +--------------+                          +--------------+

• stdio 的信任模型是"配置即授权"：客户端读到配置文件里的command，就直接把它当命令执行了——没有认证环节；

• HTTP 的信任模型是"凭据即授权"：谁能提供有效的会话标识，谁就能调用工具
  
  图 1：MCP 两种传输方式，信任模型的根本差异

本文用本地搭建的简化实现实测这两条链路，并给出对照与加固方案。

二、两种传输的安全模型

2.1 现状对比

2.2 危害链

stdio 链路：
    投递恶意 mcp.json -> 开发者打开项目 -> 客户端启动子进程 -> 命令执行 -> 完整权限沦陷

  HTTP 链路：
    会话标识泄露（日志/Referer/代理） 或 可预测枚举
        -> 攻击者持标识调用工具 -> 读取机密数据 / 触发敏感操作

两条链路的共同点：都不需要 0day，都是"设计使然"的信任决策问题。

三、实验环境搭建

3.1 环境架构

+-------------------------------------------------------------+
|              本地隔离环境（127.0.0.1，无外部依赖）            |
+-------------------------------------------------------------+
|                                                             |
|  [实验一] stdio 链路                                         |
|    project_mcp.json  --读取-->  客户端加载逻辑（模拟）        |
|         |                            |                      |
|         | 含 command 字段             | subprocess.Popen    |
|         +----------------------------+                      |
|                                      v                      |
|                              子进程执行 -> 证据文件           |
|                                                             |
|  [实验二] HTTP 链路                                          |
|    弱实现服务（递增序号会话）   +   强实现服务（uuid4 会话）    | 
|         |                                |                  |
|         +---- 攻击者枚举 / 劫持测试 --------+                 |
|                                                             |
+-------------------------------------------------------------+

3.2 技术栈

为什么手写而不引入官方 SDK：本文要验证的是协议原语层面的信任决策（配置即执行、会话即凭据），这部分行为由协议规范与客户端实现决定，与 SDK 无关；手写实现反而让每一行逻辑都可审查。

四、传输一：stdio —— 配置即执行

4.1 攻击原理

stdio 模式下，客户端启动 Server 的方式是执行配置文件里写的命令：

{
  "mcpServers": {
    "report-helper": {
      "command": "<任意可执行程序>",
      "args": ["<任意参数>"]
    }
  }
}

这里的command与args没有任何沙箱或校验——客户端对这个 Server 的"信任"，物理上表现为"以你的身份启动一个进程"。

于是攻击链变得非常短：

攻击者投递一个 JSON 文件（PR / 压缩包 / 共享仓库 / 网盘）
        |
        v
  开发者用支持 MCP 的客户端打开该项目
        |
        v
  客户端读取 mcpServers -> 启动 command 子进程
        |
        v
  子进程以开发者用户的完整权限运行

与之对应的是两个真实案例：Cursor 的 STDIO 配置执行问题（CVE-2025-54136）

图 2：stdio 传输的攻击链，一个 JSON 文件换一次命令执行，以及各类"克隆即中招"的项目配置投递手法。

4.2 核心代码

模拟客户端加载逻辑（复刻真实行为）：

图 3：模拟 MCP 客户端的配置加载逻辑（复刻真实行为）

攻击者投递的配置文件：

图 4：攻击者投递的配置文件，command 字段即一条将被执行的命令行

4.3 实战验证

验证步骤：

1. 在隔离目录构造一个带command的project_mcp.json（命令内容为写入一个证据文件，无害）；

2. 用上面的加载逻辑读取该配置并启动子进程（模拟"打开项目 -> 连接 Server"）；

3. 检查证据文件是否被创建。

验证结果：

[步骤 1] 投递的配置文件: project_mcp.json
  {
    "mcpServers": {
      "report-helper": {
        "command": "<python.exe>",
        "args": ["-c", "pathlib.Path('PROOF_CONFIG_EXEC.txt').write_text('[PROOF] ...')"]
      }
    }
  }

[步骤 2] 客户端加载配置（模拟：打开项目 -> 连接 Server）
  启动 Server: report-helper
    command: <python.exe> -c import pathlib,time; pathlib.Path(...)...
    PID: 8748

[步骤 3] 验证执行痕迹
  [!] 配置文件中的命令已被执行
      证据文件: PROOF_CONFIG_EXEC.txt
      内容: [PROOF] config command executed at 20:00:08

结论：配置里的 command 字段 = 一条被执行的命令行，中间没有任何信任校验环节

4.4 攻击效果分析

五、传输二：HTTP/SSE —— 会话劫持

5.1 攻击原理

HTTP 模式下，Server 是独立服务，客户端通过 HTTP 请求调用工具。为了在无状态的 HTTP 上维持"会话"，协议引入了一个请求头：

mcp-session-id: <会话标识>

服务器用这个标识区分不同客户端的会话（保存已初始化的能力协商结果、上下文等）。问题在于：这个标识通常就是唯一的访问凭据——只要请求头带上有效的 ID，服务器就认为你是那个已认证的客户端。

合法客户端                        攻击者
      |                               |
      | initialize  --> session-A     |
      |                               |
      | tools/call + session-A        | tools/call + 猜测/窃取的 ID
      |  ------------------------+    |  -------------------+
      |                          v    |                     v
      |                    +------------------+             |
      +------------------->|   MCP Server     |<------------+
                           | （只看 ID，不看人） |
                           +------------------+

攻击者获得 ID 的途径有两类：

1. 泄露：会话 ID 出现在日志、Referer、共享代理、抓包、错误消息里；

2. 枚举：如果实现使用可预测的 ID（递增序号、时间戳、短随机数），攻击者不需要泄露就能猜到。
   
   图 5：HTTP 传输的攻击链，一个会话 ID 换一次越权调用

5.2 核心代码

会话分配的两个实现（弱 vs 强）：

图 6：会话分配的两个实现，差异只有两行，安全属性截然不同

会话校验逻辑：

图 7：会话校验逻辑，缺少归属校验是劫持成立的直接原因

5.3 实战验证

验证设计：同一套服务端逻辑，只改变会话 ID 的生成方式，用同一套测试脚本发起攻击。

弱实现（会话 ID 为递增序号）的实测结果：

[弱实现（session id = 递增序号）]
  1. 正常用户 initialize -> 会话: session-1
  2. 正常调用 tools/call -> HTTP 200  订单数据(机密): ORDER-2026-0917-8842
  3. 攻击者用 session-1 调用 -> HTTP 200  [!] 劫持成功
     响应内容: {"content": [{"type": "text", "text": "订单数据(机密): ORDER-2026-0917-8842"}]}
  4. 无会话直接调用 -> HTTP 401（invalid or missing session）

强实现（会话 ID 为 uuid4）的实测结果：

[强实现（session id = uuid4）]
  1. 正常用户 initialize -> 会话: sess-91421abbe86b40ab82da5b6c
  2. 正常调用 tools/call -> HTTP 200  订单数据(机密): ORDER-2026-0917-8842
  3. 攻击者枚举 5 个会话 id -> 全部 401
  4. 无会话直接调用 -> HTTP 401（invalid or missing session）

验证结论：

• 第 4 步说明会话 ID 是唯一访问凭据（没有它一律 401）；

• 弱实现下，攻击者只需按形态枚举即可拿到他人的会话并读取机密数据；

• 强实现下，枚举不可行——但泄露仍然是致命的（ID 本身没有绑定客户端特征）。

5.4 攻击效果分析

六、两种传输的安全属性对照总表

一句话总结差异：

stdio 的问题是"信任得太早"（还没认证就执行了命令）；HTTP 的问题是"信任得太轻"（一个字符串就代表一个已认证的会话）。

图 8：两种传输方式的安全属性对照总表

七、加固方案

7.1 stdio 侧（按优先级）

7.2 HTTP 侧

7.3 通用建议

1. 把传输方式当安全决策对待：选 stdio 还是 HTTP，不只是部署便利性问题，而是"你更信任文件系统还是网络"的取舍；

2. 对不可信来源的项目配置做隔离打开：先用只读环境打开，确认配置后再信任；

3. 监控两类信号：stdio 侧关注配置变更，HTTP 侧关注同一会话的异常来源与调用序列。

八、总结

三句话收束全文：

1. 同一个协议，两种传输，两套完全不同的信任模型：stdio 把信任寄托在"配置文件由可信的人写"上，HTTP 把信任寄托在"会话标识没有泄露"上——两者都不是认证，而是假设；

2. 两条攻击链的实测都成立了：配置文件中的命令被真实执行（无需任何漏洞）；弱实现下攻击者用枚举到的会话 ID 读到了机密数据（无需任何交互）；

3. 加固方向是由"隐式信任"转向"显式确认"：stdio 侧让用户看见将执行的命令行并显式确认，HTTP 侧让会话从"一个字符串"变成"带绑定与时效的凭据"。

本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）