MCP 服务器处理身份验证的三种方式（以及为何被动扫描会遗漏其中一种）
Source: Dev.to
问题
在扫描了525台MCP服务器后，我发现它们聚集成三种不同的身份验证架构。了解服务器使用的层级需要不同的测试方法——而大多数现有扫描器只能检测Tier 3。
Tier 1 – 真正开放 (179 台服务器， 34%)
- MCP 连接完全开放。
任何人都可以初始化、列出工具并调用它们。任何层面都不需要凭证。
示例
| Server | Tools (count) | Notable tools |
|---|---|---|
sendit.infiniteappsai.com | 131 | publish_content, delete_post, get_analytics |
fflpdljiuruqdnewvwkk.supabase.co/functions/v1/mcp | 29 | create_wallet, swap, withdraw_wallet |
mcp.forex-gpt.ai | 45 | trade_market_order, save_oanda_credentials |
mcp.deepwiki.com | – | Documentation server, intentionally public |
检测 – tools/call 在没有凭证的情况下成功。
风险范围 – 范围广泛。有些 Tier 1 服务器是有意开放的（公共文档、只读 API）。其他则暴露金融操作或写入权限——这才是真正的攻击面。
Source: …
Tier 2 – API‑层认证 (38 台服务器， 7%)
-
MCP 传输是开放的。
您可以在不提供任何凭证的情况下连接、初始化并枚举所有工具。工具的模式（名称、描述、参数）完全可见。 -
但 当您实际调用工具时，服务器会返回 401。
认证发生在底层 API 层，而不是 MCP 协议层。MCP 服务器本质上是私有 API 的公共外壳。
示例
| 服务器 | 工具（数量） | 备注工具 |
|---|---|---|
mcp.cashfree.com | 26 | create-order、standard-transfer-v2、authorize |
mcp.airtable.com | 8 | CRUD 工具 |
bigquery.googleapis.com | – | Google 的 MCP 服务器 – 工具可枚举，调用需 OAuth |
mcp.render.com | – | 云基础设施工具，操作需 Render API 令牌 |
mcp.po6.com | – | 邮件工具（list_mailboxes、get_email） |
检测方式 – initialize 和 tools/list 能成功，但 tools/call 返回 401 或其他认证错误。
为何重要 – 仅检查 tools/list 的被动扫描器会把所有 38 台 Tier 2 服务器归类为“无认证”——产生误报。它们并不易受攻击；模式曝光是有意为之（与浏览公共 API 文档的情况相同）。如果不进行主动测试，您根本无法发现这一点。
Tier 3 – MCP‑层 认证 (306 台服务器，58%)
- 在 MCP 协议层面需要进行身份验证 — 可以在
initialize期间或通过传输头部完成。
未提供有效凭证时，工具列表不可枚举。
示例
Stripe、PayPal、Notion、GitHub Copilot、Salesforce、Figma、Box、Monday.com、HubSpot。
检测 – initialize 失败或返回 401/403，或 tools/list 在没有凭证的情况下返回空或错误。
这些服务器在任何 MCP 交互之前都会实现 OAuth 2.1 或 API‑key 验证。这是 MCP 规范推荐的安全姿态。
为什么大多数扫描器会错过 Tier 2
大多数 MCP 安全扫描器——包括我之前的版本——将服务器分为两类：
- “需要认证”
- “无需认证”
它们仅检查 tools/list 是否在没有凭证的情况下返回工具。此方法 完全错过 Tier 2。
- 这 38 台 Tier 2 服务器在被动扫描中看起来与 Tier 1 完全相同——两者都在未认证的情况下返回工具。
- 差异仅在尝试 调用 工具时出现。
对安全评估的影响
| Tier | 表面暴露 | 执行能力 |
|---|---|---|
| 1（真正开放） | 完整——工具既可以枚举 又 可以执行 | 真实攻击面 |
| 2（API 层认证） | 工具模式暴露（信息泄露） | 操作受保护 |
| 3（MCP 层认证） | 未提供凭证时无表面暴露 | 无攻击面 |
Real‑World Example: Cashfree Payments
- 扫描
mcp.cashfree.com后 未检测到 MCP‑layer 认证，并发现 26 个公开工具（例如create-order、standard-transfer-v2）。 - 在提交安全披露后，我尝试调用这些工具。每一次调用都返回：
{
"message": "authentication Failed",
"code": "request_failed",
"type": "authentication_error"
}- 我向 Cashfree 发送了更正说明：这属于 有意的设计，不是漏洞。
这说明了 主动验证 的重要性。被动枚举只能得到表面信息；主动测试才能判断这些表面是否真的可被访问。
更新的数据集（版本 2026‑02）
- 标记为
has_auth: False的服务器已通过 活跃（空）tools/call请求 验证。 - Tier 2 服务器现在单独分类为
auth_type: api_layer。
修正后的细分
| 层级 | 服务器 | 总比例 | 描述 |
|---|---|---|---|
| 1（真正无认证） | 179 | 34 % | 工具可在无需凭证的情况下调用 |
| 2（API‑层认证） | 38 | 7 % | 仅可枚举工具 |
| 3（MCP‑层认证） | 306 | 58 % | 枚举工具需要认证 |
总计“无 MCP‑层认证”：217 台服务器（41 %）——但其中只有 179 台真正可以在无需凭证的情况下利用。此差异对风险量化至关重要。
为什么这对 AI 代理更重要
人类攻击者在测试 Cashfree 的 MCP 时会在工具调用返回 401 后停止。而如果给 AI 代理下达以下指令：
“探索可用的支付工具并了解 API 表面”
它将会：
- 连接到 MCP 端点。
- 列举所有 26 种工具及其完整描述和参数。
- 试图理解并可能执行这些工具。
- 遭遇 401 – 但工具描述已经在代理的上下文中。
在 Tier 2 中暴露的工具模式是一种 针对 AI 代理的信息泄露风险：工具描述充当语义指令。代理读取到 standard-transfer-v2: “在 Cashfree Payments 发起金额转账” 后，就知道在收到金融目标时尝试进行资金转账——即使实际执行会失败。
这并不是 Cashfree 的漏洞，而是 设计权衡（公开 API 发现 vs. 凭证门控执行），只是在不同的风险情境下产生不同的影响。
要点
- 仅被动扫描不足——它无法区分 Tier 1 与 Tier 2。
- 需要主动测试（例如，一个空的
tools/call） 来正确分类服务器并避免误报。 - 理解层级有助于您 优先处理修复 并 量化真实攻击面，尤其当 AI 代理是威胁模型的一部分时。
考虑“客户端”是自主 AI 代理时的注意事项
MCP 服务器运营者的实际要点：即使你的操作在 API 层面上通过身份验证，也要考虑公开工具模式是否是合适的权衡。你不仅仅是向开发者展示 API 文档——你实际上在向 AI 系统提供可执行指令。
当前扫描统计
- 525 台服务器已扫描，截至 2026 年 2 月。
资源
联系
如果您有任何问题或需要帮助，请联系：