近几年，Chrome浏览器及其扩展生态的迅猛发展极大地增强了用户的浏览体验和生产力，但与此同时，安全问题也日益凸显。尤其是涉及本地服务与扩展程序之间通信的部分，更成为网络攻击者关注的焦点。Model Context Protocol，简称MCP，是近年来兴起的一个协议，用于让人工智能代理与本地系统工具和资源进行交互。虽然这带来了诸多便利，但MCP协议的设计缺失了严格的身份认证机制，使得运行在本地的MCP服务器暴露出严重的安全隐患。本文将结合近期发现的真实案例，深入分析Chrome扩展如何利用MCP协议实现对本地系统的越权访问，轻易绕过浏览器的沙箱保护机制，从而造成潜在的完全控制风险。 MCP的基础及运行机制 MCP被设计为一种面向AI代理的开放协议，使得AI代理能够通过标准化接口访问和操作本地资源。
例如，文件系统访问、通信软件接口（如Slack、WhatsApp）以及其他系统工具，都可以通过MCP被统一调用。它支持两种主要的通信实现方式，包括基于HTTP协议的Server-Sent Events(SSE)和基于进程标准输入输出的stdio方式。 在实际部署中，多数MCP服务器倾向使用SSE协议绑定到本地特定端口（如localhost:3001），以便供本机的客户端进程连接。遗憾的是，协议本身和目前市面上大多数实现都是默认不设认证的，这意味着任何能够访问本地回环地址的程序都可能连接到MCP服务器，执行暴露出来的功能。Chrome扩展，即使没有任何特殊权限，也能够发起网络请求，访问localhost的端口。这一设计上的模糊区域，使得扩展通过与MCP服务器通信，绕开Chrome内建的沙箱限制，有机会直接操作文件系统或调用敏感服务。
沙箱机制的破局与潜在影响 Chrome浏览器的沙箱机制旨在限制扩展程序或者网页代码访问本地系统资源，从而保护用户环境不被恶意软件侵害。然而，MCP服务器作为一个外部服务却直接监听本地端口，此时扩展可以合法地向其发送HTTP请求，完成身份验证缺失的交互。通过获取会话ID、工具列表等信息后，恶意扩展可以在用户不知情的情况下操控该本地服务所提供的一切功能。 这种情况实际上是一种“沙箱逃逸”，在网络安全领域里具有极强的破坏力。攻击者利用这个路径能够实现对目标机器的非授权访问，读取敏感文件、植入恶意程序甚至取得系统最高权限。特别是当MCP服务器暴露了诸如文件系统读写、Slack消息管理、WhatsApp交互等接口时，受影响的范围将不仅限于单台设备，而可能波及整个企业网络环境，导致数据泄露和业务中断等连锁反应。
现实中的风险案例及研究发现 安全研究人员最近监控浏览器扩展网络流量时，发现某些扩展向localhost发送数据包，目标正是本地运行的MCP服务。这些扩展并未表现出传统的恶意行为，但一旦结合MCP的无认证机制，它们便具备了访问和控制本地重要资源的潜力。 验证性实验中，研究团队搭建了一个基于mcp.so开源框架的文件系统MCP服务器，并开发了一个模拟Chrome扩展。该扩展能够轻松连接到本地MCP服务器，获取工具列表并执行文件操作，而无需用户授权。甚至将此方法移植到其它类型的MCP服务器中，例如Slack集成，也同样有效。 这一现象凸显了MCP协议设计导致的安全漏洞。
此外，虽然Chrome在2023年加强了对普通网页访问本地网络的限制，禁止不安全的公共网站对localhost端口进行访问，但Chrome扩展却在权限设计上依然允许访问本地私有网络，为恶意扩展提供了可乘之机。 防范措施与未来展望 面对日益扩大的MCP威胁，企业和安全团队必须重新审视本地服务与浏览器扩展之间的边界。第一步是强制MCP服务器实施身份认证和细粒度访问控制，通过密码、令牌或操作系统权限限制访问来源。其次，加强监控与异常检测，及时发现疑似访问行为，尤其是来自未授权扩展的请求。 第三，Chrome和其他浏览器厂商应考虑针对扩展访问本地私网环境制定更加细化的权限管理策略，甚至引入动态审计和弹窗确认，避免默认开放通路。最后，开发者应当提高安全意识，在设计MCP服务器及扩展应用时，遵循最小权限原则，确保不暴露超出业务需求的接口。
综上所述，MCP协议作为连接AI代理与本地资源的重要桥梁，虽然极大推动了技术应用发展，但其默认缺少认证机制的设计缺陷以及Chrome扩展对localhost的访问权限，构成了当前重要而紧迫的安全挑战。只有结合技术防护与策略监管，才能有效遏制因MCP导致的沙箱逃逸风险，保障用户与企业资产安全。未来，随着AI应用的普及，如何平衡便利性与安全性，将成为技术界和安全领域亟待攻克的重要课题。
