MCP特性及攻击面

前言

模型上下文协议 (Model Context Protocol, MCP) 作为一种新兴的开放标准，旨在促进人工智能助手与各类数据系统之间的连接，从而提升人工智能模型的响应质量和相关性. 然而，随着 MCP 的广泛应用，其潜在的安全漏洞和攻击面也日益受到研究人员和安全专家的关注。

本文旨在MCP的基础概念组件，随后分析安全漏洞以及暴漏的攻击面（这一部分大家可以当做checklist来看，篇幅有限，在本文中就不展开了），接着给出我们调研到的一些实例MCP安全漏洞实例，并在最后给出一些从传统安全中吸取的经验教授作为相关的安全建议。由于这个方向比较新，而且可以写的东西太多，难免挂一漏万，还希望各位师傅多多包涵。

模型上下文协议(MCP) 概述

定义

模型上下文协议是一个开放标准，其核心目标是为开发者提供一种构建安全、双向连接的途径，将他们的数据源与人工智能驱动的工具连接起来. 这一协议的出现，旨在解决当前人工智能模型在获取实时、相关数据时面临的挑战。由于信息孤岛和遗留系统的存在，即使是最先进的 AI 模型也常常受限于其与外部数据的隔离. 每当需要接入新的数据源时，开发者往往需要进行定制化的开发，这使得构建真正互联互通的 AI 系统变得难以扩展.

MCP 通过提供一个通用的、开放的标准，将 AI 系统与数据源连接起来，从而取代了过去零散的集成方式. 这种标准化使得 AI 系统能够更简单、更可靠地访问所需的数据，从而产生更优质、更相关的响应. 形象地来说，可以将 MCP 比作 AI 应用的 USB-C 接口，它为各种 AI 模型连接不同的数据源和工具提供了一种标准化的方式.

MCP 的核心原理是实现数据源和 AI 工具之间的安全双向连接. 其基本架构包括两个主要组成部分：MCP 客户端和 MCP 服务器. 开发者可以通过构建 MCP 服务器来暴露他们的数据，而 AI 应用程序则可以作为 MCP 客户端连接到这些服务器，进行数据的读取和写入操作. 这种客户端-服务器架构为在协议层实施安全策略提供了基础。

关键组件

MCP 的生态系统主要包含以下关键组件。

1)MCP 主机 (Host): 这是用户直接与之交互的 AI 应用程序环境，也是 MCP 客户端运行的地方. 常见的 MCP 主机包括 Claude Desktop、Cursor 等集成开发环境 (IDE)，以及各种自定义的 AI 助手. 这些主机能够管理与多个 MCP 服务器的连接，从而扩展 AI 应用的功能.

2)MCP 客户端 (Client): 客户端位于主机应用程序内部，负责管理与特定 MCP 服务器的连接，并处理主机与服务器之间的通信. 一个客户端通常与一个服务器保持一对一的连接.

3)MCP 服务器 (Server): 服务器是独立的程序，它们根据 MCP 规范暴露外部系统的功能和数据. 这些外部系统可以是本地文件、数据库，也可以是远程服务，例如 Salesforce 和 Box 等应用程序的 API. MCP 服务器充当着 MCP 世界与外部系统特定功能之间的桥梁或 API.

4)工具 (Tools): 工具是由 MCP 服务器暴露的功能，AI 模型可以在用户的授权下调用这些功能来执行特定的操作. 例如，一个天气 API 可以作为一个工具，供 AI 模型查询天气信息.

5)资源 (Resources): 资源是由 MCP 服务器提供的数据源，AI 模型可以访问和读取这些数据，将其作为上下文信息的一部分. 资源类似于 REST API 中的 GET 端点，提供数据而不执行重要的计算或产生副作用.

6)提示 (Prompts): 提示是 MCP 服务器预定义的文本模板，旨在帮助 AI 模型以最优的方式使用工具或资源. 用户可以在运行推理之前选择合适的提示，以指导 AI 模型完成特定任务.

7)采样 (Sampling): 采样是一种服务器控制的功能，允许 MCP 服务器主动向 AI 模型请求补全 (completions)，从而实现服务器发起的代理行为和递归的 LLM 交互.

应用

MCP 的标准化特性赋予其在多个领域广泛的应用潜力。

它可以连接客户支持系统，使聊天机器人访问用户票务数据，从而提供更个性化和可靠的服务；在企业 AI 搜索方面，MCP 能够集成企业的文件存储系统，使 AI 助手可以理解员工的问题，并基于文档内容生成答案，甚至提供文档链接；在 AI 驱动的代码助手中，MCP 可以嵌入代码编辑器，帮助 AI 理解编码上下文，生成更准确的代码；在自动化工作流中，MCP 提供结构化的上下文管理机制，支持 LLM 自主推进任务流程；此外，MCP 还致力于构建统一协议，使 AI 应用轻松接入 GitHub、Slack、Google Maps 等多种数据源与工具。

安全漏洞

协议设计缺陷

缺乏强制的身份验证和授权标准:

MCP 规范中，对于远程 HTTP 服务器的身份验证和授权并非强制要求。

这意味着集成提供商可以自行决定如何实现身份验证，导致实现方式不一致，并可能存在安全漏洞，使得远程服务器容易受到未经授权的访问和中间人攻击

URL 中包含会话 ID

MCP 规范要求在 URL 中包含会话标识符 (Session ID). 这种做法违反了安全最佳实践，因为会话 ID 可能会暴露在服务器日志中，攻击者可以利用这些信息进行会话劫持

缺乏默认的加密和完整性控制

MCP 协议本身并没有强制要求对数据传输进行加密或实施消息完整性检查. 这意味着在没有额外安全措施的情况下，客户端和服务器之间的通信可能会被窃听或篡改，从而损害数据的保密性和完整性

数据传输安全风险

数据在传输过程中可能被窃听或篡改

尽管可以使用传输层安全协议 (TLS) 来加密数据传输 ，但如果实现不当或未强制使用，数据仍然可能在传输过程中被恶意方窃听或篡改，尤其是在客户端和服务器通过网络进行通信时.

OAuth 令牌被盗的风险

MCP 使用 OAuth 令牌来保护对 Gmail 或 Google Drive 等服务的凭据访问. 如果攻击者成功拦截或窃取这些令牌，他们可能会设置恶意的 MCP 服务器，从而获得对用户账户的未授权访问，读取用户的机密信息或冒充用户进行通信.

与其他系统交互时的漏洞

MCP 的价值在于其能够与其他各种系统进行集成，然而，这种集成也可能引入新的安全漏洞

与不安全 API 或数据源的集成可能引入新的漏洞

MCP 服务器通常需要与后端的 API 或数据源进行交互. 如果这些后端的 API 或数据源本身存在安全漏洞，或者 MCP 服务器在与其交互时处理不当，那么这些漏洞可能会被引入到 MCP 生态系统中，扩大整体的攻击面.

过度授权的风险

为了提供灵活的功能，MCP 服务器通常会请求过度的权限. 这种过度授权意味着，如果一个 MCP 服务器遭到入侵，攻击者可能会获得超出其正常功能所需的权限，从而能够访问或操作更多的敏感数据和系统资源

提示注入攻击

由于AI 模型依赖自然语言进行交互，提示注入攻击成为 MCP 环境中一个重要的安全威胁。

攻击者可以在看似正常的电子邮件或消息中嵌入恶意指令，当AI 模型处理这些包含恶意指令的输入时，可能会触发未授权的 MCP 操作，例如转发机密文件到外部地址.

工具中毒攻击

工具中毒是MCP 特有的安全风险，攻击者可以利用 MCP 服务器提供的工具列表进行攻击

恶意工具伪装成合法工具

攻击者可以将恶意的 MCP 包发布到开发者平台，伪装成合法的文件管理工具或其他常用工具. 当用户下载并安装这些恶意工具后，它们可以执行未授权的操作，例如安装恶意软件或窃取数据.

工具定义在安装后可能被静默更改 (Rug Pull)

一些 MCP 客户端在安装时会显示工具的描述信息，但不会在工具定义更改后通知用户. 这使得攻击者可以在用户批准安装一个看似安全的工具后，悄悄地更改其定义，使其执行恶意操作，例如将用户的 API 密钥发送给攻击者.

跨服务器工具阴影攻击

在一个 AI 代理连接到多个 MCP 服务器的环境中，一个恶意的服务器可以劫持或覆盖另一个受信任服务器提供的工具. 这意味着恶意服务器可以利用受信任服务器的权限来执行恶意操作，例如访问用户的 Gmail 或数据库，而这些操作可能不会在用户可见的日志中显示.

中间人攻击

当MCP 客户端和服务器之间的通信发生在网络上时，存在遭受中间人攻击的风险。

当客户端和服务器不在同一机器上时，可能发生中间人攻击: 当客户端和服务器使用 HTTP 等网络协议进行通信时，如果通信没有得到适当的保护 (例如，使用 TLS 加密)，攻击者可能会拦截客户端和服务器之间的通信，窃听敏感信息，甚至篡改数据

数据篡改

恶意方可能通过多种方式篡改MCP 环境中的数据。

恶意服务器可能篡改发送给客户端的数据: 一旦攻击者控制了一个 MCP 服务器，他们不仅可以窃取服务器能够访问的数据，还可以篡改服务器发送给客户端的数据，从而影响 AI 模型的决策或用户的判断

攻击面

现在我们从组件角度来总结一下引入MCP后暴露的攻击面

MCP 主机 (Host) 的攻击面

主机本身可能存在的漏洞

运行 MCP 客户端的 AI 应用程序 (即 MCP 主机) 本身可能存在安全漏洞。如果攻击者能够利用这些漏洞入侵主机系统，那么他们就有可能控制 MCP 客户端，从而影响与所有连接的 MCP 服务器的交互.

主机对客户端和服务器的管理不当

MCP 主机负责管理其内部的 MCP 客户端以及它们与外部 MCP 服务器的连接. 如果主机在管理这些连接时不当，例如未能实施适当的访问控制或未能使用安全的传输协议，那么就可能为攻击者创造机会.

MCP 客户端 (Client) 的攻击面

客户端处理恶意服务器响应时的漏洞: MCP 客户端需要能够与各种不同的 MCP 服务器进行通信，并处理服务器返回的响应. 如果客户端在处理来自恶意服务器的响应时存在漏洞，例如未能正确地验证服务器返回的数据或未能安全地处理工具描述信息，那么攻击者就可能利用这些漏洞进行提示注入或其他类型的攻击

MCP 服务器 (Server) 的攻击面

服务器代码中存在的漏洞，如命令注入、路径遍历等

对MCP 服务器进行安全研究发现，许多服务器实现中存在常见的 Web 应用程序漏洞，例如命令注入、路径遍历和服务器端请求伪造 (SSRF) 等. 这些漏洞使得攻击者可以通过构造恶意的请求来执行未授权的命令、访问受限的文件或发起对内部资源的攻击.

服务器对后端数据源的访问控制不当

MCP 服务器充当着 AI 模型与后端数据源之间的中介. 如果服务器对后端数据源的访问控制策略配置不当，例如授予了过多的权限，那么攻击者一旦控制了 MCP 服务器，就可能能够访问或操作超出其权限范围的敏感数据

多服务器环境下的攻击面

在一个MCP 主机连接到多个 MCP 服务器的环境中，一个被攻击者控制的恶意服务器可能会利用其与主机的连接，通过修改工具描述或其他方式，影响 AI 模型与其他服务器的交互. 这种“tool shadow”攻击使得恶意服务器可以间接地利用其他服务器的功能，例如发送电子邮件或访问数据库，而其自身可能并没有直接的权限执行这些操作

漏洞实例

这里我们也总结了一些已经公开的漏洞实例。

工具中毒攻击导致数据泄露

研究人员验证了可以通过在 MCP 工具的描述中嵌入恶意指令，使得 AI 模型在执行看似无害的操作时，秘密地读取用户的敏感文件 (如 SSH 私钥和配置文件) 并将其发送到攻击者控制的服务器

这背后的原理在于AI 模型可以看到完整的工具描述（包括隐藏的指令），而用户通常只能在 UI 中看到简化版本。比如下面的代码，当用户打算使用此工具执行简单的加法操作时，系统会显示一条看似无害的描述。然而，<IMPORTANT> 标签中隐藏的指令可能会导致严重后果。响应此工具，AI 模型将：读取敏感配置文件 (~/.cursor/mcp.json)，访问 SSH 私钥 (~/.ssh/id_rsa)，通过 sidenote 参数以隐藏方式传输这些数据，并用数学解释将其隐藏起来呈现给用户。

恶意 MCP 包执行未授权命令

研究人员发现，攻击者可以创建包含恶意代码的MCP 包，并将其伪装成合法的工具发布到开发者平台.当用户下载并集成这些恶意包后，它们可以在用户的本地系统上执行未授权的命令，例如启动计算器，或者在实际攻击中安装恶意软件或窃取数据

如下图所示，攻击者会创建一个看似合法的恶意MCP 包，并将其发布到开发者平台上。

用户随后会下载该MCP，但却不知道它是恶意的。一位用户以为自己正在使用 MCP 和 Cursor AI 读取文件。然而，FastMCP 模拟了一个恶意 MCP 包，该包意外地触发了计算器的打开。该计算器正在模拟攻击。攻击时截图如下

在实际场景中，攻击者可以下载并运行恶意可执行文件，从而控制网络并在设备上保持持久性，而不仅仅是运行计算器

利用 MCP 服务器进行勒索软件攻击

研究人员也设计了方法，攻击者会制作一个带有恶意提示的文档，诱骗受害者将其上传到安装了MCP 服务器的 Claude 3.7 Sonnet。当文件触发后，攻击者会操纵 MCP 服务器加密受害者的文件。

现在假设用户安装了一个合法的 MCP 服务器，该服务器充当 Claude 和用户文件之间的桥梁。它为 Claude 提供了访问本地文件的权限，从而允许文件读写。

在下图中，攻击者利用恶意提示精心制作一份文档，并诱骗受害者将其上传到安装了 MCP 服务器的 Claude 3.7 Sonnet。

隐藏的提示被触发，操纵受害者设备上的 MCP 服务器并加密其文件。这表明即使是合法的 MCP 安装也可能被利用。

在现实场景中，假设攻击者向财务分析师发送一份伪造的审计文档。假设 MCP 服务器允许访问敏感文件并通过 HTTP 发送数据。分析师将文档上传到 Claude，触发恶意提示，使攻击者能够未经授权访问财务记录，从而导致数据泄露、报告篡改或勒索软件部署。

通过 MCP 窃取 WhatsApp 消息历史

研究人员实现了一种针对whatsapp-mcp 服务器的攻击，该服务器连接用户的 WhatsApp 账户到 MCP 系统. 通过特定手段，攻击者可以重定向发送消息的请求，将用户的 WhatsApp 消息历史记录秘密地发送到攻击者控制的电话号码。

在如下的代码中，实现了一次与sleeper rug pull 相结合的影子攻击，即一个 MCP 服务器，仅在第二次加载时将其工具界面更改为恶意界面。

该服务器首先将其伪装成一个良性的“random fact of the day”实现，然后将该工具更改为恶意实现，操纵同一代理中的 whatsapp-mcp，从而将消息泄露给攻击者的电话号码。

攻击效果如下所示

命令注入漏洞导致远程代码执行

研究人员对一些流行的MCP 服务器实现的安全性分析发现，超过 40% 的实现包含命令注入漏洞.攻击者可以利用这些漏洞，通过在发送给服务器的特定参数中注入恶意代码，从而在服务器上执行任意代码，甚至完全控制服务器

比如下图的代码是一个流行MCP 服务器的实际实现代码

这个代码包含一个典型的命令注入漏洞。攻击者可以在 notification_info 字典中构建一个包含 Shell 元字符的值的 Payload。

这里给出一个简化的漏洞利用示例来说明这种漏洞利用非常的容易

模型上下文协议 (MCP) 的防御与缓解措施

安全设计原则

默认安全 (Secure by Default)

默认安全原则要求系统在初始状态下就应具备最高安全性，而非依赖后期配置。这意味着系统的默认配置必须是安全的，用户需要主动操作才能降低安全级别。

在MCP系统中，所有敏感功能和高风险操作默认应处于禁用状态，系统应默认关闭不必要的服务、端口和功能。默认权限应设置为最低级别，需要时再提升。例如，MCP系统默认应禁用远程管理接口，用户需要通过安全验证流程显式启用；默认情况下，所有数据传输应采用加密方式，用户需要特别授权才能使用非加密传输。

纵深防御 (Defense in Depth)

纵深防御原则强调构建多层次、多维度的安全防护体系，确保即使某一层防护被突破，其他层次仍能提供有效保护。

这要求在MCP系统中实施多层安全机制：在网络层部署防火墙、入侵检测系统和网络隔离；在应用层实施身份验证、授权控制和输入验证；在数据层实施加密、访问控制和完整性校验；在物理层实施设备安全和环境控制；同时建立监控、审计和响应机制，形成动态防御体系。这样，即使某一层被攻破，其他层也能提供保护。

最小权限原则 (Principle of Least Privilege)

最小权限原则要求系统中的每个组件、服务和用户只被授予完成其任务所必需的最小权限集。

在MCP系统中，应精确定义每个角色所需的最小权限集，实施基于角色的访问控制（RBAC），定期审查和调整权限设置，对特权操作实施额外的控制措施，并采用临时提权机制，而非长期授予高权限。例如，MCP服务器进程应以非管理员身份运行，只有在执行特定管理任务时才临时提升权限；开发人员在测试环境中只能访问其负责模块的相关资源，而不是整个系统。

用户同意与控制 (User Consent and Control)

用户同意与控制原则强调尊重用户的数据主权和操作自主权。

对于任何涉及数据访问和操作的行为，MCP系统都必须获得用户的明确同意和理解。系统应提供清晰、易懂的隐私政策和数据使用说明，允许用户查看、修改和删除其个人数据，为用户提供精细的权限控制界面，重要操作需要用户确认，并提供撤销机制。例如，MCP系统在首次使用时应明确告知用户数据收集范围，并获得明确授权；系统应提供直观的控制面板，让用户可以随时查看哪些数据被共享，并能够随时撤销特定权限。

通过严格遵循这些安全设计原则，MCP相关系统可以在保障功能性的同时，最大限度地提高系统安全性，保护用户数据和系统资源不受未授权访问和恶意攻击。

身份验证与授权

强制使用 OAuth 2.1 或更安全的身份验证机制

强制使用OAuth 2.1 或更安全的身份验证机制是保护 MCP 系统安全的基础。对于远程 MCP 服务器，应强制实施 OAuth 2.1 或其他更先进的身份验证协议，确保客户端和服务器之间的身份验证过程安全可靠。这种机制不仅能有效验证通信双方的身份，还能防止中间人攻击和凭证盗用等安全威胁。通过实施严格的身份验证流程，系统可以有效阻止未经授权的访问尝试，保护敏感数据和关键功能不被非法利用。此外，应配合使用 TLS/SSL 加密通信，确保身份验证过程中的数据传输安全，进一步增强整体安全性。

实施基于角色的访问控制 (RBAC)

实施基于角色的访问控制（RBAC）是精细管理 MCP 系统权限的有效方式。通过根据用户的角色和职责分配不同级别的访问权限，系统可以确保用户只能访问其工作所需的特定工具和资源。这种分层的权限管理机制有效限制了潜在安全事件的影响范围，即使某个用户账户被攻破，攻击者也只能获得该角色所对应的有限权限，无法访问整个系统。RBAC 应结合最小权限原则，定期审查和更新角色定义及权限分配，确保权限设置始终与组织结构和业务需求保持一致，同时避免权限蔓延和过度授权问题。

使用短期 OAuth 令牌并管理刷新令牌

使用短期OAuth 令牌并严格管理刷新令牌是减少令牌滥用风险的关键策略。通过缩短访问令牌的有效期（通常限制为几小时或更短），即使令牌被盗，攻击者能利用它的时间窗口也非常有限。同时，对刷新令牌实施严格的管理措施，包括设置合理的过期时间、实施令牌轮换机制、监控异常使用模式，以及在检测到可疑活动时立即撤销令牌。此外，应建立完善的令牌撤销机制，确保在用户权限变更、离职或设备丢失等情况下能够及时撤销相关令牌。通过这些措施的综合应用，可以显著降低令牌被盗后被滥用的风险，提高系统的整体安全性。

数据加密

使用 TLS 加密传输中的数据

使用传输层安全协议(TLS)加密传输中的数据是保护MCP系统通信安全的基础措施。在客户端与服务器之间的所有网络通信中，应始终强制实施TLS加密，确保数据在传输过程中的机密性和完整性。这种加密机制能有效防止数据在网络传输过程中被窃听、篡改或伪造，抵御中间人攻击和数据嗅探等威胁。在实施TLS时，应使用最新的安全版本，禁用已知存在漏洞的旧版本协议和弱加密算法，定期更新证书并验证证书的有效性。此外，应实施证书固定(Certificate Pinning)技术，防止恶意证书替换攻击，并配置适当的密码套件，在保证兼容性的同时优先选择强加密算法，确保通信通道的安全性达到最高标准。

加密存储的敏感数据

加密存储敏感数据是保护MCP系统数据安全的关键环节。对于MCP服务器存储的敏感信息，如OAuth令牌、API密钥、用户凭据和其他机密数据，应使用强加密算法进行加密存储，防止数据泄露事件造成严重后果。在实施数据加密时，应采用业界认可的强加密标准，并结合适当的加密模式确保数据的机密性和完整性。加密密钥的管理同样至关重要，应使用专业的密钥管理系统进行存储和轮换，避免硬编码密钥或使用弱密钥。此外，应实施数据分类策略，根据数据敏感度采用不同级别的加密保护，并建立完善的访问控制机制，确保只有授权用户和进程能够访问解密后的敏感数据。通过这些综合措施，即使在数据库或存储系统被入侵的情况下，攻击者也无法获取有价值的明文信息，从而有效降低数据泄露的风险和影响。

输入验证与过滤

验证所有输入参数是否符合预定义的模式

验证所有输入参数是否符合预定义的模式是防止恶意输入攻击的第一道防线。对于MCP服务器接收的所有输入数据，包括资源URI、工具参数、提示参数等，都应该实施严格的验证机制，确保其格式、类型和值范围符合预期。这种验证应基于预先定义的JSON模式或其他结构化验证规则，对输入数据进行全面检查。实施输入验证时，应采用白名单策略，明确定义允许的输入模式和值范围，而非仅排除已知的恶意模式。对于不符合预期模式的输入，系统应立即拒绝处理并记录异常，同时向用户返回适当的错误信息，但不泄露系统内部细节。此外，验证逻辑应在服务器端实施，不应仅依赖客户端验证，因为客户端验证可能被绕过。通过严格的输入验证，可以有效防止格式错误的数据进入系统，降低安全漏洞被利用的风险。

清理和转义用户输入，防止注入攻击

清理和转义用户输入是防止各类注入攻击的关键措施。对于用户提供的所有输入数据，除了进行格式验证外，还应实施全面的清理和转义处理，移除或转义可能被用于执行恶意操作的特殊字符或代码片段。这种处理对于防止命令注入、SQL注入、XSS攻击和提示注入等多种攻击至关重要。在处理用户输入时，应根据数据的使用上下文选择适当的清理和转义策略，例如，用于构建命令行的输入需要特别注意防止命令注入，用于构建数据库查询的输入需要防止SQL注入，而用于构建AI提示的输入则需要防止提示注入攻击。系统应使用成熟的安全库和框架进行输入处理，避免自行实现可能存在缺陷的清理逻辑。此外，应实施输入长度限制，防止缓冲区溢出和拒绝服务攻击。通过综合应用这些清理和转义措施，可以显著降低注入攻击的风险，确保系统安全处理用户输入数据。