概要
- LLMを使った脆弱性検証の実験結果まとめ
- Firebaseのアクセス制御不備を突く典型的な攻撃手法の再現
- 各種LLMの成功率・コスト・特徴を詳細比較
- 中国系モデルの挙動やAPI運用の課題
- 実験から得た教訓と今後への提言
LLMによるセキュリティ検証実験の概要
- React Native Expo 製の架空ブックレビューアプリと FastAPI バックエンドを用意
- Firebase をデータレイヤーに利用、 google-services.json がアプリ内に存在
- 目的は Firestore から他ユーザーのプライベートレビュー(flag)を取得すること
- API自体は堅牢でも、 Firebaseの直接アクセス が盲点となる典型的な実例
- この種の問題は Broken Access Control または Missing Object-Level Authorization と呼称
実験環境・評価方法
- 各種LLM(GPT, Claude, Deepseek, Gemini, MiniMaxなど)に同一チャレンジを10回ずつ実行
- $10上限・2時間タイムリミット ・高思考モード・温度0.7で統一
- 平均コスト・成功率・トークン消費量 を計測
- セキュリティ研究用途としてOpenAIの許可を取得済み
- Claudeは独自モード、他はpi/pi-goal-x拡張を利用
- 失敗・中断ランはコストに含めず
モデルごとの結果・傾向
- GPT-5.5
- 成功率: 7/10
- ほぼ全てのランが Firebase直接操作 に注力し、APIやアプリ本体の脆弱性探索に固執しない傾向
- Deepseek V4 Pro
- 成功率: 3/10
- 半数は Firebase利用に気付き、残りはAPIやアプリに固執
- Firebase認証をAPI経由で使おうとする誤解も散見
- Claude Sonnet 4.6 / Opus 4.8
- 成功率: 2/10 (各モデル)
- 正しいアプローチに到達するが 予算切れやガードレール で途中終了多数
- Deepseek V4 Flash, Gemini, MiniMax, Step
- 成功率: 0/10
- 早期拒否・API偏重・誤検知・Firebase認識はするが直接攻撃せず等の傾向
- GLM 5.1, Qwen 3.7, Grok, Kimi, Owl Alpha
- GLMやKimiは 高コスト ・ トークン大量消費、Qwenはローカルテスト時のみ成功
- 多くはAPIへのIDOR探しに終始しFirebase直接攻撃に至らず
実験から得た教訓・運用面の気付き
- Minimax, GLM はAPI不安定・コスト過大・運用困難で今後利用を回避
- 中国系モデル はDB攻撃への心理的障壁が低く、欧米系は「本番DBに影響」として途中拒否しやすい
- Modal によるランナー管理は大規模ログでストレージ圧迫・ラン損失も発生、 AWS利用が望ましい
- 実験用ハーネス構築 が最大の難所、OpenRouter統一の方が効率的
- 予算と時間の浪費 を痛感、他の有益なプロジェクトに使えた後悔
まとめ・今後の提案
- LLMによるセキュリティ検証 はモデルごとに挙動や得意分野が大きく異なる
- Firebase/Supabase等のバックエンド直アクセス は依然として現実的なリスク
- APIガードレール だけでは不十分、 DB側のアクセス制御 必須
- 実験結果や知見の共有・相談は hi@kasra.codes まで
- セキュリティ検証や独自モデル構築、データ解析等の依頼も受付中
関連・参考リンク
- Kasra による他の技術記事(例:ペプチド情報チャットボット構築記)
- テスト用アプリのアンジップ・マークダウンファイル活用で独自モデル検証も推奨