Hello there, ('ω')ノ
🎯 1. NoSQLインジェクションとは？
NoSQLインジェクションは、MongoDBやCouchDB、Firebase、ElasticsearchなどのNoSQLデータベースに対して、 ユーザ入力が意図せずクエリ構文として解釈されてしまうことで、不正なデータ参照や認証バイパスなどが可能になる脆弱性です。
📦 2. 対象となる代表的なNoSQLエンジン
| データベース | 特徴 |
|---|---|
| MongoDB | JSONベースのドキュメント型DB（最も一般的） |
| CouchDB | HTTPインターフェースを持つドキュメントDB |
| Firebase | クライアント直結が多く認証に注意 |
| Elasticsearch | 検索系だが入力がクエリに反映される |
🧭 3. チェック対象となるページ・機能
| 機能・ページ | 入力ポイント | 備考 |
|---|---|---|
| 🔐 ログインフォーム | ユーザ名・パスワード | バイパスできるか試す |
| 🔍 検索機能 | キーワード | $regex, $gt, $neなどの注入 |
| 📤 APIリクエスト | JSONパラメータ | リクエスト本文に注意 |
| 🔄 ID指定API | id=xxxなどのクエリ |
条件を操作できるか確認 |
🧪 4. MongoDBベースの代表的なペイロード
🔓 ログインバイパス（認証繰り抜け）
入力欄に以下を入力：
| フィールド | 値 |
|---|---|
| ユーザ名 | {"$ne": null} |
| パスワード | {"$ne": null} |
結果 → 条件が常に真になり、ログイン成功するケースがある
🔍 クエリ操作によるデータ取得
例：検索欄に以下を入力
{"$gt": ""}
→ 文字列フィールド全てが対象に → 条件がゆるくなり、全件取得できてしまう
🔁 条件変更（IDなど）
"id": {"$ne": "0"}
→ id != 0 という条件に変化する
→ 他人のデータも取得できる可能性がある
🛠️ 5. 診断手順
- フロントエンドやAPIでユーザ入力がDBクエリに影響してそうな箇所を特定
- そのパラメータに 構造化されたJSON風のペイロード を挿入
レスポンスや挙動に異常があるか観察：
- ログイン成功してしまう
- 意図しないデータが表示される
- 全件取得などが起こる
🔐 6. よく使うペイロード一覧
| 目的 | ペイロード例 |
|---|---|
| 常に真（認証バイパス） | {"$ne": null} / {"$gt": ""} |
| 条件無視 | {"$regex": ".*"} |
| 論理演算 | {"$or": [{"isAdmin": true}, {"isAdmin": false}]} |
| ID操作 | id={"$ne": 1} |
📄 7. HTTPリクエスト例（Burpで試す）
POST /api/login HTTP/1.1
Content-Type: application/json
{
"username": { "$ne": null },
"password": { "$ne": null }
}
→ ログインが成功したら脆弱性あり
⚠️ 8. 注意点・ベストプラクティス
| ポイント | 説明 |
|---|---|
| JSON形式そのものが注入手段になる | 文字列で送るのではなく、構造を変えることで成立する |
| 入力値を文字列型で固定処理していないと危険 | toString() などの型変換が防止に有効 |
| クライアント直結型DB（Firebaseなど）は特に注意 | 認可ミスが重大な結果を引き起こす |
🧰 9. 補助ツール
- Burp Suite（JSONインジェクション対応）
- NoSQLMap：MongoDBベースの自動診断ツール
- Postman：JSONで柔軟に構造を操作しやすい
🔎 10. 見つけやすいヒント・兆候
- JSONベースのAPI
MongoError,unexpected token,invalid BSONなどのエラー- レスポンスに意図しない件数・権限データが含まれる
- 認証バイパス時に403や401にならない
Best regards, (^^ゞ
