背景介绍

许多影响最大的漏洞是无法通过 Burp Suite 的默认规则集捕获，而需要手动测试，本文就是讲述了这样一个的案例。

发现异常

与往常一样，研究人员的调查首先在 Burp Suite 中捕获所有 ChatGPT 请求，然后启动’自动扫描‘来寻找 API 中值得探索的’有趣‘领域。

当使用 Burp Suite 的自动扫描针对 ChatGPT 等成熟 API 测试时，一般不会抱有发现漏洞的期望。更多的是通过寻找奇怪的响应或错误响应。

很多人在执行 API 测试时往往会忽略观察 Logger 中一闪而过的自动请求，在自动扫描期间观察Logger时，研究人员通常会查看两处主要细节：HTTP Status code和响应长度（Length），在查看 ChatGPT 的 API 上运行的定制化 Burp Suite 扫描时，出现了下面的奇怪请求：

这是一个 401 响应状态码，并且响应长度不是864字节，同时在 Query 列中还多了一串字符串。让我们看看这个请求包的具体样子：

左侧的请求是对 TE.CL HTTP 请求走私测试，右侧的响应是对单个请求的两个响应。

深入挖掘

简化PoC，以便能够更好地了解后端发生的情况：

这些请求中的每一个都使用准确的 Content-Length 标头，但未使用正常的双 rn 去正确终止。

看起来前端 CloudFlare 服务器仅根据内容长度而不是进一步的分隔符来解析多个请求，于是将分解的请求分别发送到了后端服务器。

这是 HTTP 请求走私吗？

这不太符合 HTTP 请求走私的传统定义，当攻击者发送PoC请求时，就会发生常规 HTTP 请求走私，该请求在前端服务器和后端服务器之间进行不同的解析，导致攻击者或应用程序的用户接收到他们不希望接收的数据。

看起来这好像是基于原始异常请求的 HTTP 请求走私，但经过深入研究，似乎更像是 HTTP 请求隧道。

HTTP 请求隧道能够发送打包在单个请求中的多个请求，并让后端单独解析它们。它本身并不是一个漏洞，但它是对正常代码路径的一个有用的偏离，通常会导致利用。

研究人员尝试了许多不同的方法来利用这一点，使用多个不同的授权令牌，添加新的标头，例如“openai-organization: openai”，更改主机标头以指向不同的域，在请求其他用户的数据时添加“please”和“thank you”，该架构的一个突出特点就是绕过了速率限制。

速率限制绕过

我们通常会使用 TurboIntruder 插件来测试速率限制绕过，该插件使用自己的自定义网络堆栈以极快的速度向服务器发送请求，但这无法绕过 text-davinci-edit-001 模型的 20 个请求/分钟限制。

使用 TurboIntruder 测试时，会发现立即收到了 20 个请求，然后收到 429 Rate Limit Exceeded HTTP 响应，这表明 API 速率限制按预期执行。

然而使用多个PoC请求叠加的自定义Repeater group中，可以在 50 秒内获得了 31 个响应：

Protect AI 几个月前通过漏洞赏金计划联系了 OpenAI，但 OpenAI 认为这不是漏洞。

并未结束

根据测试中对API的观察，研究人员坚定认为这不太可能是ChatGPT API 这个特定‘怪癖’中潜在可利用性的终结，并且在测试过程中出现了其他一些有趣的事情。

例如，并不是每次都会收到对所有拆分请求的响应，当在单个请求中包含 2 个拆分请求时，大约 90% 的情况下会收到两个响应，那么其他请求去了哪里？

它们是否正在被处理？或是被发送给了另一个用户？是否存在响应队列‘中毒’的可能性？此外，通过向服务器提供无效的授权令牌，可以显著增加服务器的响应时间，这可能有利于增加连接打开的时间并导致服务器的HTTP响应队列出现问题。

以上内容由骨哥翻译并整理。

原文：https://blog.huntr.com/advanced-api-attacks-in-chatgpt