MCP不安全凭据存储漏洞分析
窃取MCP服务器存储的长期凭据
由于许多MCP服务器旨在将LLM连接到第三方API（如知识管理系统或云基础设施服务），它们通常需要凭据来读取或修改数据。为此，MCP在2025年3月的协议修订中集成了OAuth 2.1。如果正确实施，OAuth基于令牌的方法为服务器提供了一种简单安全的方式，以获取范围有限的短期凭据。
然而，并非所有用户希望连接到其LLM的下游服务都支持OAuth，因此许多MCP工具要求用户向服务器提供API密钥。这些长期凭据通常通过以下两种途径之一到达MCP服务器，这两种途径都创造了凭据窃取的向量：
途径1：不安全的配置文件
大多数MCP服务器通过命令行参数或环境变量获取凭据，这些参数通常源自主机AI应用程序管理的配置文件。我们在Google Maps、Postgres和GitLab的官方MCP服务器中观察到了这种模式。
当主机应用程序不安全地存储此配置时，安全风险就会出现。例如，Claude Desktop在用户的主目录中创建一个claude_desktop_config.json文件。在macOS上，我们发现该文件具有全局可读权限：
|
|
此-rw-r--r--权限集允许系统上的任何进程或用户使用标准文件访问操作读取文件内容，包括其中存储的任何明文API密钥。不需要特殊权限。
途径2：通过聊天日志泄露凭据
另一种常见模式涉及用户直接将凭据输入AI聊天界面，依赖模型将它们传递给适当的MCP服务器。Supercorp的Superargs包装器明确为期望在参数或环境变量中配置信息的服务器提供了便利。
这种方法带来了两个不同的风险。首先，正如我们上一篇文章详述的，恶意MCP服务器可以直接从对话历史中窃取凭据。其次，主机AI应用程序本身通常将整个对话历史记录（包括任何嵌入的凭据）记录到本地文件中，用于调试或历史功能。
在我们的测试中，我们发现像Cursor和Windsurf这样的应用程序以全局可读权限存储这些对话日志：
|
|
与配置文件类似，这些权限不安全的日志为本地攻击者或恶意软件提供了另一个易于访问的明文凭据来源。
风险叠加：Figma示例
一些实现同时通过两种途径暴露凭据。社区提供的Figma MCP服务器允许用户通过工具调用设置其API令牌。然而，服务器随后使用Node.js的fs.writeFileSync函数将此凭据保存到用户主目录中的配置文件中。默认情况下，此函数创建具有0666权限（-rw-rw-rw-）的文件，使存储的Figma令牌全局可读，并且根据用户的umask设置，也可能全局可写。
写入配置文件实现了类似于会话固定的攻击，受害者不知不觉地登录到攻击者控制的账户。对于像Figma这样的设计工具，受害者可能会在账户中保存商业秘密或其他私人信息，立即将其披露给攻击者。如果下游服务是银行或加密货币交易所，用户可能被诱骗直接向攻击者的账户存款或转账资产。
更安全凭据处理的步骤
用更好的身份验证方法替换这些易泄露的凭据存储不会一夜之间发生，但多个利益相关者可以帮助推动生态系统向前发展。所有具有面向公众API的Web服务都应添加OAuth支持，包括具有狭窄范围的短期令牌。除了帮助客户端最小化凭据窃取风险外，OAuth还提供了最佳用户体验，因为通过浏览器登录通常比摆弄配置文件简单得多。
即使第三方服务不支持OAuth，MCP服务器开发人员也可以选择更安全的方法在本地存储凭据。现代桌面操作系统具有专门构建的API，用于具有自动加密的凭据存储，例如Windows的凭据管理API和macOS的钥匙串API。这些API远优于使用明文文件存储，即使相关文件仅由其所有者可读。
至于用户，他们能做的最好的事情是仔细审查他们在环境中安装的软件，并仅使用使用OAuth或使用安全操作系统API存储凭据的MCP服务器。或者，仅作为最后的权宜之计，用户可以手动收紧其AI软件留下的任何敏感文件的权限。
当一个技术领域以AI和MCP的方式快速发展时，开发人员很容易专注于快速交付而将安全视为事后考虑。但随着MCP成为越来越强大的AI系统的基础，我们需要扭转这一趋势，从一开始就将安全凭据处理作为首要任务。