Coders Conquer Security: シェア＆ラーンシリーズ - NoSQLインジェクション

NoSQLデータベースはますます人気が高まっています。特にアジャイル開発手法を採用するチームにとって、非構造化データを扱う際のスピードと手軽さは否定できません。

開発者が新しい技術の脆弱性や課題を洗い出すには時間がかかります。本番環境で一定期間運用されて初めて、問題が表面化し始めるのです。

NoSQLデータベースも同様です。開発者がアプリケーションの安全を守るために知っておくべき重要なリスクがあり、その一つがNoSQLインジェクションです。

NoSQLインジェクションとは何か、どのような被害をもたらすのか、そしてどう対処すべきかを見ていきましょう。

NoSQLインジェクションを理解する

NoSQLインジェクションは、XMLやSQLインジェクションといった、多くのインジェクション脆弱性と共通の要因で発生します。

NoSQLインジェクションにより、攻撃者はNoSQLクエリに任意のコマンドを挿入できるようになります。これにより、データの窃取が可能になるだけでなく、十分な権限があればデータベースの改ざんまで行われてしまいます。

アプリケーションがユーザー入力データを直接NoSQLクエリ式に組み込むと、クエリが持つ関数や組み込み演算子が操作され、データの窃取や改ざんを許してしまうことがあります。悪意を持って実行された場合、その結果は壊滅的なものになりかねません。

MongoDBは、この脆弱性を突く攻撃の標的として最も人気のあるデータベースの一つです。「$ne: ""」はSQLにおける「1=1」に相当する演算子です。例えば、攻撃者がユーザー名やパスワードの入力欄に「$ne: ""」という文字列を入力したとします。もしそのコードがNoSQLインジェクションに対して脆弱であれば、データベースは「ユーザー名とパスワードが空文字ではない」すべてのレコードを検索してしまいます。つまり、全件抽出されてしまうのです。恐ろしいことです。

もしデータベースが暗号化されていなければ、攻撃者はすべてのユーザーのユーザー名とパスワードを盗み出すことができます。これには管理者アカウントも含まれるため、データベース全体へのフルアクセス権を奪われることになります。

攻撃者は、常に真（true）となる値を渡そうとすることがよくあります。また、関数として設定されたプロパティに悪意のあるコードを注入する攻撃も一般的です。

例えば、MongoDBのfind関数は、$whereプロパティを持つオブジェクトを受け取ります。$whereプロパティには、真偽値を返す関数が設定されます。もしこの関数がユーザー入力によって何らかの形で変更されてしまうと、そこにNoSQLインジェクションの脆弱性が潜んでいる可能性が高いと言えます。

NoSQLインジェクションの複雑な仕組みについて詳しく知りたい方は、こちらのInfoQの記事をご覧ください。

NoSQLインジェクションが危険な理由を知る

NoSQLインジェクションが危険な最大の理由は、セキュリティコミュニティにおいて、本来受けるべき精査がまだ十分になされていない点にあります。

NoSQLインジェクションの影響は、従来のSQLインジェクションとほぼ同じです。データの窃取や改ざん、アカウントの乗っ取りが行われるほか、最悪の場合、削除コマンドが実行されてデータが完全に消去される恐れもあります。

結論として、MongoDBをはじめとするNoSQLデータベースエンジンは攻撃に対して脆弱です。「No SQL」だからといって「No Injection（インジェクションがない）」というわけではありません。
幸いなことに、コミュニティの一部ではこの問題が認識され、注意喚起が行われています。開発者は、悪用されると大きな災いとなるこうしたあまり知られていない脅威からアプリケーションを守るため、知識を深める必要があります。

NoSQLインジェクションを阻止する

NoSQLインジェクションへの対策は困難な場合があります。SQLインジェクションのようなパラメータ化クエリという選択肢がないためです。しかし、不可能ではありません。いくつかの対策方法をご紹介します。

• 脆弱性を検出する手法の一つとしてファザー（Fuzzer）が利用できます。しかし、多くの物事がそうであるように、最もシンプルなアプローチが最も効果的です。ここでは、昔ながらのコードレビューが最強の味方となります。
• コードレビューを行う際は、ユーザー入力が式の値を設定したり、関数を変更したりする可能性のある箇所を探してください。ユーザー入力によってクエリが変更されないようにしましょう。
• ユーザー入力は必ず適切なクラスにキャストしてください。数値であれば数値型に、文字列であれば文字列型にキャストするといった具合です。
• ユーザー入力を含む箇所で、$whereやそれに類するeval関数は絶対に使用しないでください。ほとんどの場合、データモデルやスキーマを変更することで回避可能です。
• MongoDBのドライバーとしてMongooseの使用を検討してください。Mongooseを使えば、NoSQLデータベースのスキーマを定義できます。入力値が文字列であることをMongooseに指定すれば、それらは文字列としてキャストされます。そのため、攻撃者がオブジェクトを渡しても、オブジェクトとしてではなく文字列として扱われるようになります。
• データベースを強化しましょう！権限の低いユーザーアカウントを作成し、クエリの実行時間を制限し、組織に適用されるセキュリティのベストプラクティスを常に遵守してください。

NoSQLデータベースの利便性の裏には、開発者がセキュリティを考慮せずに導入・利用し始めてしまうという欠点があります。

NoSQLデータベースを安全に構築し、NoSQLインジェクションから身を守る方法を時間をかけて学ぶことが不可欠です。

例えば、MongoDB Enterprise Editionには、ドキュメントに対する高度なアクセス制御機能があります。「最小権限の原則」を徹底することは、万が一アプリケーションに脆弱性が見つかった場合の多層防御（DiD）戦略として有効です。

まとめると、以下の通りです。

• NoSQLクエリ式で使用する前に、入力をサニタイズする
• Mongooseのようにサポート機能を持つドライバーを使用する
• クエリ内で入力データがどのように使用されているかを重点的に確認するコードレビューを行う
• ファザーやスキャナーを使用して、コード内の脆弱性発見に役立てる

NoSQLは「No Injection（インジェクションなし）」ではありません

NoSQLデータベースは、その拡張性とセットアップの容易さから急速に普及しています。新しい技術であるため、開発者がセキュリティ対策を考慮せずに導入してしまうケースが見受けられます。

NoSQLデータベースもSQLデータベースと同様にインジェクション攻撃に対して脆弱である可能性があるため、注意を払い、クエリには細心の注意を払ってください。詳細については、当社の学習リソースをご覧いただくか、無料デモでスキルを試してみてください。

事前に備えておけば、アプリケーションのNoSQLインジェクションを心配する必要はありません。とても簡単です！

NoSQLインジェクションを見つけ、特定し、修正する準備はできましたか？セキュアコードアリーナへようこそ、戦士よ。

2018年はこれで締めくくりです！これが今年最後の投稿となりますが、次回の「Coders Conquer Security」ガイドは2019年1月10日に公開予定です。またお会いしましょう！