NoSQL Injection: SQLからの移行がインジェクションからの解放を意味しない🍃

データベース技術の進化に伴い、多くの組織が柔軟性、スケーラビリティ、パフォーマンスの利点からNoSQLデータベースを採用しています。MongoDB、Cassandra、RedisなどのNoSQLソリューションは、ソーシャルメディアプラットフォームからIoTシステムまで、現代アプリケーションの基盤となっています。しかし、開発者の間には誤った認識も根強くあります：NoSQLデータベースは本質的にインジェクション攻撃に免疫であるという考えです。この誤った安心感は、新たな脆弱性の景観を生み出し、攻撃者によってますます悪用されています。

NoSQLセキュリティの誤信念

NoSQLデータベースはインジェクション攻撃に免疫であるという考えは誤りですが、この誤解は多くのアプリケーションを危険にさらし続けています。開発者が従来のSQLデータベースからNoSQLに移行する際、多くはインジェクションの脆弱性を克服したと考えがちです。実際は、もっと複雑で深刻な問題があります。

NoSQLインジェクションは、クエリの形成過程における脆弱性を悪用し、攻撃者が不安全なクエリを操作して認証を回避したりデータを盗んだりする攻撃です。根本的な問題はSQLインジェクションと同じく、未検証のユーザー入力をデータベースクエリに直接連結させることにあります。

NoSQLインジェクションの脆弱性理解

NoSQLの違いは何か？

SQLデータベースでは、SELECTやINSERTといったSQLクエリに基づくインジェクションが一般的ですが、NoSQLデータベースは各タイプに特化したクエリ言語を使用します。この多様性は、NoSQLのセキュリティ確保に一つのアプローチがないことを意味し、プラットフォームごとに構文や演算子、攻撃の可能性が異なります。

NoSQLは標準化されたクエリ言語を持たず、MongoDB、Cassandra、Redis、Google Bigtableなど、各エンジンによって許可されるクエリも異なります。このため、開発者は選択したデータベースのセキュリティ上の特性を理解する必要があります。

NoSQLインジェクションの主な2つの形態

主に2つのタイプがあります：構文インジェクションと演算子インジェクションです。

構文インジェクションは、攻撃者がクエリの構文を破壊し、自身のペイロードを挿入するものです。潜在的なインジェクションポイントを特定するには、現在の構文を崩したり演算子を挿入したりし、その反応の変化（内容長やステータスコード、レスポンスヘッダーの違い）を観察します。

演算子インジェクションは、NoSQLデータベース特有のクエリ演算子を悪用します。MongoDBでは、例えば $ne（not equal）、$gt（greater than）、$where などの演算子を操作してクエリのロジックを変更し、セキュリティ制御を回避します。

実世界の攻撃シナリオ

認証バイパス：定番の攻撃

最も一般的で危険なNoSQLインジェクションの一つは、認証メカニズムを回避する攻撃です。典型的なログイン関数例：

Users.findOne({
  "name": req.body.name,
  "password": req.body.password
});

この例では、ユーザ名パラメータはJSONからデシリアライズされた値です。攻撃者はMongoDBのクエリ演算子を挿入し、クエリを操作してログインを回避できます。

例えば、攻撃者は次のような値を送信します：

{
  "name": {"$ne": "1"},
  "password": {"$ne": "1"}
}

この $ne（not equal）演算子は、「名前」と「パスワード」が文字列「1」と異なる最初のユーザを見つけるために使われます。条件はほぼ常に真となるため、攻撃者は認証を突破し、システムにアクセスします—通常は最初のユーザ（しばしば管理者アカウント）として。

特定アカウントの侵害

特定のアカウントを狙う場合、既知のユーザ名や推測したユーザ名を含むペイロードを作成できます。例として、$in演算子と一般的な管理者ユーザ名を使う方法があります。これにより、正当な資格情報なしで高価値アカウントを狙えます。

JavaScriptインジェクションによるデータ抽出

多くのNoSQLデータベースでは、$where演算子のように限定的なJavaScriptコードを実行できる場合があります。これにより、より高度な攻撃の機会が生まれます。

$whereを使った攻撃では、条件に一致した場合に遅延を引き起こすJavaScriptコードを挿入し、ブラインドデータ抽出を可能にします。パスワードや機密フィールドの各文字を順次テストし、応答時間を測定することで、攻撃者はデータセットを文字単位で抽出できます。

セカンドオーダーインジェクション

セカンドオーダーNoSQLインジェクションは、未検証の入力をアプリケーションに注入し、保存された後に不安全なクエリとして実行される攻撃です。これらは、即時の入力処理を回避し、後から実行されるため、非常に巧妙です。

なぜNoSQLインジェクションはより危険か

一部のNoSQLデータベースはアプリケーションコードをクエリに利用しており、攻撃者は望ましくない操作だけでなく、悪意のあるコードや未検証の入力をアプリ内で実行することも可能です。これにより、従来のSQLインジェクションよりも深刻なリスクとなる場合があります。

NoSQLインジェクションは、動的スキーマを持つNoSQLデータベースをターゲットにしやすく、攻撃の脆弱性が高まります。柔軟性は開発に便利ですが、攻撃面も増加します。

また、分散構造やセキュリティ制御の不備により、データ漏洩のリスクも高まります。

現在の脅威の状況

NoSQLインジェクションは従来のSQLインジェクションよりも容易に悪用できる反面、多くの開発者はこれらの脆弱性に気づいていません。容易さと認識不足の組み合わせが、NoSQLインジェクションの重大な懸念となっています。

400以上のNoSQLインジェクションコマンドが記録されており、その中には221の悪意あるコマンドと179の安全なコマンドが含まれ、攻撃手法の多様性と高度さを示しています。

OWASP Top 10の「Injection」カテゴリーにもNoSQL Injectionが含まれており、その重要性が認識されています。

包括的な防御戦略

入力検証とサニタイズ

ユーザー入力を体系的に検証し、信頼しないことが基本です。入力前に期待通りの形式かどうかを確認し、脆弱性の可能性を排除します。特に、シングルクォートやダブルクォート、ブラケット、データベース固有の演算子などをテストします。

パラメータ化クエリと安全なAPIの利用

プリペアドステートメントの使用を推奨します。これにより、データとコマンドを分離し、インジェクションを防止します。各パラメータは危険な文字や演算子を含まないか慎重に確認します。

MongoDBの場合は、JavaScript実行を必要としない安全なクエリビルド機能を利用し、$whereのような演算子は必要最小限に留め、使用時は厳格な入力検証を行います。

型検証の実施

ユーザーデータの型を検証し、オブジェクトや配列などの意図しない構造を排除します。これにより、NoSQL修飾子の注入を防ぎます。

最小権限の原則

アプリケーションのアクセス権を最小限に抑えることが重要です。データベースの操作に必要な最小権限だけを付与し、攻撃成功時の被害を抑えます。

ホワイトリストとブラックリストの設定

許可されたデータフィールドのホワイトリストを設定します。すべての悪意ある入力を検知し排除するブラックリスト方式よりも、正当な入力のパターンを明確に定義し、それ以外を拒否します。

システムの最新化

多くのNoSQL製品は継続的に開発されているため、最新バージョンへのアップデートを怠らないことが重要です。古いバージョンには深刻なセキュリティ脆弱性が存在します。

Webアプリケーションファイアウォール（WAF）の導入

NoSQLインジェクションを検知・ブロックできるWAFを導入します。リクエストパターンを分析し、疑わしいクエリ構造を事前に遮断します。

定期的なセキュリティテスト

セキュリティ専門家による定期的なペネトレーションテストや自動スキャンを行い、脆弱性を早期に発見・対処します。

NoSQLインジェクションの脆弱性テスト

識別技術

アプリケーションが構文として解釈する文字を特定するために、個別の文字を挿入します。例：シングルクォートを送信し、構文エラーの有無を確認します。

MongoDBの例では、'"{ ;$Foo} $Foo \xYZ`のような文字列を使い、反応の変化を観察します。

ブール値ベースのテスト

脆弱性を検出したら、次はブール条件に影響を与えられるかを確認します。偽条件と真条件のリクエストを送り、応答の違いを観察します。

演算子のテスト

$ne演算子を使い、ユーザ名が無効な値と異なるすべてのユーザをクエリするなど、クエリ演算子の処理を試します。これにより脆弱性の有無を確認します。

今後の展望：セキュリティ優先の開発

NoSQLデータベースへの移行は、スケーラビリティや柔軟性、パフォーマンスの向上に大きなメリットをもたらします。ただし、その利点にはセキュリティ責任も伴います。NoSQLが「インジェクションなし」と誤解されるのは危険です。

入力検証の欠如は、データベースの種類に関わらず深刻な影響をもたらします。Webアプリ、モバイルアプリ、IoTシステムでNoSQLの普及が進むにつれ、攻撃対象も拡大しています。

開発者は、SQLと同じ厳格さでNoSQLのセキュリティに取り組む必要があります。構文の違いはセキュリティ原則の違いを意味しません。基本ルールは変わらず、「ユーザー入力を信用せず、常に検証・サニタイズし、安全なコーディングを行う」ことです。

まとめ

NoSQLインジェクションは、現代アプリケーション開発において重要なセキュリティ課題です。構文や手法は従来のSQLインジェクションと異なりますが、根底にある脆弱性—未検証のユーザー入力がデータベースクエリに影響を与える点は共通です。NoSQLが「安全」と誤信されることは、攻撃者にとって格好の標的となる危険な知識のギャップを生んでいます。

組織は、SQLからの移行がインジェクション脆弱性からの解放を意味しないことを認識し、包括的な入力検証、パラメータ化クエリの利用、最小権限の原則の適用、最新のセキュリティパッチの維持を徹底すべきです。これにより、これらの最新データベースの利点を享受しつつ、未然に攻撃を防ぐことが可能です。

アプリケーションのセキュリティは、選択したデータベース技術ではなく、実施するセキュリティ対策にかかっています。NoSQLインジェクションは防止可能です—それは、脅威を認識し、具体的な対策を講じることで実現します。