NoSQLデータベースの人気はますます高まっています。特に、開発チームがアジャイルな方法論に基づいて作業している場合には、非構造化データを扱う際のスピードと容易さを否定することはできません。

開発者が新技術の脆弱性やその他の課題を解決するには時間がかかります。本番環境での使用期間が長くなって初めて、問題が表面化します。

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

ここでは、NoSQLインジェクションとは何か、どのような被害をもたらすのか、そしてどのように修正するのかを見ていきましょう。

NoSQLインジェクションの理解

NoSQLインジェクションは、XMLインジェクションやSQLインジェクションなどのインジェクション脆弱性と同じものが多く存在します。

NoSQL インジェクションにより、攻撃者は NoSQL クエリに任意のコマンドを入れることができます。これにより、データを盗んだり、権限が十分に高ければデータベースに変更を加えたりすることができます。

アプリケーションがユーザが制御するデータを直接NoSQLクエリ式に配置する場合、これらの式は多くの場合、データを盗んだり変更したりするために操作可能な関数を取ったり、組み込みの演算子を持っています。そして、そのようなことが悪意を持って実行された場合、悲惨な結果になる可能性があります。

MongoDBデータベースは、この脆弱性を悪用する最も一般的な遊び場の一つです。"$ne:""'は、SQLの世界では1=1に相当する演算子なので、例を挙げると、攻撃者は"$ne:""'をUIのユーザー名とパスワードのフィールドに入れることができます。もしそのコードがNoSQLインジェクションに脆弱であれば、データベースはユーザー名とパスワードが空の文字列に等しくないすべてのレコードを検索します。言い換えれば、全部です。やべぇ。

このデータベースが暗号化されていなければ、攻撃者はデータベース内のすべてのユーザーのユーザー名とパスワードを盗むことができます。これには管理者のユーザー名とパスワードも含まれ、データベース全体にアクセスできるようになります。

攻撃者はしばしば、常に真である値をパスインしようとします。また、関数に設定されているプロパティに悪意のあるコードを注入する攻撃もよく行われます。

たとえば、MongoDB の find 関数は $where というプロパティを持つオブジェクトを受け取ります。where プロパティには、true または false に評価されるべき関数が設定されています。ユーザーの入力によってこの関数が何らかの形で変更された場合、NoSQLインジェクションが潜んでいる可能性があります。

NoSQLインジェクションの複雑な仕組みについては、InfoQの記事をご覧ください。

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

NoSQLへのインジェクションが危険なのは、それに見合うだけの精査がセキュリティコミュニティからまだ受けられていないからです。

NoSQLインジェクションの影響は、従来のSQLインジェクションとほぼ同じです。データが盗まれたり変更されたり、データを盗むことでアカウントが侵害されたり、おそらく最も悪質なのは、削除コマンドが正常に発行された場合、データが完全に消去されてしまうことです。

要するに、MongoDBやその他のNoSQLデータベースエンジンは攻撃されやすいということです。"
ありがたいことに、コミュニティの中には注意を促している人もいます。しかし、より多くの開発者が自分たちのアプリケーションを、悪用されると大きな頭痛の種になるような、あまり知られていない厄介なものから守れるよう、自らを教育する必要があります。

NoSQLインジェクションを倒す

NoSQLインジェクションを撃退するのは困難です。残念ながら、SQLインジェクションのようにパラメータ化されたクエリという選択肢はありません。しかし、不可能ではありません。いくつかのオプションがありますので、参考にしてみてください。

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

NoSQLデータベースの使いやすさの欠点は、開発者がセキュリティを考えずに立ち上げて使い始める傾向があることです。

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

例えば、MongoDB Enterprise Editionには、ドキュメントに対する高度なアクセスコントロール機能があります。最小限の特権」を行使することは、万が一、アプリケーションに脆弱性が見つかった場合に備えたDiD（Defense in Depth）戦略として有効です。

まとめますと、以下のようになります。

• NoSQLのクエリ式で使用する前に入力をサニタイズする
• マングースのように、あなたを助けてくれるドライバーを使う
• クエリの中で入力データがどのように使用されているかを具体的に調べるコードレビューの実施
• ファザーやスキャナーを使って、コードの脆弱性を見つけることができます。

NoSQLはNo Injectionsではない

NoSQL データベースは、そのスケーラブルな機能とセットアップの速さから、急速に人気を集めています。しかし、その新しさゆえに、開発者はセキュリティ対策を考えずにNoSQLデータベースを使ってしまうことがあります。

NoSQLデータベースは、SQLデータベースと同様にインジェクション攻撃に対して脆弱な場合がありますので、慎重に行動し、クエリに注意を払ってください。さらに詳しく知りたい方は、ラーニングリソースをご覧いただくか、無料デモでスキルをお試しください。

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

今すぐNoSQLインジェクションを見つけ、特定し、修正する準備ができていると思いますか？セキュアコードの世界に飛び込んでみませんか？

これで2018年は終わりです。これが今年最後の記事となりますが、次回のCoders Conquer Securityガイドは2019年1月10日にお届けします。それでは、またお会いしましょう