データベース
 Computer >> コンピューター >  >> プログラミング >> データベース

MongoDBでのコードインジェクション

元々は2019年3月5日に公開されました

アプリケーション開発者、データベース管理者（DBA）、またはその他の技術者の場合は、コードインジェクションを監視する必要があります。

MongoDBでのコードインジェクション

安全なクラウド環境があります。データベースアクセスがロックダウンされています。しかし、アプリケーションコードはどうですか？より安全であると考えられていますが、いいえ NoSQLiでは、注射できないという意味ではありません。 NoSQLは、他のデータベースコードと同じようにコードインジェクションの影響を受けやすい可能性があります。コードインジェクションを防止しないことは、ドアにセキュリティシステムを設置し、バックウィンドウを開いたままにするようなものです。

コードインジェクションとは何ですか？

コードインジェクションは、インジェクションされる未検証のデータです。 （または追加されて）脆弱なプログラムに組み込まれ、アプリケーションコードの形式で実行され、多くの場合、悲惨な結果になります。

SQLiは、最も一般的なタイプのインジェクションの1つであり、10年以上経った今でも、強力になっています。インジェクションの問題は、データベース言語だけに限ったことではありません。 SQLとNoSQL以外にも、XPath®、XMLパーサー、SMTPヘッダー、およびその他のコンテキストでインジェクションが発生する可能性があります。重大度に関する限り、コードインジェクションはリモートコード実行（RCE）に似ています。ゲームオーバー ペネトレーションテストの画面。

アプリケーションでNoSQLiを検出して防止することが重要です。軽減されていないインジェクションベクトルを許可すると、ユーザーベースの安全性が脅かされる可能性があり、ビジネスが終了する可能性のある信頼の喪失を表します。幸い、テーマの仕組みを理解したら、サービスのNoSQLiの脆弱性を検出して防止するための具体的な手順を実行できます。

単純なNoSQLiの例

通常、MongoDB®は、安全なBSONクエリ構築ツールを使用して構築されたバイナリJSON（BSON）データを取り込みます。ただし、場合によっては、MongoDBは、$whereなどのシリアル化されていないJSONおよびJavascript（JS）式も受け入れることができます。 演算子。SQLと同様に、$where 演算子は、NoSQLに注入される可能性があります。ただし、SQLとは異なり、NoSQL $where その条件をJSで表現します。これは、SQLが提供するものに制限されるのではなく、JSの表現力を最大限に活用して、可能なインジェクションクエリを作成できることを意味します。

このようなパブリックリポジトリのMongoDBインジェクション文字列のリストを確認すると、SQLや他の言語の同様の脆弱性に対応する、一般的なインジェクション戦略のいくつかがわかります。たとえば、従来の1 == 1を使用するものもあります。 非表示（または管理者レベル）のリソースと特権を再表示するために、クエリにtrue値を返すように強制する式：

$Where: '1 == 1'

他のスニペットは、sleep()を使用してブラインドインジェクション戦略をエミュレートします DBの速度を低下させ、巧妙に設計されたフィルターと組み合わせて機密情報を列挙できる副作用を作成する機能：

';sleep(5000); ';it=new%20Date();do{pt=new%20Date();}while(pt-it<5000);

そしてもちろん、注入されたクエリが重要な情報を直接照合して取得しようとする、単純な古いデータの抽出があります。

' && this.password.match(/.*/)//+%00

最初の例の後、残りの2つは$whereを使用しません オペレーター。 NoSQLDBを攻撃するための足がかりとして便利なJSフレーバー式は必要ありません。

NoSQLiの防止

NoSQLi耐性のあるアプリケーションアーキテクチャを構築しようとするときに追求すべきいくつかの一般的な戦略があります。それらが一般的な注射防止のアドバイスに準拠しているのは当然のことです。

MongoDB/NoSQLiも例外ではありません

一部の人々は、コードインジェクションをSQL固有であると見なし、他のコンテキストに適用されるインジェクションの原則の有効性を過小評価しています。うまくいけば、この投稿はNoSQLiがであることをあなたに納得させます 本物。これは、MongoDBと同様の投稿で十分に文書化されており、Node.jsアプリでのNoSQLインジェクションを防ぐことはできません

未検証のユーザーデータを信頼しないでください

セキュリティ上の理由から、ユーザーを信頼するべきではありません！

これはセキュリティの決まり文句として出くわすかもしれませんが、すべての入力が悪意を持って調査されることを期待しています。 $where 前の例は、$where: unvalidated_inputの行に沿って何かを実行できない理由を明確に示しています —この時点でフィルターをユーザーに公開していると思うかもしれません（十分に悪いです！）。ユーザーが未検証のデータをより大きなクエリに導入しているという事実は、ベストプラクティスとはほど遠いものです。

言語または統合の詳細に注意してください

NoSQLiは、インジェクションの影響を受けないという点では特別ではありませんが（そして、同じ種類の攻撃の多くに苦しんでいます）、NoSQLiに固有の戦略、さらには言語やコンポーネントに固有の戦略がないという意味ではありません。 aNoSQLDBの上に構築されています。顕著な例は、$where以降です。 はPHP変数として渡されるようにフォーマットされているため、PHPアプリケーション上に構築されたNoSQL DBは、これと、$whereに格納されている悪意のある文字列インジェクションのシナリオを考慮する必要があります。 。

結論

繰り返しますが、いいえ NoSQLiでは、注射できないという意味ではありません。 NoSQLは、SQL、SMTPヘッダー、XML、およびその他のコンテキストと同様に、コードインジェクションや、他の多くのテクノロジを悩ませているアプリケーションコードではない一般的な処理の落とし穴の影響を受けやすくなっています。

この投稿によって、NoSQLiとそれがビジネスにとって何を意味するのかについての理解が深まったことを願っています。これで、コードをプロセスに誘導して、コードの普及、普及、影響を少なくすることができます。アプリとホスティング環境が安全であることを確認するためにMongoDB管理のアドバイスが必要な場合、RackspaceObjectRocketは経験豊富なDBAがお手伝いします。

RackspaceDBAサービスの詳細をご覧ください。

コメントや質問をするには、[フィードバック]タブを使用します。 セールスチャットをクリックすることもできます 今すぐチャットして会話を始めましょう。


  1. MongoDBコンパスの紹介

    この投稿では、MongoDBコンパスと呼ばれるMongoDB®のGUIを紹介します。 概要 Compassを使用すると、MongoDBクエリ構文を正式に知らなくても、MongoDBデータを分析して理解できます。 Compassを使用すると、視覚的な環境でデータを探索するだけでなく、クエリのパフォーマンスを最適化し、インデックスを管理し、ドキュメントの検証を実装できます。 コンパスエディション Compassには3つの主要なエディションがあります： コンパス ：すべての機能を備えたフルバージョン。 コンパス読み取り専用 ：すべての書き込みおよび削除機能が削除された、読み取り操作に

  2. MongoDBで未使用のインデックスを検索する

    バージョン3.2以降、MongoDBはすべてのインデックスの使用統計を追跡します。これらの統計にアクセスするために、MongoDBは$indexStats集約パイプラインステージを提供します。 MongoDBで未使用のインデックスを見つける際の6つの考慮事項を次に示します。 たとえば、次のコマンドは、コレクション「test.foo」のインデックス統計を提供します。 db.foo.aggregate( [ { $indexStats: { } } ] ) https://bit.ly/2seXnzo $ indexStatsの出力については説明しません。このトピックをカバーするドキュメン