相信我，我是本地的：Chrome Extensions、MCP 与沙箱逃逸

Trust Me, I'm Local: Chrome Extensions, MCP, and the Sandbox Escape

Source | HN Comments

文章指出，Chrome extension 可通过本地运行的 Model Context Protocol (MCP) 服务器进行通信，从而绕过 Chrome 的沙箱机制。这导致了严重的安全风险，因为 extension 可以未经授权地访问文件系统、Slack、WhatsApp 等服务，甚至完全控制机器。文章通过实验证明了这一漏洞，强调了任何 Chrome extension 都能利用此问题。作者建议重新评估本地 MCP 的安全性，并强调了管理 MCP 使用、强制访问策略和监控 extension 行为的重要性，以防止潜在的破坏性攻击。

ExtensionTotal

通过快速检测恶意、有风险、易受攻击或不合规的第三方扩展程序和软件包，简化企业供应链安全。

相信我，我是本地的：Chrome Extensions、MCP 与沙箱逃逸

Yuval Ronen

让我们来谈谈 MCP。你可能听说过它们，也可能读过与它们相关的安全风险。当然，它们听起来令人担忧，但当你把它们放到真实的场景中，它们可能会变得比你想象的更可怕。

就在上周，我们的系统标记了一个可疑的 Chrome extension。它向 localhost 上的一个端口发送消息——乍一看没什么奇怪的，但当我们深入挖掘时，我们发现这个 extension 与本地机器上运行的 MCP 服务器通信。

Chrome extension 可以与 MCP 通信这一事实是一个严重的风险。其后果是巨大的。像 Chrome 的沙箱模型这样的常用安全措施根本不堪一击。

你正在看到的是对文件系统未经身份验证的访问，在某些情况下，甚至是完全控制机器。这不是一个小问题；这是一个巨大的、颠覆性的漏洞。

更糟糕的是：任何 Chrome extension 都可以利用这一点。不需要任何特殊权限。如果主机上运行着一个易受攻击的 MCP 服务器，那就完了。我们已经发现了与文件系统访问、Slack、WhatsApp 等服务相关的易受攻击的 MCP 服务器。这不再只是一个理论上的风险，而是真实的，其影响可能是毁灭性的。

因此，如果你正在本地运行 MCP，现在是时候认真重新评估你的安全性了。当我们发现这一点时，我们感到震惊，现在是时候让其他人也注意到这一点了，以免为时过晚。

所以，系好安全带，准备好了，让我们一起深入了解一下。

一个可疑的 localhost 连接

在监控浏览器 extension 活动时，我们的检测引擎标记了一个 Chrome extension，它向 localhost 发出网络请求。虽然该 extension 本身没有显示出恶意行为的迹象，但目标地址引起了我们的注意。它正在与一个本地服务通信，该服务实现了 Model Context Protocol (MCP) ——一种用于将 AI 代理与端点上的系统工具和资源连接的协议。

来自 Chrome Extension 的 localhost MCP 连接

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

MCP：默认开放

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

Server-Sent Events (SSE) ——使 MCP 服务器能够通过 HTTP POST 请求进行通信。
Standard Input/Output (stdio) ——使 MCP 服务器能够通过进程的标准输入和输出流进行通信。

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

重要的是要注意，传输层本身不实现或要求任何身份验证机制。是否实施访问控制取决于 MCP 服务器的开发人员，但实际上，目前几乎所有 MCP 服务器默认情况下都不强制执行身份验证。

对于本地使用，依赖于 Server-Sent Events (SSE) 的 MCP 服务器通常绑定到 localhost 上的一个端口，使其可以从运行在同一机器上的进程（如 MCP 客户端）访问。

沙箱，遇到大锤

现在我们了解了基于本地 SSE 的 MCP 服务器是如何运行的，以及它通常可以被运行在同一机器上的进程访问，我们可以重新审视这个问题：Chrome extension 也可以访问它吗？

通信流程相当简单：

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

客户端-服务器通信示意图

首先，我们从 mcp.so 设置一个基于本地 SSE 的 MCP 服务器，特别选择了一个文件系统变体，它允许 AI 客户端与本地文件系统交互。按照服务器 README 中的设置说明：

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

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

该 Chrome extension 拥有对 MCP 服务器工具的_无限制_访问权限——不需要身份验证——并且正在与文件系统交互，就好像它是服务器公开的核心功能的一部分。这可能造成的影响是巨大的，为恶意利用和完全系统入侵打开了大门。

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

我们还尝试设置了一个 Slack MCP，我们的 Chrome extension 能够访问它并与其公开的功能进行交互：

这个 POC 演示了 Chrome extension 架构中的一个完全的沙箱逃逸。虽然 Chrome 已经加强了对私有网络访问的安全控制，但浏览器 extension 仍然是一个值得注意的例外。

在 2023 年，Google 引入了更严格的措施来防止网站访问用户的私有网络（例如，localhost、192.168.x.x 等）——此举旨在保护内部基础设施免受通过公共网站上运行的恶意脚本进行的探测或攻击。

2023 年 9 月：Chrome 117 推广到稳定版，结束了弃用试验。Chrome 阻止来自公共、非安全环境的所有私有网络请求。

虽然 Chrome extension 的运行能力比普通网页更高，但它们仍然被设计为遵守 Chrome 的沙箱原则——除非明确授予权限，否则它们与操作系统和本地资源保持隔离。

然而，不受限制地访问 localhost 打破了这种隔离屏障，使得与本地机器和更广泛的组织环境之间的意外交互成为可能——尤其是通过像本地 MCP 服务器这样的暴露服务。

控制混乱

自推出以来，MCP 生态系统迅速扩展，数千个服务器提供了各种功能。虽然这带来了强大的新可能性，但也引入了越来越多的安全风险。正如所演示的那样，一个简单的 Chrome extension，无需任何特殊权限，就可以突破沙箱，连接到本地 MCP 服务器，并代表用户执行特权操作。这有效地打破了浏览器沙箱建立的隔离模型。并且当这些 MCP 服务器在不强制执行身份验证的情况下公开对文件系统、Slack 或 WhatsApp 等工具的访问时，风险会从理论上的担忧飙升到企业范围内的威胁。

对于安全团队来说，这不仅是一个新的向量，而且是一个全新的攻击面，并且是被危险地低估的攻击面。MCP 已经在开发人员环境和生产系统中部署，通常只有最少的监督或访问控制。如果不加以控制，它们会为端点提供一个开放的后门，绕过传统的防御措施。管理 MCP 的使用、强制执行严格的访问策略以及密切监控 extension 的行为必须成为不容妥协的优先事项。