Hacker News 中文摘要

RSS订阅

MCP安全漏洞与攻击向量 -- MCP Security Vulnerabilities and Attack Vectors

原文链接 | HN讨论 | 2025-07-20 05:47:21

文章摘要

文章探讨了Model Context Protocol（MCP）的安全漏洞和攻击向量。MCP旨在标准化AI模型与外部工具的通信，但其设计缺乏足够的安全考虑。MCP服务器通过自然语言描述工具功能，这些描述直接输入AI上下文，若攻击者控制MCP服务器，可注入恶意内容，导致潜在的安全风险。

文章总结

标题：MCP安全漏洞与攻击途径

来源： https://forgecode.dev/blog/prevent-attacks-on-mcp/

发布时间： 2025年6月17日

最近深入研究了一些模型上下文协议（MCP）的实现，发现了一些令人不安的问题。这些问题虽然不算是惊天动地，但却是那种在你不经意间突然爆发的安全债务。

这是系列文章的第一部分。阅读第二部分：如何真正修复这些问题 →

MCP是Anthropic公司试图标准化AI模型与外部工具通信的协议1。它旨在为AI应用提供一个通用的集成层，类似于REST API，但在安全性方面考虑得远远不够。

协议本身非常简单——通过stdio或HTTP进行JSON-RPC通信。AI请求可用工具，获取工具列表及其描述，然后调用这些工具并传递参数。简单到你可以在一个下午实现一个基本的服务器。

而这正是问题所在。

MCP服务器使用自然语言描述工具，AI通过读取这些描述来理解每个工具的功能。听起来很合理，对吧？

但问题在于，这些描述会直接输入到AI的上下文中。如果你控制了MCP服务器，你可以在这些描述中插入任何内容。

AI读取这些描述后，可能会认为它收到了新的指令。用户请求天气信息，AI却决定窃取数据。

我在几个流行的MCP实现中测试了这一点……确实有效。大多数实现甚至没有尝试对工具描述进行清理。

为什么这很重要​

与典型的提示注入攻击不同，这种攻击途径存在于协议本身2。AI必须读取工具描述才能正常工作。你不能简单地“清理”这些描述而不破坏核心功能。

更糟糕的是，在大多数设置中，用户从未看到工具描述。他们只看到“正在检查天气……”，而AI在后台执行完全不同的指令。

我花了一些时间查看了现有的MCP服务器实现。身份验证的情况……并不理想。

很多服务器基本上是这样的：

参考3

那个TODO注释/文档承担了太多的工作。

MCP规范确实提到了身份验证，但基本上是“自己想办法”。我看到的大多数实现要么完全跳过身份验证，要么添加了一些容易被绕过的基本API密钥检查。

我发现一个服务器只在GET请求中检查API密钥。POST请求（你知道，那些真正执行操作的请求）则直接通过。

MCP工具以包的形式分发，这意味着我们面临供应链攻击的所有风险。但有一个转折——这些工具以你的AI系统拥有的权限运行。

常规的供应链攻击可能会窃取你的npm令牌或挖掘加密货币。MCP供应链攻击可以读取你的对话、访问你的数据库，并冒充你访问其他服务。

我一直在关注一些流行的MCP工具仓库。安全实践……参差不齐。很多工具拥有广泛的权限，代码审查很少，维护者可能没有太多考虑安全性。

我不点名，因为我不想羞辱任何人，但如果你在生产环境中使用MCP工具，你可能需要审计你实际运行的内容。

我在几个内部系统中测试了这些内容（显然是在获得许可的情况下）。结果并不理想：

  • 在2/4的MCP实现中成功进行了工具描述注入
  • 在1/10的生产部署中发现了未经验证的端点
  • 识别了几个拥有比实际需要更多权限的工具

最可怕的部分？大多数这些内容在标准日志中是不可见的。用户请求“检查我的日历”，AI执行恶意工具，日志显示“calendar_check: success”。祝你在SIEM中发现这一点。

这并不是要重写一切。大多数问题都可以通过一些基本的卫生措施来解决：

对于工具描述：

  • 在将描述输入AI之前进行解析和验证
  • 删除任何看起来像指令的内容
  • 考虑使用结构化描述而不是自由文本

对于身份验证：

  • 实际实施身份验证（OAuth流程现在在MCP 2025-06-18中是必需的）
  • 使用最新的MCP规范中指定的OAuth资源服务器模式
  • 实施资源指示器（RFC 8707）以防止令牌盗窃
  • 在每个请求上验证令牌

对于供应链：

  • 固定工具版本
  • 在部署前审查代码
  • 以最小权限运行工具

这些都不是火箭科学。只是没有人愿意做的无聊的安全工作。

MCP的采用正在迅速增加。我看到它被部署在金融服务、医疗保健、客户支持系统中。这些地方一旦发生安全事件，后果将非常严重。

干净利落地修复这些问题的窗口正在关闭。一旦你有成千上万的MCP服务器在生产环境中运行，协调安全更新将变得非常困难。

最好趁生态系统还小的时候修复这些问题。

注：

最新的MCP规范（2025年6月18日发布）解决了一些安全问题：

  • OAuth资源服务器分类现在是必需的
  • 必须实施资源指示器（RFC 8707）以防止恶意令牌访问
  • 新的安全最佳实践文档
  • 移除了JSON-RPC批处理（减少了攻击面）

然而，上述核心漏洞（工具描述注入、供应链风险）在协议本身中仍未得到解决。

第二部分将涵盖具体的缓解策略以及我一直在构建的一些工具，以使这些内容更容易保护。没有什么突破性的东西，只是真正有效的实用工具。

如果你正在构建MCP工具或发现了其他安全问题，请告诉我。这个生态系统仍然足够小，我们可以在问题变成灾难之前真正修复它们。

1. Anthropic. "Model Context Protocol Specification." GitHub Repository. https://github.com/modelcontextprotocol/specification↩

2. OWASP. "Prompt Injection." OWASP Top 10 for Large Language Model Applications, 2023. https://owasp.org/www-project-top-10-for-large-language-model-applications/↩

3. Google Cloud Platform. "Cloud Run MCP Implementation." GitHub Repository. https://github.com/GoogleCloudPlatform/cloud-run-mcp/commit/a49ce276eaa148c8031e912c79bbb60116e8273e↩

继续阅读：第二部分 - 如何真正修复这些问题 →

评论总结

  1. MCP的安全性

    • 正面观点：MCP在安全性方面表现突出。
      • "Truly, S in MCP stands for Security!"（“确实，MCP中的S代表安全！”）
    • 负面观点：MCP在安全实践上仍有不足，尤其是在认证和密码管理方面。
      • "We have not learned anything from the hundreds of open MongoDB databases without passwords floating around the internet waiting to be breached."（“我们从未从数百个无密码的MongoDB数据库中吸取教训。”）
      • "We now have the same with MCP servers in the AI era as documented in [0]."（“在AI时代，MCP服务器也面临同样的问题，如[0]所记录。”）

  2. MCP的采用与规范

    • 正面观点：MCP的采用速度正在加快。
      • "MCP adoption is picking up fast."（“MCP的采用速度正在加快。”）
    • 负面观点：尽管新规范涵盖了认证，但MCP尚未完全适应。
      • "MCP new spec has to an extent covered auth. But the MCPs are yet to adopt to that."（“MCP的新规范在一定程度上涵盖了认证，但MCP尚未完全适应。”）

  3. 独立监控的必要性

    • 建议MCP需要一个独立的监控程序来确保其安全性。
      • "MCP clearly needs an independent monitoring program to safeguard it. Let's call it Tron."（“MCP显然需要一个独立的监控程序来保护它，我们称之为Tron。”）

  4. 关于帖子操纵的指控

    • 有评论认为该帖子存在投票操纵行为，建议禁止相关域名。
      • "This post is an obvious victim of upvote manipulation. HN should ban the forgecode domain if it's going to abuse submissions like this."（“这篇帖子显然是投票操纵的受害者。如果forgecode域名继续滥用提交，HN应该禁止它。”）

  5. 重复的根源问题

    • 评论指出问题的根源与过去类似，建议参考相关分析。
      • "Same root causes again - check out https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/"（“同样的根源问题再次出现——请查看https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/”）