安全研究员 Kasra 做了一件多数人只会想想的事——他掏出约 1500 美元，让多款主流大模型去攻击自己亲手写的应用，看它们能不能找到真正的安全漏洞。结果既让人意外，又让人清醒。
实验设计：不是做题，是实战
大多数 LLM 安全评测用的是人造题目：给模型一段有明显漏洞的代码，问它"这里有什么问题？"这就像把答案写在考卷旁边再问考生能不能看见。
Kasra 的做法完全不同。他构建了一个叫 BookNook 的书评应用，漏洞藏在 Firebase 配置里——不是 API 逻辑缺陷，而是部署层面的配置错误。这种漏洞在真实项目中极为常见：开发者为了方便调试，把安全规则设成全开放，上线后忘了收紧。
关键设计点：
- 漏洞类型是配置错误而非代码缺陷——测试的是模型对真实运维场景的理解力
- 模型需要自己发现漏洞，而不是被告知"去找某个问题"
- 攻击路径涉及多步推理：发现配置问题 → 构造利用方式 → 执行攻击
这更像是一场渗透测试，而不是代码审计练习。
Firebase 配置错误：最常见的"隐形门"
Firebase 安全规则是这类实验的理想靶点。来看一个典型的错误配置和正确配置对比：
❌ 危险配置——BookNook 中的漏洞原型
// firestore.rules — 全开放，任何人可读写所有集合
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if true; // ← 上线后忘了改
}
}
}
这段规则的意思是：任何人、任何条件下都可以读写整个数据库的所有文档。开发阶段为了方便测试这么写很常见，但一旦部署到生产环境，用户数据、评论、甚至管理员配置全部裸奔。
✅ 正确配置——按集合和角色收紧
// firestore.rules — 按集合细分，仅认证用户可写
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// 书评：认证用户可读，仅作者可修改自己的评论
match /reviews/{reviewId} {
allow read: if request.auth != null;
allow create: if request.auth != null
&& request.auth.uid == request.resource.data.authorUid;
allow update, delete: if request.auth != null
&& request.auth.uid == resource.data.authorUid;
}
// 用户配置：仅本人可读写
match /users/{userId} {
allow read, write: if request.auth != null
&& request.auth.uid == userId;
}
// 其他集合：默认拒绝
match /{document=**} {
allow read, write: if false;
}
}
}
部署前可以用 Firebase 本地模拟器验证规则：
# 安装模拟器并测试规则
firebase emulators:start --only firestore
# 运行规则测试脚本
firebase emulators:exec --only firestore "node test-rules.js"
BookNook 的漏洞正是第一种配置——模型能不能从应用行为和公开信息中推断出这一点，才是实验的核心问题。
LLM 的攻击表现：能推理，但不会"嗅探"
Kasra 让多款主流模型（具体型号在原文中有详细列表）对 BookNook 发起攻击，观察它们的策略和成功率。
几个值得注意的现象：
模型擅长已知模式的推理。 当模型接触到 Firebase 相关线索时，它能迅速联想到"安全规则可能全开放"这一常见错误，并构造出合理的利用路径——比如直接写入恶意评论、读取其他用户数据。这说明模型对常见漏洞模式的"知识储备"是扎实的。
模型不擅长主动侦察。 真实渗透测试的第一步是信息收集：端口扫描、目录遍历、配置文件探测。LLM 缺乏这种主动"嗅探"能力——它不会像人类黑客那样先跑一遍 nmap 或翻遍 /robots.txt、/.env，再决定攻击方向。模型的推理是被动的，需要你把线索喂到它面前。
多步攻击链是薄弱环节。 从发现配置错误到完成数据窃取，中间可能需要 3-5 步操作（枚举集合名 → 构造请求 → 绕过前端校验 → 写入/读取数据）。模型在单步推理上表现不错，但在串联多步时容易丢失上下文或跳过关键步骤。
用 LLM 辅助安全测试：可复制的实践
虽然 LLM 还不能独立完成渗透测试，但作为辅助工具它已经很有价值。下面是一个可运行的 Python 脚本，用 OpenAI API 对自己的 Firebase 项目做规则审计：
"""
firebase_rule_auditor.py
用 LLM 审计 Firebase 安全规则，找出过度宽松的配置。
使用前：
1. pip install openai
2. export OPENAI_API_KEY="sk-..."
3. 把你的 firestore.rules 内容粘贴到 RULES 变量
"""
from openai import OpenAI
client = OpenAI()
# ← 替换为你自己的规则内容
RULES = """
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if true;
}
}
}
"""
PROMPT = f"""你是一名 Firebase 安全审计员。分析以下 Firestore 安全规则，
找出所有过度宽松的配置，并给出修复建议。
规则内容：
{RULES}
请按以下格式输出：
1. 漏洞位置（具体 match 路径）
2. 风险等级（高/中/低）
3. 攻击场景描述
4. 修复后的规则片段
"""
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": PROMPT}],
temperature=0.2, # 低温度，减少幻觉
)
print(response.choices[0].message.content)
运行方式：
export OPENAI_API_KEY="sk-your-key-here"
python firebase_rule_auditor.py
这个脚本做的是静态规则审计——把配置喂给模型让它分析。这比让模型自己去"发现"配置问题要可靠得多，因为线索是你主动提供的。
更完整的用法是结合 Firebase CLI 导出当前规则再审计：
# 导出当前项目的 Firestore 规则
firebase firestore:rules > current_rules.txt
# 把文件内容填入脚本中的 RULES 变量，然后运行审计
开发者该怎么做
Kasra 的实验揭示了一个现实：LLM 对已知漏洞模式的识别能力已经相当强，但它还不是一个能独立完成渗透测试的"AI 黑客"。对于开发者来说，这意味着：
收紧配置是第一防线。 模型能找到的漏洞，人类黑客更容易找到。Firebase 安全规则、AWS IAM 策略、Nginx 配置——这些部署层面的设置应该在上线前逐条审查，而不是依赖事后检测。
用 LLM 做静态审计，而不是动态攻击。 把配置文件、安全规则、权限模型喂给 LLM 分析，效果远好于让模型自己去"探索"你的系统。前者是模型擅长的模式匹配，后者是它目前做不好的主动侦察。
建立部署前检查清单：
- [ ] Firestore 安全规则是否包含
allow read/write: if true - [ ] IAM 策略是否使用了
*:*通配权限 - [ ]
.env文件是否暴露在公网可访问路径 - [ ] API 端点是否有未鉴权的管理操作
- [ ] CORS 配置是否允许任意 Origin
- [ ] 上述检查是否纳入 CI/CD 流程自动化
1500 美元的实验告诉我们：LLM 已经能读懂你的配置错误，但它还不会自己敲门。等它学会嗅探的那天，全开放的 Firebase 规则就不再是"忘了改"的小问题，而是已经被利用的大事故。现在就收紧规则，比等模型进化要便宜得多。