NoSQLインジェクションの深淵：型混乱が招く「クエリ・ハイジャック」の解剖学
多くの開発者がSQLインジェクションを「過去の遺物」と誤認し、MongoDBやRedisといったNoSQLの海へ飛び込む。しかし、彼らは重大な事実を見落としている。NoSQLにおいて、データは単なる「文字列」ではなく、プロトコル層でパースされる「構造体」として扱われるという事実だ。
NoSQLインジェクションは、SQLiのような構文の破壊ではなく、「型混乱（Type Confusion）」によるクエリの論理的なすり替えである。
1. なぜ「型」が攻撃ベクトルになるのか
多くのNoSQLデータベースは、クライアントからの入力（例えばJSONのボディ）をそのままクエリ演算子として解釈する。ここで致命的なのは、Node.jsのreq.bodyやPHPの連想配列が、意図しない型（ObjectやArray）を受け入れたときに生じる挙動だ。
例えば、パスワード認証のロジックで以下のような実装を見かける。
// 脆弱な実装例：バリデーションなき入力の直接利用
const user = await db.collection(‘users’).findOne({
username: req.body.username,
password: req.body.password // ここに { “$ne”: null } が渡されたら？
});
攻撃者がJSONボディに {"username": "admin", "password": {"$ne": null}} を送り込めば、DBは「passwordがnullでないユーザー」を探し出し、認証をバイパスする。これは、アプリケーションが「文字列を期待している場所に、演算子を含むオブジェクトが混入した」ことに起因する。
2. プロトコル層からの視点：なぜバリデーションが「最強の防壁」か
この攻撃を食い止めるのは、WAFやエッジのフィルタリングではない。アプリケーション層の深部で行う「厳格な型スキーマバリデーション」のみである。
メモリレイヤまで掘り下げると、この問題は「データのシリアライズとデシリアライズの非対称性」に起因する。通信プロトコル（BSONやJSON）は、構造化データをそのままメモリ上のデータ構造にマッピングするため、受け取り側のアプリケーションが「この値はプリミティブなString型でなければならない」という制約を強制しない限り、DBドライバはその構造を「指令（Command）」として解釈し続ける。
3. 実践：防御アーキテクチャの構築
「信頼してはいけない。常に型を強制せよ」。これが鉄則だ。実務では Joi や Zod を用い、入力の境界で徹底的に構造を精査する。
import { z } from ‘zod’;
// 入力スキーマの厳格な定義
const loginSchema = z.object({
// 文字列型であることを強制し、かつ余計なキー（$から始まる演算子等）を排除する
username: z.string().min(1).max(50),
password: z.string().min(8).max(128)
});
// コントローラーでの適用
async function handleLogin(req, res) {
try {
// 構造が一致しない場合、ここで即座に弾く
const validatedData = loginSchema.parse(req.body);
const user = await db.collection(‘users’).findOne({
username: validatedData.username,
password: validatedData.password
});
// …以降の処理
} catch (err) {
// 監査ログに不正な型入力を記録する（異常検知のトリガーとなる）
log.error(‘Invalid input structure detected’, { ip: req.ip });
res.status(400).send(‘Invalid request’);
}
}
4. セキュリティアーキテクトとしての提言
この問題の本質は、「入力のバリデーション」という古典的な概念が、NoSQLという柔軟なデータ構造と衝突した際に発生する「意味論的脆弱性（Semantic Vulnerability）」にある。
今後の防御層には、単なるスキーマ検証を超えた「ガードレイル」が必要だ。
- 型強制のオートメーション: TypeScriptのインターフェースだけでなく、ランタイムでの型チェック（io-tsやZodなど）をCI/CDパイプラインの必須条件とする。
- クエリ・カプセル化: DBドライバに直接生のリクエストオブジェクトを渡さず、必ず「DTO（Data Transfer Object）」を経由させ、演算子を含まないプリミティブな値のみを抽出する層を設けること。
- クエリログの異常検知: データベースのクエリログを解析し、
$ne,$gt,$regexといった演算子が、本来含まれるべきでないフィールドに含まれていないかを監視する。これは、生成AIによるプロンプトインジェクション検知にも通じる、構造化データの異常検知手法だ。
最後に
セキュリティとは、境界線を引くことではなく、「何が正しい構造であるか」を徹底的に定義し続ける作業である。NoSQLの自由度は、悪意ある入力に対してあまりに無防備だ。
あなたが次にコードをレビューする時、その req.body は本当にあなたが期待した「文字列」なのか、それとも攻撃者が送り込んだ「実行可能な指令」なのか。その疑念こそが、最強の防衛の第一歩となる。
コメント