奇安信攻防社区-MCP安全协议：从攻击手法到最佳实践，全景解析

MCP安全协议：从攻击手法到最佳实践，全景解析

在大模型和智能应用快速发展的今天，Model Context Protocol（MCP）逐渐成为连接模型与外部服务的重要标准。它让开发者可以更方便地调用第三方 API，为模型提供更多上下文能力。但与此同时，安...

在大模型和智能应用快速发展的今天，Model Context Protocol（MCP）逐渐成为连接模型与外部服务的重要标准。它让开发者可以更方便地调用第三方 API，为模型提供更多上下文能力。但与此同时，**安全问题也随之而来**。

如果说 OAuth 2.0 曾经是互联网授权的“护城河”，那么 MCP 的兴起意味着我们需要重新思考：**如何在模型调用的上下文中，避免被攻击者钻空子？**

今天我们就来拆解 **MCP 实现中的三大安全风险**：

1. **混淆副手问题（Confused Deputy）**
2. **Token Passthrough（令牌透传）**
3. **会话劫持（Session Hijacking）**

并逐一解析它们的攻击流程、危害，以及官方推荐的防御措施。

- - - - - -

混淆副手问题：当代理成了“帮凶”
----------------

在分布式系统和授权协议中，有一个经典陷阱：**Confused Deputy Problem（混淆副手问题）**。直白点说，就是一个“好心办坏事”的代理，被攻击者利用，成了帮凶。

### 背景

MCP 代理服务器的常见角色是：

- **MCP Proxy Server**：连接 MCP 客户端与第三方 API；
- **第三方授权服务器**：负责保护 API 的授权；
- **第三方 API**：提供具体功能，依赖授权服务器签发的令牌访问。

通常情况下，MCP 代理会用一个 **固定的 Client ID（Static Client ID）** 去对接第三方授权服务。这样做简化了架构，但也埋下了隐患。

### 架构和攻击流程

#### 正常的OAuth代理使用（保留用户同意）

![](https://files.mdnice.com/user/70591/4da21751-1939-4bf7-8c4d-53074648570e.png)

#### 恶意的 OAuth 代理使用（跳过用户同意）

![](https://files.mdnice.com/user/70591/7f9d0072-f8ee-4127-930a-3b9260e98e83.png)

### 攻击流程

正常情况下，用户会通过代理去访问 API，授权服务器会弹出 consent 界面，让用户确认授权。

但如果攻击者掌握了技巧，就可能这样操作：

1. 用户正常完成过一次授权，此时浏览器里已经存有 consent 的 Cookie。
2. 攻击者构造一个恶意请求，伪造 redirect\_uri，骗用户点开链接。
3. 浏览器携带 Cookie 发给授权服务器。因为已有记录，授权服务器会跳过 consent 界面。
4. 授权码被下发到攻击者指定的恶意地址。
5. 攻击者用这个授权码换取 token，从而冒充用户访问 API。

换句话说，**代理因为使用静态 Client ID，帮攻击者绕过了用户确认环节**。

### 缓解措施

- **MUST**：每个动态注册的客户端，都要单独获得用户的同意。
- 即使第三方授权服务不支持动态注册，MCP Proxy 也必须额外补齐 consent 流程。
- - \*

Token Passthrough：危险的“令牌透传”
---------------------------

很多开发者可能会觉得，既然 MCP 客户端已经拿到了 Token，直接转发给下游 API 就好了。**但这恰恰是一种反模式。**

### 风险分析

所谓 “Token Passthrough”，指 MCP 服务器不验证令牌的合法性（是否颁发给自己），直接将客户端提供的令牌转发给下游服务。这样做会带来以下问题：

- **绕过安全控制**：下游 API 的限流、身份校验等机制失效。
- **审计难度大**：MCP 服务器无法区分不同客户端，日志中身份混乱。
- **信任边界被打破**：下游服务误以为所有请求都来自代理，实际却可能是攻击者伪造的。
- **未来兼容性风险**：一旦系统需要引入更严格的安全控制，透传模式将成为巨大负担。

### 缓解措施

- **禁止透传**。MCP 服务器 **必须拒绝** 一切不是专门颁发给它的令牌。
- 所有令牌的 **audience（受众字段）** 必须检查，确保只服务于 MCP 自身。
- - \*

会话劫持：ID一旦泄露，权限瞬间丢失
------------------

另一大风险是 **Session Hijacking（会话劫持）**。简单来说，就是攻击者窃取或猜到某个用户的 Session ID，继而冒充该用户执行操作。

### 攻击方式

MCP 场景下，常见的会话攻击有两类：

#### （1）Prompt Injection 劫持

![](https://files.mdnice.com/user/70591/866b7ba3-2c30-4c96-bbd6-25284172a510.png)

- 客户端连到 Server A，拿到一个 Session ID。
- 攻击者窃取这个 ID，然后在 Server B 发起恶意请求。
- 由于多服务器共享队列，恶意请求被当成正常事件投递。
- 最终客户端收到伪造响应，可能被诱导执行危险操作。

#### （2）Impersonation（身份冒充）

![](https://files.mdnice.com/user/70591/c5cc3c8b-5c99-4739-9ca2-d1f5746ad258.png)

- 用户登录 MCP 服务器，生成持久会话。
- 攻击者拿到这个 Session ID。
- 服务器不再进行二次验证，直接认为攻击者就是合法用户。
- 整个系统的访问权限就此沦陷。

### 缓解措施

要避免会话劫持，MCP 官方提出了一套明确的防护实践：

1. **会话不可作为认证手段**：所有请求都要进行严格授权验证。
2. **Session ID 必须安全生成**：使用安全随机数（如 UUID），避免可预测序列。
3. **会话绑定用户信息**：不仅存储 session\_id，还要加上 user\_id，例如 `<user_id>:<session_id>`。
4. **Session 定期轮换/过期**：减少长期泄露带来的风险。
5. **额外唯一标识**：在必要时结合设备指纹、IP 校验，增加攻击门槛。

- - - - - -

为什么这些风险值得重视？
------------

MCP 的目标是把模型变成更“有上下文”的工具，但一旦代理、令牌或会话被滥用，攻击者可能获得：

- **持久访问第三方 API 的能力**（无需用户同意）；
- **越权操作**（绕过权限和审计机制）；
- **数据泄露通道**（利用透传或代理盗取信息）。

更可怕的是，这些攻击往往隐藏在正常调用流中，不易被发现。

- - - - - -

最佳实践总结
------

从今天的分析可以看到，MCP 安全的关键不在于“防护一切”，而在于：

- **明确信任边界**：代理不是透明管道，而是需要强验证的安全边界。
- **最小化信任假设**：任何静态 ID、透传令牌、持久会话都可能成为突破口。
- **内置安全机制**：日志审计、随机 Session ID、用户 consent 全都要到位。

一句话总结： **把 MCP 当作独立安全主体来设计，而不是 OAuth 的简单中转。**

无论你是开发者，还是安全审计人员，都需要牢记：

- 代理要谨慎，避免被“混淆”；
- 令牌要严格，绝不能透传；
- 会话要随机，绝不能依赖。
- - \*

发表于 2025-10-11 09:57:18
阅读 ( 1855 )
分类：AI 人工智能

MCP安全协议：从攻击手法到最佳实践，全景解析

0 条评论