XSS 亮点：挖掘 ChatGPT 中的漏洞

ChatGPT 在企业和个人用户中广泛使用，是寻求访问敏感信息的攻击者的主要目标。在这篇博文中，我将向您介绍我在 ChatGPT 中发现的两个跨站脚本 (XSS) 漏洞以及其他一些漏洞。当它们链接在一起时，可能会导致帐户被接管。

深入探讨 ChatGPT

我的旅程从检查 ChatGPT 的技术堆栈开始。使用 NextJS（一种流行的 React 框架）最初让我对寻找 XSS 漏洞持怀疑态度。然而，当我探索它的功能和客户端代码时，我注意到一些事情改变了我的想法。

最初的发现

ChatGPT 允许用户上传文件并提出有关文件的问题。回答时，ChatGPT 可能会引用这些文件，并包含一个可点击的引用图标，让您返回原始文件或网站以供参考。

上面的代码处理引用点击事件。它将文件的内容处理成一个 blob，然后使用“window.open”函数打开它。根据文件内容类型，此方法可能存在安全风险。

我通过上传包含文本和 JavaScript 的 HTML 文件对此进行了测试。ChatGPT 对其进行了处理并提供了引用。当我单击引文时，HTML 内容通过 blob URL 显示在我的屏幕上，但内容安全策略 (CSP) 违规阻止了我的 JavaScript 负载。

绕过CSP

图 2：ChatGPT CSP 策略

在研究 CSP 策略时，我注意到本应是动态的随机数值是静态的。nonce 是一个唯一的字符串，可以让特定的 HTML 元素绕过 CSP 限制。通常，该值随每个请求而变化，确保仅执行服务器批准的元素。然而，这里却没有改变。

使用另一个帐户和不同的 IP 地址进行测试证实了该问题。然后，我上传了一个新的 HTML 文件，其中包含包含此随机数属性的脚本标记。这次，我的脚本在点击引用后就成功执行了。

挑战和限制

利用此漏洞并不简单。它要求用户上传有害文件并以提示 ChatGPT 引用该文件的方式进行操作。然后，用户需要点击引用来触发XSS。

我研究了 ChatGPT 的共享对话功能，作为使此漏洞可共享的可能方法。该计划是与目标共享对话链接并让他们点击引用，这将触发 XSS。

这种方法没有达到预期的效果。在 ChatGPT 对话中上传的文件只能由上传这些文件的帐户访问。尝试从另一个帐户访问这些文件会导致 404 错误。

知识文件的新方法

OpenAI 推出的GPT附带知识文件。这些文件通过一个 API 运行，该 API 与用户上传文件所用的 API 非常相似，但有一个值得注意的附加功能——“gizmo_id”参数。通过我的探索，我发现当GPT设置为公开时，任何帐户都可以访问和下载这些知识文件，只要他们有必要的信息——具体来说，GPT ID和关联的文件ID。

我认为这是一个功能级别授权错误，因为它允许任何 ChatGPT 用户下载公共 GPT 知识文件。

这导致了新的剥削可能性。如果我可以使共享对话请求公共文件而不是原始上传的文件，则可以利用 XSS 漏洞。

我重点关注用于启动 ChatGPT 对话的“/backend-api/conversation”端点。以下是请求正文的外观：

我注意到这个结构与我之前创建的共享 ChatGPT 对话的“pageProps”对象中看到的助理元数据类似。

我在助理消息元数据中看到了引文对象，其中包括我上传的文件 ID。这与我最初讨论的用于获取文件内容的易受攻击的代码所使用的 ID 相同。此时，我意识到如果我可以控制此元数据，我可能可以使此漏洞可共享。

尝试角色和质量分配

然后我探索了是否以及如何操纵这些元数据。我首先尝试将对话中的角色从“用户”更改为“助手”。令我惊讶的是，ChatGPT 接受了这一更改并继续生成响应，就像它们来自助手一样。

接下来，我尝试调整元数据以匹配我在“pageProps”对象中看到的引用结构。此方法也有效，表明存在批量分配漏洞。当应用程序不加区别地将用户提供的数据分配给内部对象或变量时，就会出现批量分配漏洞。如果应用程序没有正确过滤或限制可以分配的数据，则可能会发生这种情况。在这种情况下，我可以使用输入数据来操作 ChatGPT 应用程序的各个方面（特别是引文元数据），而这些方式通常对普通用户来说是禁止的。

漏洞利用

我向“/backend-api/conversation”端点创建了一个新请求，模拟助手并注入自定义引用对象。我所做的唯一更改是将文件 ID 设置为“file-Cbn7djQD1W20s3h5JM8NfFs8/download?gizmo_id=g-ghPiYIKcD#”，强制 ChatGPT 客户端改为使用 GPT API。

此漏洞按计划发挥作用。我创建并共享了一个对话，当使用另一个 ChatGPT 帐户进行测试时，单击对话中的任何引用都会从我的公共 GPT 中下载知识文件，从而触发了 XSS。

我向 OpenAI 报告了这个漏洞。他们的回应是删除 blob 创建并更改逻辑以直接打开下载 URL。

图 7：OpenAI 的修补代码

修复后，我检查了涉及“context_connector”、“元数据”和“download_url”的附加功能。然而，这些组件没有出现任何新的漏洞，因为对话元数据无法直接控制这些值。

另一个 XSS 漏洞

然后，我通过检查与 ChatGPT 如何处理网站引用呈现相关的其他功能来扩大我的调查范围。这次探索让我得到了以下代码：

图 8：易受攻击的代码 #2

在检查代码时，我注意到引文元数据对象（在代码中引用为“em” ）直接用于设置引文链接的“href”属性（即“em.url”）。这是一个危险信号，因为正如我已经确定的那样，我可以通过冒充助手来操纵元数据。

初步测试和新挑战

为了测试此漏洞，我建立了一个新对话。在此设置中，我操作了引文元数据，将其 URL 值设置为 JavaScript 协议 URL，例如“javascript:alert(1)”。然而，开发并没有按计划进行。虽然我成功地将锚标记的 `href` 属性设置为我的 JavaScript URL，但该标记还包含一个 `target=”_blank”` 属性。正如我在之前的博客文章“使用键盘快捷键攻击 Microsoft 和 Wix ”中所讨论的，此属性只能使用键盘快捷键来利用。

ChatGPT 允许使用“iframe”将其界面嵌入到其他网站中。这意味着可以从完全不同的网站触发该漏洞。

在我的概念验证中，我将共享的 ChatGPT 对话嵌入到“iframe”中，并使用 CSS 对其进行定位，以便任何点击都会无意中触发引用链接。为了使 iframe 不可见，我将其不透明度设置为零。在这个不可见的 iframe 上，我添加了文本“按住 ⌘ 并单击以在新选项卡中打开我”。遵循这些说明的用户会在不知情的情况下在 chat.openai.com 上执行任意 JavaScript。

SameSite Cookie 和存储分区

另一个障碍涉及SameSite cookie和存储分区，安全措施旨在通过限制浏览器跨不同来源管理 cookie 和其他类型存储的方式来保护网络隐私和安全。在我们的场景中，当用户访问嵌入了链接到 ChatGPT 共享对话的 iframe 的恶意网站时，这些措施将阻止对 ChatGPT 会话 cookie 和 LocalStorage 的访问，从而有效地将他们从 iframe 中的帐户注销。

这些安全功能旨在防止跨站点请求伪造 (CSRF) 攻击和各种形式的侧通道跨站点跟踪攻击，例如定时攻击、XS 泄漏和跨源状态推断 (COSI) 攻击。值得注意的是，这些措施的威胁模型不包括跨站点脚本（XSS），这是我们在这种情况下利用的漏洞。

通过创建包含 HTML 内容的 Blob 对象并使用 chat.openai.com 上下文中的 URL.createObjectURL 方法为其生成 URL，我能够将父窗口导航到此 Blob URL。这绕过了 SameSite cookie 限制和存储分区。这是可能的，因为从 chat.openai.com 内部发起的导航被视为同源请求，因此不受典型的跨源限制，从而可以接管任何 ChatGPT 帐户。

下面是我们最终的利用代码：

图 9：最终的利用代码

OpenAI 的修复

发现这些漏洞后，我立即与 OpenAI 分享了我的概念验证。他们的响应速度非常快，通过添加引用 URL 的客户端验证，在几个小时内修复了 XSS 问题。

下面，您可以看到在渲染引文链接时添加并使用了“eF”方法，验证了只能使用“https”、“mailto”和“tel”协议。

图 10：OpenAI 的修补代码 #2

结束语

我想对 OpenAI 表示感谢，感谢他们通过协作和有效的方法来解决这些漏洞。得知我们的努力让 ChatGPT 对于所有用户来说更加安全，我感到很欣慰。

请关注我们的下一篇博客文章，我们将深入研究双重代理攻击，这是我们为类似 ChatGPT 的系统开发的一种新的后利用技术。