ChatGPT沙箱被攻破：一条复杂攻击链如何窃取账户数据

当“沙箱”不再安全：Parameter Labs 发现的 ChatGPT 账户接管漏洞

沙箱（sandbox）一直是浏览器安全模型中最关键的防线之一。当 ChatGPT 开始支持在对话中渲染交互式 HTML 应用时，OpenAI 把这些内容放进了一个受限的 iframe，期望不可信代码无法触及用户数据和平台 API。但 Parameter Labs 的研究表明，这条防线曾经存在缺口——而且缺口并非来自某个显而易见的设计失误，而是一连串看似无害的组件叠加。

据 Parameter Labs 披露的分析，他们找到了一条相当复杂的攻击链，最终后果是：攻击者可以构造一个 ChatGPT 分享链接，任何已登录用户点开后，私人数据就可能被窃取，或者以该用户身份执行操作。OpenAI 修复了漏洞并支付了 5,000 美元漏洞赏金。

攻击链拆解：四个环节的连锁反应

第一个环节：MathLive 虚拟键盘的 postMessage 入口

OpenAI 在图形支持中使用了 MathLive 这个 JavaScript 数学输入库。MathLive 自带一个虚拟键盘组件，而这个键盘可以被父页面通过 postMessage() 触发——消息来源可以是沙箱内的 iframe。

问题在于，接收消息的代码使用了 innerHTML 来渲染内容。这意味着任何能发送消息的代码都可以向父页面注入自定义 HTML。更关键的是，当时没有机制阻止其他沙箱 iframe（包括 HTML 预览 iframe）调用这个方法。一个本意是提供数学公式输入便利的组件，意外变成了跨信任边界的数据入口。

postMessage 与跨源通信

postMessage() 是 HTML5 引入的跨文档通信 API，允许不同源的窗口（包括 iframe 与父页面）之间安全地传递消息。它的设计初衷是打破同源策略的严格隔离，让嵌入的第三方内容能与宿主页面协作。但它的安全性完全依赖于接收方对消息来源（event.origin）和消息内容的校验。如果接收方不检查来源，任何能向该窗口发送消息的上下文——包括恶意 iframe——都可以触发其消息处理逻辑。MathLive 虚拟键盘的问题正在于此：它暴露了 postMessage 接口，但未限制调用者身份，导致沙箱内的不可信代码也能驱动父页面中的组件。

第二个环节：innerHTML 绕过沙箱限制

innerHTML 本身不会直接执行 <script> 标签，这是它常被误认为“相对安全”的原因。但攻击者不需要直接执行脚本——他们可以注入一个不带 sandbox 属性的新 iframe。这个新 iframe 不再受原有沙箱约束，相当于在受限环境里打开了一扇没有锁的侧门。

这一步是整个攻击链的转折点：从“只能注入静态 HTML”升级为“可以控制一个不受限的浏览上下文”。

iframe sandbox 属性

sandbox 是 iframe 的一个 HTML 属性，用于对嵌入内容施加一系列限制，例如禁止执行脚本、禁止提交表单、禁止访问父页面 DOM 等。当 iframe 带有 sandbox 属性时，浏览器会将其视为一个不透明源（opaque origin），并默认禁用多项能力；只有通过显式的 allow-* 令牌才能恢复特定权限。ChatGPT 的 HTML 预览正是依赖这一机制隔离不可信代码。然而，如果攻击者能通过 innerHTML 注入一个新的 iframe 且不添加 sandbox 属性，这个新 iframe 就完全不受原沙箱约束，等同于在受限环境中创建了一个拥有完整浏览器权限的子上下文，从而实现了沙箱逃逸。

第三个环节：CSP 与 YouTube oEmbed 的意外组合

OpenAI 的内容安全策略（CSP）阻止了内联脚本，只允许从少数几个域名加载脚本。这本是一层很强的防护。但允许列表里包含 YouTube——而 YouTube 的 oEmbed 端点可以被用来反射 JavaScript，并让它在页面上下文中执行。

换句话说，CSP 的严格程度被一个合法的第三方服务绕过了。这不是 CSP 配置错误，而是允许列表机制在面对可反射内容的第三方端点时固有的脆弱性。

CSP 与 JSONP/oEmbed 反射

内容安全策略（CSP）通过 script-src 等指令限制页面可以加载和执行脚本的来源，是防御 XSS 的核心机制之一。但 CSP 的允许列表只校验脚本的来源域名，不校验脚本的内容。如果允许列表中的某个域名提供了反射用户输入的端点（如 YouTube oEmbed 接口可根据参数返回包含用户可控内容的 JSON/JSONP 响应），攻击者就能构造一个指向该端点的 URL，让浏览器从“可信”域名加载一段实际由攻击者控制的 JavaScript。这种手法常被称为 JSONP 劫持或反射型脚本注入。它揭示了一个根本矛盾：允许列表的信任粒度是域名，而可反射端点的信任粒度必须细到具体路径和参数。

第四个环节：数据窃取与账户接管

一旦攻击者在 ChatGPT 页面上获得 JavaScript 执行权限，后续操作就变得直接：调用 API 获取用户私人数据，再通过图片引用把数据外传。最终产物是一个看似正常的 ChatGPT 分享 URL，但访问者会在不知情的情况下触发整条攻击链。

为什么 5,000 美元赏金引发了争议

Parameter Labs 的披露中，作者直言 5,000 美元的漏洞赏金对于这个严重程度的漏洞“有点便宜”。这个评价值得认真对待。

从攻击复杂度看，这条链涉及四个独立环节的串联，发现和利用都需要对浏览器安全模型、CSP 机制和第三方服务行为有深入理解。从影响面看，漏洞影响的是 ChatGPT 的分享功能——一个设计上就是为了让链接被广泛传播的功能。任何已登录用户点击恶意分享链接都可能中招，无需额外交互。

赏金金额本身是一个信号。它既反映平台对漏洞严重性的内部评级，也会影响安全研究者的披露意愿。对于涉及账户接管和数据外泄的漏洞，5,000 美元在业界大型平台的赏金体系中确实偏低。

对 AI 产品沙箱设计的启示

这起事件的价值不止于一个已修复的漏洞。它揭示了 AI 产品在集成富交互能力时面临的结构性风险。

第三方库是信任边界的一部分

MathLive 的虚拟键盘本身没有漏洞——它的 postMessage 接口是正常设计。问题在于，当这个库被嵌入一个需要严格隔离的环境时，它的消息接收逻辑就成了攻击面。AI 产品大量依赖第三方 UI 组件，每一个组件都可能引入新的跨上下文通信通道，而每一条通道都需要被纳入威胁模型。

允许列表不等于安全

CSP 允许列表是一种常见的简化策略：只要脚本来自可信域名就放行。但 YouTube oEmbed 的例子说明，可信域名上的某些端点可以成为反射内容的载体。安全设计需要考虑的不只是“谁提供脚本”，还有“这个域名上的哪些端点可以被操纵”。

沙箱嵌套需要防逃逸设计

innerHTML 注入新 iframe 之所以危险，是因为新 iframe 不受原沙箱约束。任何允许不可信内容创建浏览上下文的机制，都必须确保新上下文继承同等或更严格的限制。这在单层沙箱假设下容易被忽略。

沙箱逃逸的通用模式

沙箱逃逸通常不依赖单一漏洞，而是利用“能力提升”的链条：从一个受限上下文出发，通过某个合法接口获得创建新上下文的能力，再让新上下文继承更少的限制。常见的逃逸路径包括：通过 innerHTML 或 document.write 注入不带 sandbox 的 iframe；利用 window.open 打开新窗口（新窗口默认不受原沙箱约束）；通过 postMessage 触发宿主页面中权限更高的组件。防御此类逃逸的核心原则是“限制的单调性”：任何由不可信内容创建的新浏览上下文，其权限必须不高于创建者。实现上需要对注入点进行白名单过滤、对 window.open 和 iframe 创建进行拦截，并在宿主页面处理跨上下文消息时严格校验来源。

结语

Parameter Labs 的发现是一次典型的链式漏洞利用：没有单点失误，但四个环节串联后形成了完整的账户接管路径。OpenAI 的修复和赏金支付说明漏洞已被处理，但攻击链中暴露的设计模式——第三方组件的跨上下文通信、允许列表的可反射端点、沙箱嵌套的逃逸风险——对所有在对话界面中集成富交互内容的 AI 产品都具有参考价值。

沙箱的安全性不取决于它有多严格，而取决于它与其他组件的交互方式是否被完整地建模和测试。