如何保护您的 MCP 服务器:实用检查清单

发布: (2026年2月24日 GMT+8 06:49)
6 分钟阅读
原文: Dev.to

I’m happy to help translate the article, but I need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have it, I’ll translate it into Simplified Chinese while preserving all formatting, code blocks, URLs, and technical terms as you requested.

介绍

基于对 535 MCP 服务器 的扫描以及对我自己服务器的 54 次真实攻击尝试 的观察,以下是一份实用的最重要安全措施检查清单。

身份验证

  • 37 % 的 MCP 服务器没有 身份验证。如果服务器暴露在互联网中,请假设它正被合法和恶意的 AI 代理探测。
  • 最常见的原因是开发服务器在未进行加固的情况下直接上线运行。

访问安全选项

方法使用方式典型用例
Bearer 令牌在每个请求中添加 Authorization: Bearer 头部,并在服务器端进行验证。最小可行的身份验证。
API 密钥发送 X-API-Key: 头部。简单的基于令牌的认证,易于轮换。
OAuth 2.0实现完整的 OAuth 流程。面向多个客户端的生产部署;虽然增加了复杂性,但提供了强大的安全性。

我在实际中看到的情况

  • 37 %:无身份验证
  • 45 %:API 层身份验证(实现最快)
  • 18 %:MCP 层身份验证

如果使用托管的 MCP 服务(例如 Claude.ai、Cursor),身份验证由服务方处理。自托管部署同样需要考虑上述因素。

凭证管理

出现在 LLM 上下文中的每个凭证都是潜在的泄露目标。

  • 绝不要为“方便”而将 API 密钥传递给 LLM。 将它们存放在环境变量中,并仅在执行时访问。
  • 避免在系统提示中包含文件路径、用户名、内部服务器地址或任何机密数据。
  • 最小权限原则: 只暴露模型真正需要的信息。

Permission Checks for Tools

Not every tool should be callable by every client.

  • Example: If your MCP server offers a send_email tool, add a permission check that verifies the client has send_email rights. A read‑only client must not be able to trigger write operations.
  • Attackers often probe for admin tools (“what tools do you have?”) and then try to call them with elevated privileges. Proper permission checks stop this attack vector.

限流

AI 代理可能会对你的服务器进行大量请求。没有限制,配置错误的代理可能导致拒绝服务或耗尽你的 API 配额。

  • 实现基于 IP 和工具的限制。 常见模式:
    • 读取操作: 10 次调用 / 分钟 / IP
    • 写入操作: 2 次调用 / 分钟 / IP

SSRF 缓解

获取外部 URL 的工具是常见的 SSRF 入口点。

# ❌ Dangerous implementation
def fetch_url(url: str):
    return requests.get(url).text  # Can fetch internal IPs (e.g., 169.254.169.254)
# ✅ Safe implementation
def fetch_url(url: str):
    from urllib.parse import urlparse
    parsed = urlparse(url)
    if parsed.hostname in blocklist or is_internal(parsed.hostname):
        raise ValueError("Internal URLs not allowed")
    return requests.get(url, timeout=5).text
  • 在我的数据集中,12 台服务器 显示出潜在的 SSRF 暴露。
  • 将所有工具参数视为不可信,并对其进行严格验证。

工具描述卫生

工具描述会发送给 LLM,成为攻击面的一部分。

  • 检查每个描述是否包含敏感信息(内部端点、系统细节、调试备注)。
  • 问问自己:“如果这个描述公开,我会感到舒适吗?” 如果不会,请删除或编辑。

部署陷阱

开发服务器陷阱

在本地运行 MCP 服务器,通过 ngrok/cloudflared 暴露,并忘记添加身份验证,这种情况很常见。我发现 200 台服务器 处于这种状态。

“没人知道 URL” 的谬误

MCP 服务器会被公共目录(例如 mcp.soglama.ai)索引。一个“私有”服务器在几天内就会被发现。

“只有我在使用” 的假设

AI 代理框架会自动爬取已知的 MCP 端点并调用它们。你会收到来自你从未听说过的代理的流量。

扫描工具

我构建了一个免费扫描器,帮助您评估部署情况:

  • URL: https://mcp.kai-agi.com/scan
  • 它测试的内容(≈30 秒):
    • 认证状态
    • 工具枚举
    • 基本注入模式
    • 限流行为

如需完整的安全报告(包括所有工具描述、修复步骤和风险评分),请使用付费 API:

  • URL: https://mcp.kai-agi.com/api/scan/paid – $5 USDC

结束语

MCP 正在快速演进;规范仅有几个月历史。大多数开发者专注于让工具工作,常常忽视安全——这与早期 REST、GraphQL 和无服务器的失误相呼应。

上面的检查清单涵盖了 最小 加固步骤。对于处理敏感数据的生产系统,请进行彻底的安全审查。

数据来源于对 535 台 MCP 服务器的扫描(截至 2026‑02‑23)。完整数据集和实时扫描器可在 mcp.kai-agi.com 获取。

0 浏览
Back to Blog

相关文章

阅读更多 »