評估 LLM 在易受攻擊的 Firebase 應用程式上的滲透測試能力

執行摘要

GPT-5.5 在自主識別並利用常見的 Firebase 配置錯誤方面展現了最高的成功率，而許多其他旗艦模型則因僵化的安全護欄（guardrails）或無法從基於 API 的攻擊轉向直接資料庫存取而失敗。在一個涉及易受攻擊的 React Native 應用程式的測試中，GPT-5.5 在 70% 的執行次數中解決了挑戰，表現顯著優於 Claude 和 Gemini 等競爭對手。

挑戰：Firebase 中的失效存取控制

該實驗使用了一個使用 React Native (Expo) 開發並搭配 Python (FastAPI) 後端的自定義書籍評論應用程式 (BookNook)。雖然 API 本身是安全的，但該應用程式在資料層包含一個關鍵漏洞：失效存取控制（或缺失的物件層級授權）。

漏洞細節

缺陷： 該應用程式包含一個 google-services.json 檔案，其中含有 Firebase 配置細節。
利用方式： 攻擊者可以直接透過 Firebase 註冊為使用者，並讀取 Firestore 資料庫，從而完全繞過強化的 API 來獲取私密使用者評論（即「flag"）。
現實世界相關性： 這種特定模式——安全的 API 搭配開放的 Firebase/Supabase 權限——是生產環境中常見的漏洞。

模型性能比較

研究人員以 10 美元的預算和每次執行兩小時的時間限制測試了幾種高推理能力的模型。

表現最佳者

模型	解決率	平均每次執行成本	每次解決成本	中位數 Token 數/每次執行
GPT-5.5	7/10	$6.62	$9.46	260k
DeepSeek V4 Pro	3/10	$0.62	$0.62	194k
Claude Sonnet 4.6	2/10	$9.15	$45.75	390k
Claude Opus 4.8	$3.23	$16.15	113k

未能解決問題的模型

包括 DeepSeek V4 Flash、Gemini 3.1 Pro Preview、Gemini 3.5 Flash、MiniMax M2.7 和 Step 3.7 Flash 在 10/10 次執行中均未能解決挑戰。

失敗模式分析

模型失敗的主要原因有三個：架構固著、安全護欄以及可靠性問題。

1. 架構固著

許多模型（包括 MiniMax M2.7 和幾次 DeepSeek V4 Pro 的執行）都變得對 API 過於固著。他們嘗試在 FastAPI 後端尋找 IDOR (Insecure Direct Object Reference) 漏洞，一旦 API 被證明是安全的，便無法轉向 Firebase 資料庫。有些模型找到了 Firebase 憑證，但錯誤地嘗試使用它們來對 API 進行身份驗證，而不是直接存取資料庫。

2. 安全護欄與拒絕執行

護欄顯著影響了西方模型的解決率：

Gemini: 因為安全原因立即拒絕執行，這反映在非常低的中位數 Token 數（例如，Gemini 3.1 Pro 為 9k）。
Claude: 經常達到正確的路徑，但觸發了「延遲拒絕」，即在模型即將執行利用程式碼時，對話階段結束了。
GPT-5.5: 表現最佳的部分原因在於研究人員的帳號已預先獲准進行安全研究，從而消除了大部分拒絕情況。

3. 資源與 API 穩定性

研究人員指出，中國模型（GLM, MiniMax）在攻擊資料庫時通常表現得更「自在」，沒有道德上的猶豫。然而，這些模型常受到頻繁的 API 中斷和高 Token 消耗的影響。例如，Qwen 3.7 Max 在最終評估中，每次執行消耗了高達 732 萬個 Token，卻未能成功解決挑戰。

社群觀點

安全專業人士與 AI 使用者之間的討論突顯了關於目前 LLM 驅動滲透測試現狀的幾個關鍵點：

「我注意到隨著每次模型發布，Anthropic 在安全性方面對模型進行了更多限制... 最終這些模型將會因為過度擬合於最低公分母而遭受重大損失。」

一些貢獻者認為這種方法論是天真的，因為它期望模型能夠完全自主地工作。他們建議「與模型協作」（人機協作）對於處理進階挑戰（如修補二進位檔或繞過反偵錯技術）要有效得多。

AI 安全測試的關鍵教訓

轉向攻擊向量很困難： 除非有明確的提示，否則 LLM 很難放棄失敗的策略（如 API fuzzing）來嘗試完全不同的向量（例如直接 DB 存取）。
護欄 vs. 能力： 模型無法解決安全挑戰，通常是安全對齊（safety alignment）的結果，而非缺乏技術推理能力。
駕馭複雜性： 建立一個可靠的代理人框架（agentic harness）來強制模型進行迭代，是實現安全研究自動化中最困難的部分之一。