了解最常見的 LLM 漏洞，網絡犯罪分子如何利用它們以及如何預防它們。

譯自7 LLM Risks and API Management Strategies to Keep Data Safe，作者 Ash Osborne。

盡管圍繞大型語言模型 (LLM)的熱情激增，但任何新的基于云的軟件解決方案都可能產生或暴露新的漏洞。讓我們探討 Open Web Application Security (OWASP) 項目發布的七種 LLM 漏洞，以及如何通過應用 API 管理安全來緩解這些風險。每節將詳細介紹一個特定的漏洞，例如提示注入或不安全的輸出處理，解釋網絡犯罪分子如何利用這些弱點，并提供實用的API 管理技術來防止這些威脅。

1. 提示注入

提示注入是指黑客能夠通過偽裝成合法提示的惡意提示，誘使 GenAI 模型做出意想不到的輸出。在這種攻擊中，如果我們不限制可以傳遞給 LLM 的提示，攻擊者可以精心設計一個請求，導致意外結果。例如，一個聊天機器人，而不是幫助用戶，開始侮辱他們。

為了緩解這種類型的攻擊，開發人員應該實施傳統的身份驗證和訪問控制，以確保只有授權用戶可以與 LLM 交互。然后，在將請求發送到模型之前，應該執行提示檢查 - 或者通過使用預處理器和后處理器來限制 LLM 可以做什么，或者通過使用模板來限制實際請求成為參數化形式。另一種選擇是使用自訓練的 LLM 或第三方服務來檢查 LLM 請求和響應的內容安全。

2. 不安全的輸出處理

通過盲目信任從 LLM 返回的響應，后端系統可能會無意中暴露，這可能導致跨站點腳本、跨站點請求偽造、服務器端請求偽造、權限提升或遠程代碼執行等問題。

對抗這種漏洞的第一步是實施提示范圍，這將提示的范圍限制在 LLM。響應也應該在返回給請求者之前進行審查，這可以像應用正則表達式模式一樣簡單，也可以像使用 LLM 本身來掃描內容以查找有害響應一樣高級。

3. 模型拒絕服務

用請求過載 LLM 會導致服務質量下降或資源成本增加，這對任何組織來說都是最糟糕的結果。然而，在模型拒絕服務中，這就是風險所在。當攻擊者對 LLM 造成資源密集型操作時，就會發生這種情況。這可能看起來像比正常情況更高的任務生成或重復的長輸入，僅舉幾例。

身份驗證和授權可用于防止未經授權的用戶與 LLM 交互。每個用戶的令牌數量的速率限制也應該用于阻止用戶消耗組織的積分，導致高成本和使用大量計算導致延遲注入。

4. 敏感信息泄露

合規團隊對敏感信息泄露的擔憂可能是限制 LLM 采用的最嚴重漏洞之一。當模型無意中可以返回敏感信息時，就會發生這種情況，導致未經授權的數據訪問、隱私侵犯和安全漏洞。

開發人員可以實施的一種技術是使用專門訓練的 LLM 服務來識別并刪除或混淆敏感數據。這也可以用于非 LLM 基于的用例。此外，可以指示 LLM不返回某些類型的數據，限制它們將如何響應。

5. 不安全的插件設計

如果訪問控制不足且輸入不安全，您將面臨不安全的插件設計。當擴展在用戶交互期間由模型自動調用時，就會發生這種情況。擴展由模型本身驅動，應用程序對執行沒有控制權。通過利用這一點，攻擊者可以構建一個惡意請求，導致各種不希望的行為。

為了緩解這種風險，通過授權和身份驗證來限制誰以及什么可以訪問底層 LLM。這通過限制對敏感操作的訪問來降低被利用的風險。還應將清理和控制應用于提示請求，以限制在操作調用中可以執行的操作。

6. 過度代理

當授予過多的功能、權限或自主權時，LLM 系統可能會采取導致意外后果的行動。這是一個威脅，應通過可觀察性和流量檢查持續監控，以了解哪些內容與 LLM 交互以及如何使用它。還應使用授權和身份驗證來實施嚴格的訪問控制，以限制誰可以訪問和與系統交互。對于更敏感的操作，需要更高的授權級別。

7. 過度依賴

過度依賴是另一個與授予使用 LLM 的用戶或系統自主權有關的擔憂。如果沒有監督，由于模型生成的內容，可能會出現錯誤信息、誤傳甚至法律/安全問題。

解決方案：同樣，應通過授權和身份驗證實施訪問控制，并對更敏感的操作進行限制。與過度代理監控類似，應實施對流經系統的流量的可觀察性，使組織能夠了解正在發生的交互。還應使用提示控制來限制與 LLM 的交互方式。

最終，LLM 是通過 API 調用訪問的，應以與管理傳統 API 流量相同的方式進行管理。生態系統中的縱深防御和可觀察性是了解流量如何流經系統的關鍵。所有這些都可以通過具有專門集成以管理 AI API 流量細微差別的 AI 網關來實現。