NoSQLインジェクションとは？仕組みと防止策

NoSQLインジェクションとは？

NoSQLインジェクションは、攻撃者がサニタイズされていないユーザー入力を通じて悪意のある演算子、JavaScriptコード、細工した構文を挿入し、NoSQLデータベースに送られるクエリを操作する脆弱性です。Common Weakness Enumeration（CWE）では、CWE-943「データクエリロジックにおける特殊要素の不適切な無害化」に分類されます。標準SQLの代わりに、柔軟でスキーマを必要としないクエリ言語を使うMongoDB、Redis、Cassandra、Elasticsearchなどのデータベースが対象です。

攻撃が成功した場合の影響は、単一の不正なクエリにとどまりません。攻撃者は認証を完全に回避し、機密データを1文字ずつ抽出し、レコードを改ざんし、サービス拒否状態を引き起こし、サーバー上で任意のコードを実行できます。 OWASP WSTGによると、NoSQLインジェクションのペイロードは宣言型のクエリ言語だけでなくJavaScriptのような手続き型言語内でも実行され得るため、「潜在的な影響は従来のSQLインジェクションよりも大きい」とされています。

現在、NoSQLデータベースはログインシステムやチャットプラットフォームから、ECカタログやIoT管理コンソールまで、幅広く利用されています。普及が進む一方で、「SQLを使わなければインジェクションも起きない」という誤解が広まり、この脆弱性は根強いリスクとなっています。その思い込みは誤りであり、攻撃者はそこを突きます。 

NoSQLインジェクションの実際の仕組みを見る前に、標準的な脆弱性分類の枠組みでどのように位置づけられるかを確認しましょう。

OWASPによる分類

OWASPは、2021年版と 2025年版Top 10の両方で、NoSQLインジェクションをインジェクションカテゴリに分類しています。SQLインジェクションと同じリスク群に属しますが、根本原因に基づく分類は異なり、テスト方法や報告方法にも影響します。

重要な違いはCWEとの対応関係です。従来のSQLインジェクションはCWE-89（SQLコマンドで使用される特殊要素の不適切な無害化）に該当します。一方、NoSQLインジェクションはCWE-943（データクエリロジックにおける特殊要素の不適切な無害化）に該当します。CWE-943は、MongoDBのBinary JSON（BSON）演算子、Redisプロトコルのコマンド、CouchDBのRESTベースのクエリなど、SQL以外のクエリ言語を対象とします。

セキュリティテストやコンプライアンス報告でCWE-89のみを追跡している場合、NoSQLインジェクションの検出結果が誤分類されたり、完全に見落とされたりする可能性があります。ツールと分類体系をCWE-943に対応させ、その盲点をなくしましょう。 

分類を確認したら、次は攻撃者がNoSQLのクエリインターフェースを悪用する具体的な仕組みを見ていきます。

NoSQLインジェクションの仕組み

NoSQLインジェクションは、悪用します。アプリケーションがユーザー入力に期待する内容と、実際に受け取る内容の食い違いを突く攻撃です。 SQLインジェクションが共通のクエリ言語を標的とするのに対し、NoSQLインジェクションの手法はデータベースごとに異なります。MongoDBはBSON/JSONクエリ演算子、RedisはRedis Serialization Protocol（RESP）ワイヤープロトコルを使用し、CouchDBはHTTP REST APIを公開しています。各データベースには異なる攻撃対象領域、しかし根本的な問題は同じです。ユーザーが制御できるデータが適切な検証を経ずにクエリに入り、そのロジックを変えてしまいます。

演算子インジェクション：最も一般的な手法

MongoDBをバックエンドに使用する一般的なNode.jsアプリケーションでは、ログイン用エンドポイントが次のようなクエリを構築します。

正規のリクエストは {"username":"admin","password":"secret"} を送信します。しかし、攻撃者は次の内容を送信できます。

この $ne（等しくない）演算子は、ユーザー名とパスワードが "invalid" ではないすべてのユーザーを返すようMongoDBに指示します。有効なアカウントはすべてこの条件に一致します。総当たり攻撃をせずに、1回のリクエストで認証を回避できます。

JavaScriptインジェクション：$where

アプリケーションがユーザー入力をMongoDBの $where 演算子や mapReduce、$accumulator、$function などの関数に渡すと、データベースはその入力をサーバー側のJavaScriptとして評価します。攻撃者がビジーループを起こすペイロードを注入すると、MongoDBインスタンスが動作不能になり、サービス拒否を引き起こす可能性があります。任意のJavaScriptの実行は、データアクセスにとどまらず、 リモートコード実行 をデータベースサーバー上で引き起こす可能性があります。

ブラインド抽出

アプリケーションがクエリ結果を直接返さない場合、攻撃者は真偽値や応答時間に基づく手法を使い、データを1文字ずつ抽出します。例えば password[$regex]=^a のような正規表現パターンを送信し、偽であることが分かっている条件との応答の違いを観察します。これにより攻撃者は、直接的な データ漏洩 を確認することなく、パスワード、トークン、その他の機密情報を復元できます。

CRLFを利用したRedisコマンドインジェクション

RESPでは、コマンドをキャリッジリターンとラインフィード（CRLF）の組み合わせ（\r\n）で区切ります。アプリケーションがユーザー入力をサニタイズせずにRedisのプロトコルレベルのコマンドに連結すると、攻撃者はCRLFを注入して現在のコマンドを終了し、同じ接続に不正なコマンドを便乗させることができます。

Redisはデータをキーと値のペアで保存します。注入された SET、GET、CONFIG などのコマンドは、機密データの読み取り、キーの上書き、サーバー全体の再設定に悪用される可能性があります。この手法は サーバーサイドリクエストフォージェリ（SSRF）と組み合わせられることがよくあります。攻撃者はSSRFの脆弱性を利用して、公開インターネットからアクセスできない内部のRedisインスタンスに到達し、SSRF経由で便乗させたコマンドを注入します。

CouchDBのHTTP APIインジェクション

CouchDBはREST/HTTP APIを公開し、すべてのデータベース操作をJSONペイロードを含む標準的なHTTPリクエストで処理します。アプリケーションがサニタイズしていないユーザー入力をCouchDBのクエリパラメータ、ビュー定義、Mangoセレクターオブジェクトに渡すと、インジェクションが発生します。

CouchDBはJavaScriptで記述されたMapReduceビューを使用するため、MongoDBの $where 演算子と同様に、サーバー側でのコード実行リスクがあります。MapReduceビュー内で実行されるJavaScriptに影響を与えられる攻撃者は、データベースサーバー上で任意のコードを実行できます。また、細工したHTTPリクエストでCouchDBのレプリケーション機能を悪用し、内部サービスに対するSSRFを引き起こすこともできます。

MongoDBのBSON演算子、RedisのプロトコルレベルのCRLFインジェクション、CouchDBのRESTベースのAPIなど、NoSQLデータベースにはそれぞれ固有の攻撃対象領域があります。NoSQLインジェクションへの防御は、各データベース固有のクエリインターフェースに合わせる必要があります。

これらの仕組みは、コンテンツの種類、トランスポート層、フレームワークを問わず機能します。根本原因は共通しており、その共通性を理解することが防御側の優位性につながります。

NoSQLインジェクションの原因

NoSQLインジェクションは、単一のコーディングミスから生じるわけではありません。アーキテクチャ上の前提、フレームワークの動作、検証レイヤーの欠如が組み合わさり、実行時に影響が増幅されます。

不適切な入力検証と型の強制不足

アプリケーションでは、passwordのようなフィールドが常に文字列として届くと想定していても、HTTPリクエストボディ、JSONペイロード、URLエンコードされたパラメーターにはオブジェクトや配列を含められます。Express.jsのbody-parserがpassword[$ne]=xを受け取ると、アプリケーションコードが処理する前に、自動的に{ password: { $ne: "x" } }というMongoDBの演算子を含むオブジェクトにデシリアライズします。

動的なクエリの構築

構造化されたクエリオブジェクトではなく、文字列の連結や補間でクエリを組み立てると、攻撃者はクエリ構文を破り、新たなロジックを挿入できます。この点は MongoDBフォーラムで次のように確認されています。「ほとんどの場合、外部からのインジェクションは、クエリ作成時に文字列を安全でない方法で連結することで発生します」

サーバーサイドJavaScriptの有効化

MongoDBでは、$where、mapReduce、$accumulator、$functionを通じてJavaScriptを実行できます。 また、 MongoDBのチェックリストでは、これらの操作を使用しない場合は--noscriptingでサーバーサイドスクリプティングを無効にするよう明確に推奨しています。有効なままにすると、任意のコードを実行される攻撃対象領域が生じます。

フレームワークによる型変換

PHPはusername[$ne]=totoを自動的に['username' => ['$ne' => 'toto']]に変換します。 Express.jsのbody-parserもURLエンコードされたフォームデータに対して同様に動作し、password[$ne]=xを、リクエストがアプリケーションコードに届く前に、{ password: { $ne: "x" } }というMongoDBの演算子を含むオブジェクトにデシリアライズします。こうしたフレームワークの動作により、開発者が意図的に操作しなくても、一見無害なHTTPパラメーターがデータベース演算子に変わります。

ORMレイヤーの脆弱性

MongoDB自体を堅牢化していても、アプリケーションのオブジェクト関係マッピング（ORM）ライブラリがインジェクションの侵入口になることがあります。CVE-2024-53900では、Mongooseの$where演算子がユーザーの制御する入力を通じて悪用され得ることが示されました。また、CVE-2025-23061は最初の脆弱性に対する修正が不完全だったことを示し、$whereを次の要素の下にネストすることで、なお回避できることを明らかにしました $or をMongooseのpopulate().match 機能で使用し、サーバーレベルの保護を完全に回避します。

ワイヤープロトコル検証の無効化

MongoDBは、net.wireObjectCheck 設定を通じて、受信するドキュメントをワイヤープロトコルレベルで検証します。これを無効にすると、不正な形式のBSONがクエリエンジンに到達するのを防ぐ構造上の安全策が失われます。

こうした原因により、HTTPの解析からデータベースでの実行にまで及ぶ攻撃対象領域が生まれ、ビジネスリスクに直結します。

影響とリスク

NoSQLインジェクションは、機密性、完全性、可用性の3要素（CIA）すべてに影響を及ぼし、複数の要素が同時に損なわれることも少なくありません。

• 機密性： 攻撃者は任意のドキュメントの読み取り、フィールド名の列挙、ブラインドインジェクション手法による認証情報の1文字ずつの抽出が可能です。 CVE-2021-22911では、研究者がRocket.Chatのインスタンスから管理者パスワードのハッシュとパスワードリセットトークンを漏洩させました。
• 完全性： 演算子インジェクションや生のクエリの悪用により、攻撃者はドキュメントを変更、置換、削除できます。便乗させたクエリで新たなレコードを挿入したり、既存のフィールド値を上書きしたりすることも可能です。
• 可用性： $where を使ったビジーループのペイロードは、ネットワークレベルの大量通信を必要とせずにMongoDBインスタンスを占有し、データベースを事実上停止させることができます。
• 認証の回避は、最も多く報告されている影響のひとつです。 このため、NoSQLインジェクションは、インターネットに公開されたアプリケーションへの初期アクセスに直結します。
• サプライチェーンと下流へのリスクは、プラットフォーム製品におけるNoSQLインジェクションの影響範囲を広げます。脆弱性によってRocket. ChatやParse Serverのようなプラットフォームが侵害されると、その影響はプラットフォームのテナントや下流のユーザーにも及びます。サービスとして提供されるバックエンド製品にインジェクションの欠陥がひとつあるだけで、そのプラットフォーム上に構築された多くのアプリケーションが露出し、ひとつの脆弱性が多数の環境の侵害につながります。
• 規制とコンプライアンス上の影響は、機密性の侵害に直接伴います。NoSQLインジェクションによって個人を特定できる情報、認証情報、顧客との通信内容が流出すると、組織にはGDPR、HIPAA、PCI DSS、州のプライバシー法などに基づく侵害通知義務が生じます。ブラインドインジェクション攻撃で使われる1文字ずつの抽出手法では、機密データが長期間にわたって気づかれずに流出する可能性があります。少しずつの流出は見逃しやすいため、早期検知が重要です。

• リモートコード実行は、サーバー側でのJavaScript評価を通じて確認されています。OWASP WSTGは、「JavaScriptは機能が豊富な言語であるため、攻撃者はデータを操作できるだけでなく、任意のコードも実行できる」と述べています。2025年のInternational Symposium on Digital Forensics and Security（ISDFS）の論文は、このリスクを端的に表現しています。「JavaScriptは強力であるため、このような脆弱性を露出させることは、熟練した犯罪者に機関銃を渡すようなものだ」

攻撃者の手口を知る防御者は、どの段階でも攻撃を阻止できます。その手口を見ていきましょう。

攻撃者によるNoSQLインジェクションの悪用方法

攻撃者は、偵察からデータ流出やコード実行に至るまで、体系的な手順でNoSQLインジェクションを発見し、悪用します。

フェーズ1：入力経路の特定

攻撃者は、NoSQLバックエンドに渡されるパラメータを特定します。対象にはURLパラメータ、JSON形式のPOST本文、HTTPヘッダー、WebSocketメッセージが含まれます。次に、ファジング用の文字 (' " \ ; { }) から、データベースとのやり取りを示すエラーメッセージや動作の変化を観察します.

フェーズ2: 演算子インジェクションの確認

攻撃者はログインエンドポイントで、通常の認証情報の文字列を $ne 演算子に置き換えます:

アプリケーションが別のユーザーとしてのログインを成功させた場合、演算子インジェクションが確認できます. 攻撃者は確認のために $gt (より大きい) 演算子も試します:

空文字列を指定した $gt 演算子は、空でないすべてのパスワード値に一致します. 有効なパスワードなしで管理者アカウントへのログインが成功すれば、演算子インジェクションがさらに裏付けられます.

フェーズ3: 認証の回避

攻撃者は両方のフィールドに演算子を注入し、攻撃をエスカレートさせます:

これは特権アカウントを狙い、ユーザー名がリストに一致し、パスワードが空でない文字列である最初のユーザーを返します.

フェーズ4: データの窃取

攻撃者は $where JavaScriptインジェクションを使い、フィールドの存在を探ります:

応答が有効と判明しているパターンに一致すれば、resetToken フィールドが存在します. 次に攻撃者は、真偽値に基づくブラインドインジェクションを使い、その値を1文字ずつ抽出します. この手法では、次のような正規表現パターンを送信し {"resetToken":{"$regex":"^A"}}、HTTP応答を観察します. 成功を示すステータスコードや特定の応答本文は文字の一致を示し、異なる応答は不一致を示します. 攻撃者は文字位置ごとに、候補となるすべての文字を試します. CVE-2024-37405 に記録されているとおり、この抽出は応答の差異を調べるリクエストを繰り返すことで実行でき、ブラインドインジェクションは理論上の懸念ではなく現実的な攻撃となります.

フェーズ5: 権限昇格とラテラルムーブメント

抽出した認証情報やリセットトークンを使い、攻撃者は管理者権限を取得します. そこからバックエンドシステムへ侵入を広げ、$lookup または $unionWith (PortSwiggerが選出した主要なWebハッキング手法) を使った集約パイプラインインジェクションでほかのコレクションにアクセスするか、サーバー側でコードを実行して永続化します. $lookup を使った集約パイプラインインジェクションは、影響の大きい手法です. アプリケーションのクエリが本来アクセスする想定のないコレクションからデータを読み取れるため、コレクション単位のアクセス境界を実質的に破り、データベース全体のデータを露出させます.

Content-Typeの切り替え

攻撃者は頻繁に application/x-www-form-urlencoded と application/json を切り替え、一方のコンテンツタイプにしか存在しないインジェクションポイントを探します. この手法は、複数の形式を扱うREST APIに対して特に有効です.

こうした攻撃手法は、NoSQLデータベースがユーザー入力を受け付けるあらゆる場所に当てはまります. 中でも、攻撃にさらされやすいアプリケーションがあります.

影響を受けるのは誰か?

NoSQLインジェクションは、適切な型の強制なしにユーザーが制御できる入力をNoSQLデータベースへ渡す、あらゆるアプリケーションに影響します. 確認されたCVEの証拠に基づくと、特に影響を受けやすいアプリケーションのカテゴリは次のとおりです:

• 認証システム: ログインエンドポイントは、主要な情報源すべてで記録されている典型的な攻撃対象領域です.
• チームコラボレーションプラットフォーム: Rocket.Chatでは、認証前に悪用可能な脆弱性 (CVE-2021-22911) を含め、数年にわたり複数のNoSQLインジェクションのCVEが確認されています.
• Mongooseを使用するNode.js/Expressアプリケーション: オブジェクトドキュメントマッパー(ODM)であるMongooseは、MongoDB自体の制御とは別に、ORMレイヤーにインジェクションの攻撃経路を生み出します.
• Platform-as-a-Serviceのバックエンド: Parse Server (CVE-2022-24815, CVE-2026-30941)とSteedos Platform (CVE-2020-35666)は、Backend-as-a-Service製品にもリスクがあることを示しています.
• IoTとネットワーク管理: UbiquitiのUniFi Network Applicationには、権限昇格を可能にするNoSQLインジェクションのCVEがベンダーによって確認されています.
• Eコマースプラットフォーム: AquilaCMSのパスワードリセット機能におけるNoSQLインジェクションは、CRITICALと評価されました(CVE-2024-48573).
• GraphQL API: サニタイズされていないGraphQLのフィルター引数をMongoDBクエリに直接展開すると、見落とされがちなインジェクションの攻撃経路が生まれます.

MongoDBは広く利用されており、Node.js/Expressもバックエンド開発で広く採用されています. この組み合わせは広範な攻撃対象領域を生み出します. NIST IR 8504 はNoSQLインジェクションを米国政府のシステムにおけるリスクの一種として正式に文書化しています. このリスクはスタートアップやSaaS環境だけでなく、エンタープライズにも及びます.

GraphQL APIは、明示的な許可リストを使わずにフィルター引数をMongoDBクエリへ直接展開することが多く、ますます一般的な攻撃経路となっています. また、このパターンはSQL形式のペイロードに重点を置く従来の従来の Webアプリケーションファイアウォール(WAF) のルールでは十分に検出されません.

共通するのは業種ではなく、技術スタックです. MongoDB, Redis, CouchDB, Elasticsearchのいずれかをユーザー入力と組み合わせて使用している場合、アプリケーションは攻撃対象になり得ます. 特に、自動型変換を行うJavaScriptフレームワーク上で構築している場合は注意が必要です. 以下の確認済みインシデントは、実際の悪用例を示しています.

実際の事例

確認済みのCVEと公開された攻撃チェーンは、コラボレーションプラットフォーム, Eコマース, Backend-as-a-Service製品, ネットワークインフラの本番システムでNoSQLインジェクションがどう悪用されるかを示しています.

Rocket.Chat: 認証前の管理者アカウント乗っ取り(CVE-2021-22911)

SonarSourceの調査 では、Rocket.Chatの getPasswordPolicy() メソッドが認証なしで呼び出せることが示されました. 攻撃者はMongoDBの $regex 演算子をパスワードリセットトークンのパラメーターに注入し、{"$regex":"^A"} を送信して応答の違いを観察することで、トークンを1文字ずつ抽出できました.

確認済みの HackerOneレポート は攻撃チェーンを示しています: 管理者のユーザー名, メールアドレス, パスワードハッシュ, リセットトークンが漏洩し、最終的に管理者アカウントが完全に乗っ取られました.

@feathersjs/mongodb: WebSocket経由のオブジェクトインジェクション(CVE-2026-29793)

Socket.IOクライアントは、任意のJavaScriptオブジェクトをFeathersの各サービスメソッドの id 引数として送信できました. トランスポート層では型チェックが行われていませんでした. {$ne: null} を id として送信すると、コレクション内のすべてのドキュメントが一致しました. この脆弱性は CVE-2026-29793.

Ubiquiti UniFi: 認証済みユーザーによる権限昇格(CVE-2026-22557)

Ubiquitiは自社のアドバイザリで、UniFi Network Applicationに認証済みユーザーが悪用できるNoSQLインジェクションの脆弱性があり、 権限昇格 が可能になると確認しました. 認証済みのユーザーなら誰でもこの脆弱性を悪用して権限を高め、低権限のアカウントからネットワークインフラの完全な管理権限を得ることができました.

Rocket.Chat Livechat: 連鎖するインジェクション(CVE-2024-37405)

異なる2つのNoSQLインジェクションの侵入口が 連鎖的に利用されました。まず、$regex を使ったブラインドインジェクションで訪問者トークンを抽出し、続いて rid パラメーターへの2回目のインジェクションでLivechatの全メッセージを抽出しました。この認証前の攻撃により、顧客とのコミュニケーションデータが漏えいしました。

AquilaCMS：パスワードリセット機能に重大なインジェクションの脆弱性（CVE-2024-48573）

AquilaCMS, オープンソースのeコマースプラットフォームであり、パスワードリセット機能のNoSQLインジェクション脆弱性が緊急 (9.8)と評価されました。認証を受けていない攻撃者は、リセットトークンのパラメータにMongoDBの演算子を注入し、パスワードリセットの処理を操作して、意図された検証ロジックを完全に回避できました。AquilaCMSはeコマースサイトを支えているため、悪用に成功すると、顧客のアカウントデータ、決済情報、注文履歴が危険にさらされました。この脆弱性は認証なしで悪用でき、標準的なHTTPリクエストを通じてリモートから攻撃できるため、サイトにネットワーク経由でアクセスできる攻撃者なら誰でも悪用できました。

Parse Server：繰り返し発見されたインジェクションの脆弱性（CVE-2022-24815、CVE-2026-30941）

Parse Serverは、広く使われているオープンソースのBackend-as-a-Serviceプラットフォームです。複数年にわたり、NoSQLインジェクションの脆弱性が繰り返し見つかっています。 CVE-2022-24815 では、プロトタイプ汚染とNoSQLインジェクションが組み合わされていました。JavaScript層の脆弱性とデータベースインジェクションが重なることで、どちらか一方だけでは成立しない攻撃経路が生まれることを示しています。数年後には、 CVE-2026-30941 により、トークンの値が型検証なしでデータベースクエリに渡される箇所が、プラットフォームに残っていたことが明らかになりました。Backend-as-a-Service製品は、1つの脆弱性がそのプラットフォーム上に構築されたすべてのアプリケーションに影響するため、価値の高い攻撃対象です。Parse Serverが侵害されると、それに依存するモバイルアプリ、Webアプリケーション、IoTバックエンドも同じリスクにさらされます。

これらの事例は、複数年にわたり、さまざまな技術スタックで発生しています。NoSQLインジェクションは本番システムで繰り返し表面化しており、年表からはこの問題が長く続いていることがわかります。

NoSQLインジェクションの年表

2026年にCVEが相次いだことは、Node.js/MongoDBスタックに対する研究者の関心が高まっていることを示しています。NoSQLインジェクションへの注目は薄れるどころか、再び高まっている可能性があります。この動向を踏まえると、検知は優先課題です。幸い、検知の手がかりは十分に把握されています。

NoSQLインジェクションを検知する方法

NoSQLインジェクションを見つけるには、静的コード解析、稼働中のエンドポイントに対する動的テスト、ほかの対策が見逃した悪用を捉える実行時の振る舞い監視を組み合わせる必要があります。

静的解析とコードレビュー

コードベースを調査し、リスクの高いパターンを特定します。Mongooseの .find(), .findOne(), または .populate() の呼び出しで、型の検証を行わずに req.body, req.query, または req.params を直接渡している箇所を確認します. ユーザーが制御できる入力を $where に使用している箇所、ユーザーが制御できるフィルターオブジェクトを組み込んだ集約パイプライン、クライアントから生のJSONクエリオブジェクトを受け付けるエンドポイントを探します. さらに、eval(), Function() の使用や、ユーザー入力をクエリ文字列に連結するテンプレートリテラルも確認対象にします. $lookup または $unionWith を使用する集約パイプラインで、ユーザーが制御できるコレクション名やパイプラインステージを扱う場合は、特に詳しく調べる必要があります. コレクション単位のアクセス境界を越える可能性があるためです.

動的テスト

次の OWASP WSTG-INPV-05.6 の手法に従います:

1. 構文インジェクションの挿入箇所を特定するため、ファズ文字列 '"\{ ;$Foo} $Foo \xYZ` を送信します.
2. 演算子インジェクションの挿入箇所を特定するため、特殊文字 ' " \ ; { } を送信します.
3. HTTPパラメータ汚染を利用して $where パラメータを挿入し、MongoDBのエラーレスポンスを確認します.
4. 真になることがわかっている条件と偽になることがわかっている条件でレスポンスの違いを調べ、ブラインドインジェクションを検出します.

WebSocketチャネルも個別にテストしてください. CVE-2026-29793 では、Socket.IOクライアントが任意のJavaScriptオブジェクトをサービスメソッドの引数として送信し、HTTPレイヤーの検査をすべて回避できることが示されました. 多くのスキャナーはHTTPエンドポイントだけを対象とし、WebSocketのインジェクション経路を完全に見逃します. 手動または専用のWebSocketテストにより、リアルタイム通信フレームワークを使用するアプリケーションでこの検査の抜けを解消します.

実行時の振る舞いの監視

攻撃が成功したことを示す振る舞いの兆候がないか、インフラストラクチャを監視します:

• データベースサービスのプロセス（mongod、redis-server）から予期しない子プロセスやシェルが起動する
• MongoDBの演算子構文を含む異常なクエリパターン ($where, $regex, $ne, $gt) がアプリケーションログに記録されている
• 正規のクエリ負荷が増えていないにもかかわらず、MongoDBサーバーのCPU使用率が急増している
• パスワードリセット用のエンドポイントで、トークンフィールドに文字列ではなくオブジェクトが渡されている
• タイミングベースのブラインドインジェクションを示唆する、公開エンドポイントでの応答時間の差

ペネトレーションテストツール

専用ツールを使い、評価時にNoSQLインジェクションの有無を調査します:

• NoSQLMap: NoSQLインジェクションのテストと悪用に特化したオープンソースツール
• nosqli: NoSQLインジェクションを自動検出するコマンドラインツール
• Burp Suite: RepeaterとIntruderモジュールによる手動テスト。拡張機能を使ったNoSQLペイロードの自動テストにも対応
• OWASP ZAP: NoSQLエンドポイントに適用できるアクティブスキャンルール

調査すべき箇所を知ることが、課題の半分です。もう半分は、悪用を未然に防ぐ対策を構築することです.

NoSQLインジェクションを防ぐ方法

NoSQLインジェクション対策は、ユーザー入力がデータベース層に届く前に厳密な型チェックを適用することから始まります。以下の対策は、フレームワーク層での型変換からORM層のバイパスまで、先に挙げた根本原因に対応します.

クエリ構築前に型チェックを適用する

ORMやデータベースドライバーに渡す前に、スカラー値（文字列、数値、真偽値）ではない入力フィールドを拒否します。明示的な型変換が最も効果的な対策です:

MongoDBの演算子キーを除去または拒否する

req.body、req.query、およびreq.params のすべてのキーに$ プレフィックスが付いていないか確認し、データベース層に届く前に拒否します。正規表現ではなくkey.startsWith('$') で確認してください。CVE-2021-22910で報告されているとおり、正規表現には既知のバイパス手法があります.

サーバーサイドJavaScriptを無効にする

MongoDBの設定で--noscriptingを使用するか、set security.javascriptEnabled: falseに設定します。これにより$where の攻撃対象領域を完全に排除できます。条件付きロジックには$expr と型付きクエリビルダーを優先して使用してください.

スキーマ検証フレームワークを使用する

Joi、Ajv、Zodなどのライブラリを使用し、リクエスト処理の早い段階でデータ型を検証します。スカラー値が必要な箇所では配列やオブジェクトを拒否し、データベースに到達する前に演算子インジェクションを阻止します。

MongooseとORMのバージョンを固定し、セキュリティ情報を監視する

ORM層の脆弱性は、アプリケーションとデータベースの両方の制御を完全に回避する可能性があります。 CVE-2024-53900 と CVE-2025-23061 は、MongoDBのサーバー側JavaScriptを無効にしていても、Mongooseの populate().match 機能が悪用され得ることを示しました。CVE-2025-23061はCVE-2024-53900の修正が不完全だったことに起因します。パッチだけでは不十分な場合があり、独立した検証が必要です。

Mongooseやその他のODM/ORMライブラリのセキュリティ情報を購読し、依存関係のバージョンを明示的に固定してください。修復チケットをクローズする前に、各セキュリティパッチが報告された脆弱性を完全に解消していることを検証してください。

クライアントからの生のJSONクエリを受け付けない

この OWASPチートシート には「クライアントからの生のJSONクエリを受け付けないでください」と明記されています。クライアントから { "$where": "this.balance > 0" } のようなペイロードが送信されると、リモートコード実行やCPUリソースの枯渇につながります。

最小権限でデータベースを構成する

権限を最小限に抑えた専用のアプリケーション用データベースアカウントを使用してください。rootやadminの認証情報では接続しないでください。データベースのポートや管理コンソールを公開インターネットにさらさないでください。

ワイヤーオブジェクトチェックを有効に保つ

MongoDBの net.wireObjectCheck 設定は、ワイヤープロトコルレベルですべてのドキュメントを検証します。デフォルトで有効になっています。無効にしないでください。

GraphQLフィルターを保護する

GraphQLのフィルター引数は、明示的な許可リストに基づいて変換してください。信頼できないオブジェクトをMongoDBやMongooseのクエリフィルターに直接展開しないでください。

強力なアプリケーションレベルの制御は、攻撃対象領域を縮小します。ただし、完全には排除できません。すり抜けた脅威には、多層的な検知と対応で対処します。

検知と防止のためのツール

NoSQLインジェクションに対する多層防御には、アプリケーションレベルの制御、テストツール、ランタイム監視を組み合わせます。

• アプリケーション層 の防御には、入力検証ライブラリ（Joi、Ajv、Zod）、ORMレベルの保護策（Mongooseのスキーマ検証、明示的な型変換）、MongoDBに組み込まれたセキュリティ制御 (--noscripting, wireObjectCheck, ロールベースのアクセス制御)が含まれます。
• テストツール であるNoSQLMap、nosqli、Burp Suite、OWASP ZAPを使用し、開発時や ペネトレーションテスト のサイクルでNoSQLインジェクションを検査します。
• WAF は境界防御層として、既知のインジェクションパターンをブロックします。ただし、WAF はシグネチャベースのルールで動作するため、未知のペイロード、難読化された演算子、WebSocketチャネル経由のインジェクションは阻止できません。
• ランタイムでの振る舞い監視 は、WAFが残す防御の隙間を埋めます。新しいペイロード、Mongooseの populate().match の問題のようなORM層の脆弱性、WAFが検査しないWebSocketチャネルを通じて、アプリケーション層の制御が回避される場合があります。ランタイム監視は、ペイロードの送信経路にかかわらず、インジェクションが成功した後の影響を捉えます。たとえば、データベースプロセスによる予期しないシェルの起動、異常なJavaScript実行パターン、異常なクエリ量です。インジェクションのペイロードがシグネチャベースの検査をすり抜けてデータベースに到達した場合、結果として生じる異常な振る舞いが侵害を示す最も信頼できる兆候となります。

SentinelOneはどう役立つか

ペイロードの検査はWAFの役割です。SentinelOneはその先を監視します。NoSQLインジェクションが成功した後に生じるプロセスの異常、ラテラルムーブメント、悪用後の活動など、アプリケーション層の制御では見逃す振る舞いを検知し、阻止します。

SentinelOneの Singularity™ Platform には Singularity AI SIEM, エンドポイント、クラウドワークロード、IDシステム、サードパーティのソースから得たテレメトリを、単一のデータレイクで相関分析します。2024年のMITRE ATT&CK Evaluationsで、Singularity Platformは遅延ゼロで100%の検知率を達成し、アラート数を中央値より88%削減しました。ノイズが減れば、セキュリティチームは確認済みの脅威に集中できます。NoSQLインジェクション攻撃がWebアプリケーションからデータベースサーバー、認証情報の窃取へと連鎖しても、AI SIEMは手動で相関分析することなく、各領域のイベントを結び付けます。

Singularity Endpointでは、 Storyline テクノロジーが、保護対象の各エンドポイントで発生するプロセスの作成、ネットワーク接続、ファイルの変更、認証情報の使用を継続的に関連付け、一連の経緯を示すチェーンにまとめます。 $whereを利用したサーバー側JavaScript実行攻撃では、Storylineが、悪意あるリクエストを受け取ったWebサーバープロセス、異常な動作を示すデータベースサービス、そこから起動されたインタープリタープロセス、子シェルを自律的に関連付けます。これらはすべて単一のStoryline IDでつながります。Storyline Active Response (STAR)のカスタムルールは、 mongod や redis-server などのデータベースプロセスが予期しない子プロセスを起動すると発動します。これは、コマンドインジェクションの成功を示す確度の高い振る舞い指標です。

Purple AI™ 自然言語によるクエリで調査を加速します。IDCによると、Purple AIを利用する顧客は脅威の特定時間を63%短縮し、平均修復時間（MTTR）を55%短縮しています。「過去24時間にmongodが起動したすべてのプロセスを表示して」と質問したり、T1190（Exploit Public-Facing Application）やT1059（Command and Scripting Interpreter）などのMITRE ATT&CKの技術を直接指定したりできます。Purple AIのAuto Investigation機能は、スタック全体から証拠を自律的に収集し、脅威データを統合して攻撃の全容を時系列で示します。これにより、以前は数時間かかっていた調査が数分で完了します。

Cloud Workload Security はクラウドでホストされるNoSQLデータベースを実行時に保護します。ワークロードの振る舞いをリアルタイムで監視し、Verified Exploit Pathsを使用して証拠に基づく検出結果を明らかにします。クラウドでホストされるMongoDBやRedisのインスタンスに対するNoSQLインジェクションが、侵害後の活動につながったことを把握できます。

NoSQLデータベースを大規模に運用する組織は、これらの機能によって、アプリケーションレベルの防御と侵害後の活動の可視化の間にあるギャップを解消できます。 

SentinelOneのデモをリクエスト して、これらの機能の動作をご確認ください。

関連する脆弱性

NoSQLインジェクションは、次の関連する脆弱性クラスと根本原因や攻撃パターンが共通しています。

• SQLインジェクション (CWE-89)： リレーショナルデータベースにおける同種の脆弱性です。どちらもデータベースクエリ内でユーザー入力が適切に無害化されていないことを悪用します。ただし、NoSQLインジェクションでは手続き型言語を実行できるため、影響はデータの操作にとどまらず、任意のコードの実行に及びます。
• サーバーサイドリクエストフォージェリ (SSRF)： RedisのCRLFインジェクションは、SSRFと組み合わせて使われることがよくあります。攻撃者はSSRFを使って内部のRedisインスタンスに到達し、CRLFシーケンスを介して便乗させたコマンドを注入します。
• コマンドインジェクション (CWE-78)： NoSQLインジェクションによって $where を介したサーバー側JavaScriptの実行が可能になると、その能力はOSコマンドインジェクションに非常に近いものになります。
• プロトタイプ汚染： CVE-2022-24815 は、Parse Serverでプロトタイプ汚染とNoSQLインジェクションを組み合わせた脆弱性です。JavaScript層の脆弱性がデータベースへのインジェクションと重なり、影響を増幅することを示しています。
• クロスサイトスクリプティング (XSS)：XSSとNoSQLインジェクションは、いずれも入力検証の不足に起因します。一方に脆弱な組織では、検証の仕組みに共通する弱点があり、もう一方にもさらされていることがよくあります。

こうした関係を理解すれば、各脆弱性を個別に扱うのではなく、関連する脆弱性クラス全体でテストと修正の優先順位を付けられます。以下の表に、参考として確認済みのNoSQLインジェクションのCVEを示します。