随着互联网技术的不断发展，浏览器扩展已成为提升用户浏览体验和生产力的重要工具。特别是在Chrome浏览器生态中，数以万计的扩展工具为用户提供了丰富的功能支持。然而，在享受便利的同时，安全风险也日益凸显。近期，关于Chrome扩展与本地Model Context Protocol（MCP）服务器通信所带来的重大安全漏洞引发了广泛关注。本文将围绕这一话题展开，深入分析Chrome扩展如何通过本地连接访问MCP服务器，进而实现沙箱逃逸，并探讨其潜在的风险与应对策略。 首先，需要对MCP协议有一个基本的理解。
MCP，或称模型上下文协议，是一种设计用来连接AI代理与本地系统工具或资源的开放通信标准。它为AI应用提供了操作系统层面的访问能力，包括访问文件系统、消息平台等关键资源。MCP服务器通常运行在本地机器上，通过两种主要的传输机制实现通信：服务器发送事件（Server-Sent Events，简称SSE）和标准输入输出流（stdio）。SSE通过HTTP协议运行，监听特定端口，待客户端发起连接后即可进行双向通信。stdio则依赖进程的标准输入和输出流发送消息。无论哪种方式，协议本身均未内置身份认证或访问控制，相关权限管理依赖于服务器的开发者自行实现。
但在现实情况中，绝大多数MCP服务器并未配置任何认证措施，直接暴露在本地端口之上。 Chrome浏览器的安全模型设计中，沙箱机制是其防范恶意行为的重要屏障之一。官方限制扩展与操作系统及本地资源的直接交互，确保恶意扩展无法轻易突破浏览器边界，保护用户的数据安全。然而，正是由于MCP服务器开放的特性，恶意或被利用的Chrome扩展能够绕过这一沙箱限制，通过localhost端口直接访问MCP服务。由于没有任何身份认证屏障，扩展可以自由调用MCP服务器暴露的所有功能，包括文件读写、消息交互等敏感操作。 近期某安全团队的监测系统发现了这样一个异常的现象：有一款Chrome扩展在后台频繁向localhost端口发起请求，获取MCP服务器提供的“工具列表”，并尝试执行相关命令。
对实验环境中搭建的文件系统MCP服务器进行测试时，扩展毫无阻碍地与服务器通信，实现对本地文件系统的读写操作。更令人震惊的是，类似的测试还在其他常见的MCP服务器上成功，包括Slack和WhatsApp的本地MCP服务，扩展同样可以获取并调用其暴露的API接口。这类横跨浏览器扩展与本地服务之间的通信直接打破了Chrome的沙箱壁垒，成为一种新型的沙箱逃逸技术。 值得注意的是，Chrome浏览器近年来已经对公共网站访问本地私有网络做出了严格限制。例如，从2023年起，Chrome 117版本开始阻止所有公开非安全上下文发起的本地网络请求，显著减少了网页对用户私有网络探测的风险。这是为了防止恶意脚本通过浏览器将攻击目标定位到本地设备或企业内网。
然而，Chrome扩展的特殊权限使它们成为这一限制的例外，依然可以访问本地主机资源。也就是说，扩展拥有的本地私有网络访问权限无形中打开了后门，尤其是在本地运行着不安全的MCP服务器时，极易被滥用。 MCP生态快速发展，涌现出大量功能强大且多样化的本地服务，用以辅助AI和生产力工具。由于多数MCP服务器缺乏必要的安全措施，任何已安装的Chrome扩展，甚至无需请求额外权限，都可能发动针对本地MCP服务的攻击，对用户设备造成严重威胁。攻击者不再需要复杂的漏洞利用手段，通过简单的请求即可执行文件操作、窃取敏感信息，甚至实现整机控制。对于企事业单位而言，这种新型威胁意味着企业边界的安全被进一步削弱，原本依赖的浏览器沙箱隔离失效，带来了广泛且深刻的安全挑战。
针对这一状况，安全专家建议企业和开发者应采取多方面措施以应对潜在的风险。首先，MCP服务器的开发和部署必须加入强制的身份验证和访问控制策略，避免未经授权的进程接入。其次，用户应增强对Chrome扩展的管理，审慎验证扩展的来源和权限，同时企业应构建扩展安全监测机制，及时发现异常行为。第三，加强本地服务的安全配置，如关闭不必要的端口监听，减少暴露面。最后，行业标准和监管部门应推动MCP协议的安全性改进，推动社区采纳安全最佳实践。 总的来说，本地MCP协议与Chrome扩展的结合打开了一扇用于通信的新通道，但同时也成为安全防护体系的薄弱环节。
Chrome沙箱模式在抵御恶意网页攻击方面依旧有效，但面对本地服务协议的“开放性”，存在被绕过的风险。用户及企业需正视这一漏洞，重构安全策略，不断提升对本地服务与扩展行为的可视化和管控能力。在AI工具快速普及的时代背景下，安全隐患往往隐藏在新技术的便利背后，未雨绸缪成为保护数字资产和个人信息安全的关键。理解并防范Chrome扩展与MCP通信导致的沙箱逃逸，是保障未来数字空间安全不可忽视的重要一环。
