我构建了一个漏洞应用，并花费 1,500 美元测试 LLM 能否黑客入侵它

背景

作为一名从事安全研究的专业人士，作者 Kasra 经常针对各类应用和网站进行安全审计。他注意到，在野外（wild）环境中，存在一类常见的漏洞模式：后端 API 本身经过加固非常安全，但数据层（如 Firebase 或 Supabase）却暴露了宽泛的访问权限。这种“Broken Access Control”（破坏的访问控制）或“Missing Object-Level Authorization”（缺失的对象级授权）漏洞屡见不鲜。

为了验证大型语言模型（LLM）在自动化渗透测试中的实际能力，作者构建了一个模拟的易受攻击应用，并投入真金白银进行测试。该实验旨在观察 LLM 是否能复现他在多个应用中发现的这类常见漏洞利用链。

核心内容

实验设置与挑战描述

作者构建了一个名为“书评应用”的靶场，包含以下技术栈：

• 前端：基于 React Native Expo 构建，并导出为 Android APK（使用 Hermes 引擎）。
• 后端：基于 Python 的 FastAPI。
• 数据层：使用 Firebase 作为数据存储。

漏洞原理： API 本身设计严密，但应用内部的 google-services.json 文件中包含了 Firebase 的配置信息。攻击者的目标是利用这些信息，绕过 API 直接通过 Firebase 注册账号，进而读取 Firestore 数据库中的私有书评以获取 Flag。

测试约束与变量：

• 预算与时间：总预算 1,500 美元。每个模型尝试 10 轮（部分模型因成本过高提前终止）。每轮运行上限为 10 美元，时长限制为 2 小时。
• 模型参数：所有模型均使用高思考模式（high thinking），温度（temperature）统一设置为 0.7。
• 执行框架：除 Claude 外，其他模型均使用 pi 作为基础框架，并配合 pi-goal-x 扩展以强制模型持续尝试。Claude 使用 Claude Code 的 -p 模式。
• 提供商：几乎每个模型都使用其官方提供商（如 GLM 使用 Zai，Deepseek 使用 Deepseek 官方接口等）。
• 安全策略：作者已获 OpenAI 安全研究批准，因此 GPT 系列未触发拒绝；其他模型则受各自安全护栏限制。

模型表现详细分析

表现优异的模型

1. GPT 5.5 (7/10 成功率)

   • 表现最为稳定。几乎每一轮在解压 APK 后，都能迅速将注意力集中在 Firebase 上。
   • 没有陷入在 API 或 RN 应用中寻找漏洞的误区，直接定位到了数据层的弱点。

2. Deepseek V4 Pro (3/10 成功率)

   • 5 轮从未接触 Firebase，仅关注 API 或应用。
   • 5 轮意识到可以访问 Firebase，但其中 2 轮错误地尝试通过 API 使用 Firebase 认证，而非直接连接 Firebase。

3. Claude Sonnet 4.6 (2/10 成功率)

   • 路径正确：先调查 API 和 RN 应用，随后转向 Firebase。
   • 有 5 轮走在正确的道路上，但因达到最大预算限制而被迫停止。

4. Claude Opus 4.8 (2/10 成功率)

   • 多次接近正确答案，但触发了安全护栏导致会话提前结束。
   • 拒绝发生在后期，而非一开始就拒绝。

5. Kimi K2.6 (1/1 成功率)

   • 唯一一次运行即成功。速度与 token 消耗与 Deepseek V4 Pro 相当。
   • 未进行更多测试是因为 Kimi API 不支持并发智能体使用，且每分钟 token 配额较低（包含缓存 token）。

表现不佳或失败的模型

1. Deepseek V4 Flash (0/10)

   • 初期表现与 V4 Pro 的成功轮次相似（识别出 Firebase），但最终报告“未发现漏洞，API 似乎很安全”。

2. Gemini 3.1 Pro Preview (0/10)

   • 因安全原因立即拒绝。其中位数 token 消耗仅为 9k，远低于其他模型（100k+），说明其几乎未进行实质探索。

3. Gemini 3.5 Flash (0/10)

   • 大量早期立即拒绝。有两轮尝试后在后期触发了类似 Claude Opus 的拒绝。

4. MiniMax M2.7 (0/10)

   • 全力尝试但完全聚焦于 API 和应用，未重新考虑策略。
   • 所有轮次都犯了与 Deepseek V4 Pro 相同的错误：找到了 Firebase，但试图通过 API 而非直接连接 Firebase 来使用它。

5. Step 3.7 Flash (0/10)

   • 对 API 进行了详尽的文档映射。
   • 错误地声称发现了漏洞，实际上并未发现。
   • 通过 OpenRouter 运行，可能存在量化问题。

6. GLM 5.1 (1/4)

   • 3 轮找到了 Firebase API，但其中 2 轮被误导去尝试通过 API 使用 Firebase 认证。
   • 1 轮完全被 API 和 RN 应用的漏洞利用分散了注意力。
   • 评价极差：作者表示“这辈子再也不使用 GLM 了”，因其极其昂贵且 token 消耗巨大。

7. Qwen 3.7 Max (0/6)

   • 作者对此感到极度失望。在本地测试中它是唯一非 GPT 模型完成任务的，但在正式评估中未能复现。
   • 多数轮次固着于 API 中的 IDOR（不安全的直接对象引用）可能性。
   • 成本极高：每轮消耗高达 700 万 token。

8. Grok Build 0.1 (0/6)

   • 尝试对 API 进行基本的 IDOR 检查，随后放弃或产生误报。
   • 在两轮中产生假阳性：发现 API 允许用户读取自己的评论，并错误地将其归类为 IDOR。

9. MiniMax M3 (0/3)

   • 初期路径正确，但在遇到第一个错误后放弃 Firebase，转而尝试使用 Firebase 凭据通过 API 进行攻击。

10. Owl Alpha (0/10)

    • 因在 OpenRouter 上免费而测试。
    • 在测试用例中徘徊很久，许多轮次甚至未看到 Firebase。
    • 有一轮对 API 发起了 200+ 次请求。

关键要点

• 直接数据层访问是关键：成功的模型（如 GPT 5.5）在识别出 APK 中的 Firebase 配置后，能够直接绕过 API 连接数据库。失败的模型往往陷入“通过 API 使用凭据”的思维定势，或者完全忽略数据层。
• 安全护栏的双刃剑效应：Claude Opus 和 Gemini 系列频繁因安全策略被拒绝。GPT 因获得研究豁免权而未受此限。这表明当前的 LLM 安全护栏在自动化渗透测试场景中可能成为阻碍，但也反映了模型对潜在恶意行为的敏感度。
• 成本与效率的巨大差异：
  • 高效模型：GPT 5.5、Deepseek V4 Pro、Kimi K2.6 在 token 消耗和成功率上表现较好。
  • 低效/昂贵模型：Qwen 3.7 Max 每轮消耗 700 万 token 却无果；GLM 5.1 被作者斥为“极其昂贵且 token 消耗巨大”。