「NoSQL Injection」からNoSQLiを学ぶ

Bug Report

ソース：

redfoxsecurity.medium.com

脆弱性：SQLインジェクション

 

訳：

NoSQL データベースとは何ですか?

NoSQL (SQL だけではありません) は、従来のデータストアの使用を破壊。
以前のストレージメカニズムとは異なり、非リレーショナルなデータストレージの新しい概念が導入されているため、制限の不整合が緩和され。
ドキュメント ストア、グラフ、およびキーと値のストアがあります。 現代のアプリケーションに対する新たな需要により、多数のサーバー間でのデータの分散を容易にする NoSQL データベースが広く採用されていて。
NoSQL データベースは幅広いスケーラビリティを実現し、同じトランザクションのすべての操作を実行するには単一のデータベースノードを必要とし。

NoSQL データベースは以前から存在していましたが、この用語は 2009 年初頭に広く普及し。
NoSQL データベースにはさまざまなタイプとインスタンスがあり、その一部を以下に。

 

NoSQLデータベース

 

NoSQL データベースが従来の SQL データベースと異なる点は次のとおりです。

  • 動的スキーム
  • 残りのデータに影響を与えることなく、フィールドをオンザフライで編集またはドキュメントに変更できます。
  • 水平方向のスケーラビリティ
  • 構造化されたクエリ言語がない

これまでのところ、最も広く使用されている NoSQL データベースは MongoDB です。

 

SQL インジェクション攻撃と MongoDB のような NoSQL データベースの比較

SQL インジェクションは よく知られた脆弱性で。
SQL は、ユーザーがデータベースに対してクエリを実行したり、データベースからクエリを実行したり、論理演算子を使用してデータを回復したりできる言語。
これらの検索には定期的にユーザーが指定したデータが含まれるため、入力が適切にサニタイズされていない場合、インジェクション攻撃に対して脆弱になる可能性があり。

 

NoSQL データベースでクエリを実行するために SQLは使用されず。
ただし、NoSQL クエリはインジェクションの影響を受けないわけではなく。
クエリにはユーザーが指定したデータが含まれているため、このデータを適切にサニタイズしないと危険な結果が生じる可能性があり。

 

インジェクションを見つける

まず、アプリケーションがユーザー提供のデータをどこで取り込んでいるかを見つけることが重要で。
言い換えれば、外部ユーザーが制御できるデータで。
例としては次のようなものがあります。

  • フォームのフィルタリングまたは検索
  • 認証フォーム
  • ヘッダーとクッキー

一部の入力パラメータはバックエンド データベースクエリで直接使用される可能性があるため、エラーや予期しない動作を引き起こすように値を変更してみる価値があり。

クエリを中断する可能性のある入力文字の一部を以下に示し。

 

‘ “ \ ; { } ( )

 

NoSQLMap は、簡単に実現できる成果を得るために活用できる場合もありますが、より高度なケースでは、ほとんどの場合、手動テスト、静的分析、コード レビューが必要になり。

NoSQL インジェクションの脆弱性で一般的に使用される演算子は次のとおりで。

 

  1. $eq = Equal to
  2. $ne = Not equal to
  3. $gt = Greater than
  4. $regex = Regular expression
  5. $It = Less than
  6. $in = Check if the required data is present in a data structure such as pointer or array, etc.

NoSQL インジェクション

この脆弱性をシミュレートするために、「OWASP ジュース ショップの脆弱性」アプリケーションを使用しました。

 

OWASP ジュース ショップの脆弱なアプリケーション

 

このアプリケーションでは、認証後、ユーザーは製品のレビューを送信でき。
レビューが送信されると、ユーザーは自分のレビューを編集する権限のみを持ち、アプリケーションの他のユーザーによって与えられたレビューは編集できず。

たとえば、このアプリケーションでは、ユーザーの電子メール ID は bender@juice-sh.op で。

 

ステップ 1: ユーザーはいずれかの製品をクリックしてレビューを送信し。

 

 

ステップ 2: レビューを送信した後、ユーザーは「編集」をクリックし、提案されたレビューに変更を加え。

 

 

ステップ 3: レビューの編集後、BurpSuiteを使用してリクエストをインターセプトし。
リクエストを見ると、各レビューに独自の一意の英数字 ID 値があることがわかり。

 

BurpSuite

 

ステップ 4: Id パラメーターを削除し、単純な NoSQL インジェクションペイロード ($ne:-1) を追加し。
これにより、指定された ID が、指定された ID 値、つまり -1 と等しくないことが保証され。

 

NoSQLインジェクション

 

ステップ 5: Web ページを更新し。
NoSQL インジェクション ペイロードは、アプリケーションの他のユーザーによって以前に送信されたすべてのレビューを実行して変更することに注意して。

 

 

緩和

  • 入力を検証して悪意のあるパラメータを検出し。
    入力の種類を予期される型と比較して検証することにも留意して。
  • 文字列からクエリを構築せず、準備されたステートメントとともに安全な API を使用してく。
  • インジェクション攻撃が成功した場合の潜在的な被害を最小限に抑えるために、アプリケーション アカウントに DBA または管理者タイプのアクセス権を割り当てないで。

MongoDB ドキュメントから:

MongoDB では、JavaScript を使用せずにほとんどのクエリを表現できます。また、JavaScript を必要とするクエリの場合は、単一のクエリに JavaScript と非 JavaScript を混在させることができます。 ユーザー指定のフィールドをすべて BSON フィールドに直接配置し、JavaScript コードを $where フィールドに渡します。

コマンドラインで — noscripting オプションを渡すか、構成ファイルで security.javascriptEnabled を設定することにより、MongoDB でのサーバー側の JavaScript の実行をすべて無効にできます。