NoSQLインジェクションの深淵：JSONクエリ演算子が崩す認証の境界線
「SQLさえ防いでいれば安全だ」という認識は、Webアプリケーションの脆弱性診断において最も高くつく慢心だ。MongoDBをはじめとするドキュメント指向データベースにおいて、$gt（greater than）や $ne（not equal）といったクエリ演算子は、単なる利便性以上の「論理的破壊兵器」として機能する。
今日、我々アーキテクトが向き合うべきは、単なるバグではない。JSONという構造化データが、データベースの抽象化レイヤーを突き抜け、実行エンジンに直結する際の「型の不整合」という根本的な脆弱性だ。
1. 攻撃のメカニズム：論理演算子が切り開く「真」の領域
NoSQLインジェクションの本質は、アプリケーションがクライアントから受け取ったJSONオブジェクトを、そのままクエリフィルタとしてデータベースに渡してしまう点にある。
例えば、典型的な認証コードはこうだ。
// 脆弱な認証処理の例
const user = await db.collection(‘users’).findOne({
username: req.body.username,
password: req.body.password // ここがJSONオブジェクトで上書きされる
});
攻撃者が req.body.password に { "$gt": "" } というJSONを注入した場合、生成されるクエリは password: { $gt: "" } となる。「パスワードが空文字より大きい（存在し、かつ文字列である）」という条件は、実質的に常にTrueを返す。結果として、攻撃者はパスワードを知ることなく、データベース上の最初のユーザー（多くの場合、管理者）の認証をバイパスする。
これは、プロトコル層において「スカラ値（文字列）が期待される場所に、オブジェクト（演算子）が混入する」ことで発生する、いわば構文解析のミスマッチだ。
2. 回避不能な「型」の脆弱性：なぜサニタイズだけでは不十分か
多くの開発者が行う「特殊文字のエスケープ」は、NoSQLインジェクションに対しては無力である。なぜなら、攻撃者はクエリ文字列を改ざんしているのではなく、JSONの構造を悪用しているからだ。
真の防衛には、入力層での厳格な「型強制」と「構造検証」が必要になる。
推奨される防御実装：スキーマバリデーションの強制
Node.js環境であれば、Joi や Zod を用い、入力値が必ず「文字列」であることを保証しなければならない。
const { z } = require(‘zod’);
// スキーマ定義：入力が必ず単なる文字列であることを保証する
const loginSchema = z.object({
username: z.string().min(1),
password: z.string().min(8) // オブジェクトの注入を許さない
});
try {
const validatedData = loginSchema.parse(req.body);
// これ以降、passwordは必ず文字列として扱われる
const user = await db.collection(‘users’).findOne(validatedData);
} catch (e) {
// バリデーションエラーをログに記録し、不正アクセスを遮断
logger.warn(‘不正な入力構造が検出されました’, { error: e });
}
3. チーフホワイトハッカーの視点：アーキテクチャの多層防衛
単一のバリデーションに依存するのは、セキュリティアーキテクトとしては失格だ。以下の3層構造で守りを固めるべきだ。
1. 入力の正規化（Type Enforcement）:
アプリケーション層の境界で、すべての入力JSONをプリミティブ型（string, number, boolean）に強制変換する。$ne や $gt を含むオブジェクトを即座に破棄するガードレイルを配置する。
2. データベース権限の最小化:
アプリケーションが利用するDBユーザーには、find 権限のみを与え、admin 権限や eval 権限を剥奪する。万が一インジェクションが成功しても、データ構造の破壊やJavaScriptの実行を許さない。
3. 生成AIによるガードレイルの自動監査:
最近では、CI/CDパイプラインにLLMベースの静的解析ツールを組み込み、ソースコードから「データベースのクエリ構築パターン」を抽出し、演算子が外部入力を直接受けていないかを自動検証させている。プロンプトインジェクションと同様、NoSQLの演算子注入も「構造の信頼境界」を定義することが防御の鍵だ。
最後に：セキュリティは「仕様の隙間」に宿る
NoSQLインジェクションは、技術が進歩しても消えない。なぜなら、それはデータベースの「柔軟なクエリ機能」と「開発の利便性」というトレードオフが生み出す影だからだ。
我々エンジニアがなすべきことは、ツールを疑い、仕様の隙間を埋め続けること。最新の耐量子暗号を導入するのも重要だが、まずは、そのJSONクエリが「誰の意志で構築されているのか」を、コードの行間から問い直してほしい。
脆弱性は常に、設計者の「想定外」という名の隙間に潜んでいるのだから。
コメント