LLM攻擊與防禦
大型語言模型攻擊
最近各組織正急於整合大型語言模型（LLMs）以改善其線上用戶體驗。這使它們面臨網路LLM攻擊的風險，這些攻擊利用模型對攻擊者無法直接存取的資料、API或使用者資訊的存取權。例如:
- 擷取LLM可存取的資料。這類資料的常見來源包括LLM的提示、訓練集和提供給模型的API。
- 透過API觸發有害行為。例如，攻擊者可能利用LLM對其可存取的API執行SQL注入攻擊。
- 對查詢LLM的其他使用者和系統觸發攻擊。
從高層次來看，攻擊LLM整合通常類似於利用伺服器端請求偽造（Server-side Request Forgery, SSRF）漏洞。在這兩種情況下，攻擊者都在濫用伺服器端系統來對無法直接存取的獨立元件發動攻擊。
LLM攻擊和提示注入
許多網路LLM攻擊依賴一種稱為提示注入的技術。這是指攻擊者使用精心設計的提示來操縱LLM的輸出。提示注入可能導致AI執行超出其預期目的的行為，例如對敏感API進行錯誤呼叫或返回不符合其指導方針的內容。
檢測LLM漏洞
我們建議的檢測LLM漏洞方法是：識別LLM的輸入，包括直接（如提示）和間接（如訓練資料）輸入。
- 找出LLM可存取的資料和API。
- 探測這個新的攻擊面以尋找漏洞。
- 利用LLM API、功能和外掛程式
LLM通常由專門的第三方供應商託管。網站可以透過描述本地API供LLM使用，來讓第三方LLM存取其特定功能。例如，用戶支援LLM可能有權存取管理使用者、訂單和庫存的API。LLM API的運作方式
將LLM與API整合的工作流程取決於API本身的結構。在呼叫外部API時，某些LLM可能要求用戶端呼叫單獨的功能端點（實際上是私有API）以生成可發送到這些API的有效請求。這種工作流程可能如下所示：用戶端以使用者的提示呼叫LLM。
LLM檢測到需要呼叫功能，並返回一個包含符合外部API架構的參數的JSON物件。
- 用戶端以提供的參數呼叫功能。
- 用戶端處理功能的回應。
- 用戶端再次呼叫LLM，將功能回應附加為新訊息。
- LLM以功能回應呼叫外部API。
- LLM將此API呼叫的結果摘要回傳給使用者。
這個工作流程可能有安全隱憂，因為LLM實際上是代表使用者呼叫外部API，但使用者可能不知道這些API正在被呼叫。理想情況下，應該在LLM呼叫外部API之前向使用者提供確認步驟。映射LLM API攻擊面
「過度代理」一詞指的是LLM可存取能夠存取敏感資訊的API，並且可被說服不安全地使用這些API的情況。這使攻擊者能夠將LLM推至超出其預期範圍，並透過其API發動攻擊。使用LLM攻擊API和外掛程式的第一階段是找出LLM可存取哪些API和外掛程式。一種方法是直接詢問LLM它可以存取哪些API。然後，使用者可以詢問任何感興趣的API的其他詳細資訊。如果LLM不配合，可以嘗試提供誤導性的背景並重新提問。例如，使用者可以聲稱自己是LLM的開發者，因此應該有更高的權限。
防禦LLM攻擊
為防止許多常見的LLM漏洞，在部署與LLM整合的應用程式時，請採取以下步驟。
- 將提供給LLM的API視為公開可存取
由於使用者可以透過LLM有效地呼叫API，開發者應該將LLM可存取的任何API視為公開可存取。實際上，這意味著開發者應該執行基本的API存取控制，例如始終要求驗證才能進行呼叫。此外，開發者應確保任何存取控制都由LLM通訊的應用程式處理，而不是期望模型自我約束。這特別有助於減少間接提示注入攻擊的可能性，這些攻擊與權限問題密切相關，並且可以通過適當的權限控制在一定程度上得到緩解。不要向LLM提供敏感資料
在可能的情況下，開發者應避免對其整合的LLM提供敏感資料。開發者可以採取幾個步驟來避免無意中向LLM提供敏感資訊：
- 對模型的訓練資料集應用強大的淨化技術。
- 只向模型提供最低權限使用者可能存取的資料。這很重要，因為模型消耗的任何資料都可能被揭露給使用者，特別是在微調資料的情況下。
- 限制模型對外部資料來源的存取，並確保在整個資料供應鏈中應用強大的存取控制。
- 定期測試模型
你可能也想看
