MCP安全最佳实践（官方草案）

MCP安全最佳实践^[1]目前处于草案状态，目前只介绍了混淆代理人问题。当一个主体（如程序、进程或用户）被赋予特定权限去执行任务时，由于对权限的误解或滥用，导致其以另一个主体的身份执行了未授权的操作。

1. 引言

1.1 目的与范围

本文档为模型上下文协议 (MCP) 提供安全方面的考量，是对 MCP 授权规范的补充。文档明确了 MCP 实现过程中存在的安全风险、攻击途径以及相应的最佳实践。

本文档主要面向实施 MCP 授权流程的开发人员、MCP 服务器运营人员以及评估基于 MCP 系统的安全专家。阅读本文档时，应结合 MCP 授权规范和 OAuth 2.0 安全最佳实践^[2]。

2. 攻击与防范措施

本节详细介绍了针对 MCP实现的攻击方式以及可能的应对措施。

2.1 混淆代理人问题

攻击者可能会利用代理其他资源服务器的 MCP 服务器，从而制造出"混淆代理人^[3]"漏洞。

MCP 代理服务器 : 一种将 MCP 客户端连接到第三方 API 的 MCP 服务器，在提供 MCP 功能的同时，将操作委托给第三方 API 服务器，并作为单一的 OAuth 客户端与之交互。

第三方授权服务器 : 保护第三方 API 的授权服务器。它可能不支持动态客户端注册，这就要求 MCP 代理在所有请求中使用静态客户端 ID。

第三方 API : 提供实际 API 功能的受保护资源服务器。访问该 API 需要由第三方授权服务器颁发的令牌。

静态客户端 ID : MCP 代理服务器在与第三方授权服务器通信时使用的固定 OAuth 2.0 客户端标识符。此客户端 ID 指的是作为第三方 API 客户端的 MCP 服务器。无论哪个 MCP 客户端发起请求，在所有 MCP 服务器与第三方 API 的交互中，该值都保持不变。

2.1.2.1 正常的 OAuth 代理使用方式 (保留用户同意)

2.1.2.3 恶意的 OAuth 代理使用方式 (跳过用户同意)

当 MCP 代理服务器使用静态客户端 ID 与不支持动态客户端注册的第三方授权服务器进行身份验证时，可能发生以下攻击：

1. 1. 用户通过 MCP 代理服务器正常认证，以访问第三方 API
2. 2. 在此过程中，第三方授权服务器在用户代理上设置一个 cookie，表示对静态客户端 ID 的同意
3. 3. 攻击者随后向用户发送恶意链接，其中包含精心设计的授权请求，包含恶意重定向 URI 以及新动态注册的客户端 ID
4. 4. 当用户点击链接时，浏览器仍保留着之前合法请求的同意 cookie
5. 5. 第三方授权服务器检测到 cookie 后，跳过同意界面
6. 6. MCP 授权码被重定向到攻击者在动态客户端注册期间指定的服务器
7. 7. 攻击者用窃取的授权码换取 MCP 服务器的访问令牌，无需用户明确批准
8. 8. 攻击者现在以受害用户身份获得了对第三方 API 的访问权限

使用静态客户端 ID 的 MCP 代理服务器必须在将请求转发到第三方授权服务器 (可能需要额外同意) 之前，获得每个动态注册客户端的用户同意。

👉 关注「玄月调查小组」，解剖硬核技术！

[1] Security Best Practices: https://modelcontextprotocol.io/specification/draft/basic/security_best_practices[2] Best Current Practice for OAuth 2.0 Security: https://datatracker.ietf.org/doc/html/rfc9700[3] Confused deputy problem: https://en.wikipedia.org/wiki/Confused_deputy_problem