背景介绍
许多影响最大的漏洞是无法通过 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响应队列出现问题。
以上内容由骨哥翻译并整理。
