保护您的 MCP 系统:11 种常见风险及防范方法

本指南介绍 MCP 安全,涵盖 MCP 系统面临的 11 种常见风险(从间接提示词注入到本地服务器被入侵),以及有助于防范每种风险的实用措施。

Diagram of how MCP works: the MCP host (the AI app) sends tool requests through an MCP client to an MCP server, which offers its tools and returns results to the host.

MCP 风险大致可分为三类:LLM 操纵、数据与访问安全,以及基础设施漏洞。

由于 MCP 服务器通常可以访问大量内部系统,潜在的安全风险很高。不过,风险发生的可能性在很大程度上取决于配置方式。

个人和企业可以采取许多措施来确保系统受到保护,而且防护措施应始终与所连接的 MCP 服务器可能暴露的功能和数据相称。

什么是 MCP 和 MCP 安全?

模型上下文协议(Model Context Protocol,MCP)是由 Anthropic 创建的一项开放标准,用于将基于 LLM 的应用(或主机)连接到外部系统。

MCP 系统包含三个核心组件:主机、客户端和服务器。主机通常是 AI 助手,它通过客户端连接到外部 MCP 服务器,然后可以发送请求,以运行外部功能(工具)、检索数据(资源),或获取提示词并将其添加到 LLM 的上下文窗口中。

MCP 安全是指保护 MCP 系统中各连接和组件的协议。MCP 面临几项独有的关键挑战,例如 AI 应用通常具备智能体能力,而且恶意指令可能被嵌入消息中。

一些并非 MCP 特有的常见问题,例如提示词注入、身份验证薄弱和不安全的第三方集成,同样会带来隐患。与任何计算机系统一样,MCP 依靠程序性规范(例如只使用可信服务器)和技术控制措施(例如 API 网关)相结合来提供保护。

MCP 威胁有多严重?

MCP 已迅速成为一项热门的 LLM 技术,许多组织和面向消费者的应用都在使用它。由于 MCP 服务器是用代码编写的程序,它们和其他任何应用程序一样存在漏洞。

不过,当组织在受控部署中使用 MCP 时,它通常是安全的。使用可信服务器和经过验证的权限构建系统,与将自主智能体连接到十几个未经审查的服务器,两者之间存在巨大差别。

威胁 #1:间接提示词注入

攻击者可以在 MCP 服务器返回的文档、网页或工具输出中放置针对 LLM 的指令。如果主机将这些内容添加到上下文窗口中,LLM 就有可能将其误认为真实的指令。

更糟糕的是,这些指令表面上可能看起来合情合理。例如,检索到的支持工单可能会要求 LLM 在生成回答之前导出敏感的客户记录。

如何防范间接提示词注入

提示词注入通常应在主机层面处理。外部内容应被标记为不可信,涉及敏感信息的请求应由人工审核环节中的人员在充分知情后批准。进行安全测试,即调用恶意文档或数据来观察主机和 LLM 的反应,也会有所帮助。

威胁 #2:工具投毒与 Rug Pull 攻击

在工具投毒攻击中,恶意代码被添加到 MCP 工具的描述或架构(schema)中。这可能会在发现阶段(即 MCP 首次公开可用工具时)影响 LLM。

Rug Pull 攻击是一种特殊的工具投毒,指已批准的元数据遭到篡改。这种形式的工具投毒可能会改变模型使用可信工具的方式,而不是直接调用恶意工具。

如何防范工具投毒与 Rug Pull 攻击

主机在使用每个工具之前,应检查其完整定义,并与已批准的可信工具列表进行比对,从而发现任何变更。参数检查有助于识别潜在的危险功能并对其进行标记。

威胁 #3:权限过多

用户为 MCP 服务器和(通过主机)连接的 LLM 授予超出任务所需的权限,这种情况很常见。例如,在只读权限就足够时授予写入权限,或授予对内部文件系统(例如 Google Drive)的完全访问权限。

这种大范围的权限蔓延可能会扩大其他漏洞(例如恶意工具调用)的影响范围。在企业中,随着用户在日常使用 AI 工具开展工作的过程中不断授予权限,权限往往会“越积越多”(权限累积)。

如何防范权限过多

防范这一问题最直接的方法是限制权限和 OAuth 范围(读取、写入、完全访问等)。用户批准(尤其是针对敏感操作的批准)是其中的重要一环,但权限也应在系统层面(操作系统、MCP 主机和服务器)加以控制。

威胁 #4:身份验证和授权薄弱

身份验证用于验证连接到 MCP 服务器的用户或应用程序的身份。授权则规定了它们可以访问哪些工具和资源。

配置不当的 MCP 服务器可能会在未正确验证用户身份或未执行访问限制的情况下接受请求或令牌。此外,如果验证机制薄弱,被盗的凭据可能会让不法分子获得访问权限。

如何防范身份验证和授权薄弱

针对远程 MCP 服务器的基于 OAuth 的身份验证、短期令牌以及基于角色的访问控制(RBAS),都是有助于缓解授权薄弱问题的措施。基于角色的访问之所以有用,是因为即使服务器本身拥有访问权限,它也能防止用户访问超出其权限范围的数据和工具。

威胁 #5:凭据泄露和滥用

MCP 服务器通常使用 API 密钥和 OAuth 访问令牌等凭据来连接外部服务。如果这些凭据被泄露或滥用,攻击者就可以访问敏感数据和功能。

令牌透传就是一个例子:MCP 服务器将访问令牌转发给另一个服务,却没有验证该令牌是否确实是发给接收服务的。如果接收服务的保护措施不足,这又可能导致泄露。

如何防范凭据泄露和滥用

使用短期、范围狭窄的令牌并轮换凭据,可以有效限制恶意行为者利用泄露数据的程度。API 密钥和凭据应始终使用密钥管理器安全存储。

威胁 #6:混淆代理攻击

当攻击者诱骗受信任的应用程序利用其权限执行未经合法用户授权的操作时,就会发生混淆代理攻击。在这种情况下,MCP 服务器就是“代理”。

攻击者会利用 MCP 服务器的漏洞(例如 OAuth 验证薄弱)来执行恶意流程,例如工具调用或数据检索。

如何防范混淆代理攻击

授权验证(即验证每次工具调用是否属于特定用户)有助于减少混淆代理攻击。此外,数据导出等敏感操作应要求明确授权。

威胁 #7:恶意服务器和被入侵的依赖项

MCP 服务器可能包含恶意代码(它们本质上是外部程序),或依赖于被入侵的依赖项,例如第三方库。这属于软件供应链问题,而不是 MCP 独有的问题。

一种简单的发生方式是,攻击者分发一个看似合法的集成。一旦完成设置,它就可以窃取并重复使用凭据、访问敏感数据并执行未经授权的操作。

如何防范恶意服务器和被入侵的依赖项

仅从可信且经过审查的来源安装 MCP 服务器。如果可能,请审查其代码,并始终检查所有外部依赖项。确保服务器定期更新并安装补丁。

威胁 #8:服务器端请求伪造(SSRF)

服务器端请求伪造(SSRF)是指攻击者诱骗 MCP 服务器向用户并不打算访问的内部地址发送网络请求。

当 MCP 服务器公开一个从 URL 检索信息的工具时,就可能发生这种情况。如果攻击者能够影响 URL 参数,就可以将其更改为想要的网络地址,例如内部 API 或云服务。这可能导致敏感数据被检索,并可能被他人获取

如何防范服务器端请求伪造(SSRF)

MCP 服务器应始终验证 URL、阻止访问受限的内部网络地址,并防止出站网络访问。重定向也应遵循这一规则。

威胁 #9:会话劫持

会话劫持是指攻击者控制 MCP 客户端与服务器之间的活动连接。

例如,攻击者可能会从安全防护不足的 MCP 应用程序(例如主机或服务器)中窃取会话标识符。如果 MCP 服务器接受该标识符,攻击者就可能利用用户的合法权限调用工具。

如何防范

在 MCP 系统的所有应用程序中实施严格的身份验证,可以降低会话劫持的风险。MCP 客户端与远程服务器之间的加密也至关重要,可防止会话标识符被识别。

威胁 #10:Mix-up 攻击

在 Mix-up 攻击中,攻击者诱骗 MCP 客户端将授权码发送到位于客户端与 MCP 服务器之间的恶意授权服务器。授权服务器是一种应用程序,它在确认所请求的访问已获授权后颁发 OAuth 访问令牌。

如果 MCP 主机连接到多个服务,且每个服务使用不同的授权服务器,攻击者就有可能控制其中一个授权服务器(例如通过注册恶意服务),并使客户端将合法服务器颁发的授权码发送给恶意服务器。这种混淆可能使攻击者冒充已获授权的应用程序,并获得受保护服务的访问权限。

如何防范 Mix-up 攻击

MCP 客户端应在整个 OAuth 流程中验证授权服务器的身份。具体而言,它们应将服务器的颁发者标识符(iss)与预期身份进行比对,并拒绝不匹配的情况。

威胁 #11:本地 MCP 服务器被入侵

许多 MCP 服务器运行在用户的本地计算机上。用户可能从第三方安装服务器,也可能自行构建。如果攻击者能够入侵这台本地 MCP 服务器,就有可能获得对本地系统大部分内容的访问权限。

攻击者获取访问权限的方式多种多样。他们可能会分发伪装成合法集成的恶意服务器,修改 MCP 主机的配置使其发出恶意命令,或者访问运行在安全控制不足环境中的 MCP 服务器,例如通过 DNS 重绑定(一种诱骗浏览器向 localhost 服务发送请求的手段)。

如何防范本地 MCP 服务器被入侵

使用本地 MCP 服务器时,沙盒隔离和严格的同意机制非常重要。MCP 服务器只能从可信的提供方安装,并且应通过操作系统权限限制它们可以访问的目录。

MCP 漏洞往往是旧威胁换了新装

MCP 漏洞通常源于对既有风险和攻击方法的新应用。MCP 通过 LLM、MCP 服务器和外部服务之间的交互,为攻击者利用这些漏洞提供了新途径。

当然,MCP 特有的威胁确实存在。不过值得注意的是,标准安全规范(例如实施严格授权、使用可信提供方以及防范提示词注入)对于保护任何 MCP 实现都大有帮助。