让我们来谈谈 MCP。你可能听说过它们，或许也读过与之相关的安全风险。当然，它们听起来令人担忧，但当你把它们放在现实世界中时，它们很快就会变得比你想象的更加令人担忧。

就在上周，我们的系统标记了一个可疑的 Chrome 扩展程序。它向 localhost 上的一个端口发送了消息——乍一看没什么奇怪的，但随着深入调查，我们发现该扩展程序与本地计算机上运行的 MCP 服务器进行了通信。

Chrome 扩展程序能够与 MCP 通信，这是一个严重的风险，后果极其严重。像 Chrome 沙盒模型这样的常规安全措施，根本无力应对。

您将面临未经身份验证的文件系统访问，在某些情况下，甚至可能完全接管机器。这可不是个小问题， 而是一个巨大的、足以改变游戏规则的漏洞。

关键在于： 任何 Chrome 扩展程序都可以利用这一点，无需任何特殊权限。只要主机上运行着易受攻击的 MCP 服务器，就万事大吉了。我们已经发现一些与文件系统访问、Slack、WhatsApp 等服务相关的易受攻击的 MCP 服务器。这不再只是理论上的风险，而是真实存在的，其影响可能是毁灭性的。

所以，如果你在本地运行 MCP，是时候认真重新评估你的安全性了。当我们发现这个问题时，我们震惊了，现在是时候让其他人也注意到了，以免为时已晚。

所以，系好安全带，准备发车，让我们一起深入探讨这个问题。

可疑的本地主机连接

在监控浏览器扩展程序活动时，我们的检测引擎标记了一个 Chrome 扩展程序，该扩展程序向本地主机发出网络请求。虽然该扩展程序本身没有恶意行为的迹象，但其目标地址引起了我们的注意。它正在与一个实现了模型上下文协议 (MCP) 的本地服务进行通信——该协议用于将 AI 代理与端点上的系统工具和资源进行交互。

来自 Chrome 扩展程序的 localhost MCP 连接

这立即引发了一个担忧：如果浏览器扩展可以与用户机器上运行的 MCP 服务器通信，那么是什么阻止它访问敏感资源或通过 MCP 执行特权操作？

MCP：默认打开

首先，我们来了解一下 MCP 客户端如何与 MCP 服务器通信。目前有两种标准的传输实现方式：

1. 服务器发送事件 (SSE) — 使 MCP 服务器能够通过 HTTP POST 请求进行通信。
2. 标准输入/输出 (stdio) — 使 MCP 服务器能够通过进程的标准输入和输出流进行通信。

在实现 MCP 服务器时，开发人员可以选择 MCP 服务器的通信方式。服务器可以支持两种传输方式。

需要注意的是，传输层本身并不实现，也不需要任何身份验证机制。访问控制由 MCP 服务器开发者实现，但实际上，目前几乎所有 MCP 服务器默认都不强制执行身份验证。

对于本地使用，依赖于服务器发送事件 (SSE) 的 MCP 服务器通常绑定到本地主机上的端口，以便可以从同一台机器上运行的进程（如 MCP 客户端）访问它。

沙盒，遇见大锤

现在我们了解了本地基于 SSE 的 MCP 服务器是如何运行的，并且它通常可供在同一台机器上运行的进程访问，我们可以重新讨论这个问题：Chrome 扩展程序也可以访问它吗？

沟通流程相当简单：

• 客户端向服务器发送 GET 请求以获取会话 ID 和消息端点——无需任何形式的身份验证。
• 初始化后，客户端可以向该消息的端点发出 POST 请求，以检索 MCP 服务器公开的可用工具列表并直接调用它们。

首先，我们从 mcp.so 搭建了一个基于 SSE 的本地 MCP 服务器，具体选择了一种文件系统变体，以便 AI 客户端能够与本地文件系统进行交互。请按照服务器 README 文件中的设置说明进行操作：

node dist/index.js ~/work/mcp/private_directory

接下来，我们构建了一个在后台运行的 Chrome 扩展程序，并尝试连接到 localhost:3001——这是本地基于 SSE 的 MCP 服务器常用的端口。当然，这个端口可能会有所不同，因此实际的扩展程序需要扫描本地端口来定位活动的 MCP 实例。该扩展程序会获取服务器信息，检索工具列表，并尝试调用 MCP 服务器提供的工具：

该 Chrome 扩展程序可以不受限制地访问 MCP 服务器的工具（无需身份验证），并且与文件系统进行交互，就好像它是服务器公开功能的核心部分一样。此举的潜在影响巨大，为恶意利用和彻底的系统入侵打开了大门。

由于该协议的设计目标：提供一个统一的接口来与各种 MCP 服务器进行交互，而不管它们的底层实现如何，因此与不同的 MCP 服务器集成几乎不需要任何努力。

我们还尝试设置 Slack MCP，我们的 Chrome 扩展程序能够访问它并与其公开的功能进行交互：

此 POC 演示了 Chrome 扩展程序架构中的完整沙盒逃逸 。虽然 Chrome 已经加强了对私有网络访问的安全控制，但浏览器扩展程序仍然是一个明显的例外。

2023 年，谷歌出台了更严格的措施，防止网站进入用户的私人网络（例如 localhost、192.168.xx 等）——此举旨在保护内部基础设施免受公共网站上运行的恶意脚本的探测或攻击。

2023 年 9 月：Chrome 117 正式发布稳定版，结束弃用试用期。Chrome 将阻止所有来自公共、非安全环境的私有网络请求。

尽管 Chrome 扩展程序与常规网页相比具有更高的功能，但它们仍然遵循 Chrome 的沙盒原则——除非明确获得许可，否则与操作系统和本地资源保持隔离。

然而，对本地主机的无限制访问打破了隔离屏障，使得与本地机器和更广泛的组织环境发生意外的交互——尤其是通过本地 MCP 服务器等公开的服务。

遏制混乱

自推出以来，MCP 生态系统迅速扩张，拥有数千台服务器，提供各种功能。这在带来强大新机遇的同时，也带来了日益严重的安全风险。正如上文所述，一个简单的 Chrome 扩展程序，无需任何特殊权限，就能突破沙盒，连接到本地 MCP 服务器，并以用户的名义执行特权操作。这实际上破坏了浏览器沙盒所维护的隔离模型。当这些 MCP 服务器在未强制身份验证的情况下暴露对文件系统、Slack 或 WhatsApp 等工具的访问权限时，风险将从理论上的担忧飙升为企业范围内的威胁。

对于安全团队来说，这不仅仅是一个新的攻击向量，更是一个全新的攻击面，而且被严重低估了。MCP 已经部署在开发者环境和生产系统中，通常缺乏监管或访问控制。如果不加以控制，它们会为终端提供一个开放的后门，绕过传统的防御措施。管理 MCP 的使用、执行严格的访问策略以及密切监控扩展程序的行为必须成为不可或缺的优先事项。