评估 LLM 在存在漏洞的 Firebase 应用上的渗透测试能力

执行摘要

GPT-5.5 在自主识别和利用常见的 Firebase 配置错误方面表现出了最高的成功率，而许多其他旗舰模型由于僵化的安全护栏或无法从基于 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	2/10	$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 模糊测试）并尝试一个完全不同的向量（如直接 DB 访问）。
• 护栏 vs. 能力： 模型无法解决安全挑战，往往是安全对齐的结果，而非技术推理能力不足。
• 驾驭复杂性： 构建一个可靠的代理框架（agentic harness）来强制模型进行迭代，是实现安全研究自动化的最难部分之一。