web-dev-qa-db-ja.com

MongoDB IDを使用した場合のセキュリティリスクとURLのカウンターの違い

Angularアプリでは、URLにMongoDB IDを使用しています。これにはセキュリティ上のリスクがありますか？

代わりにカウンターを使用する必要がありますが、DBにはこのカウンターを実際のIDにリンクするある種のコレクションがありますか？ mysite.com/story/56ede7fsdfdsfdsfs2a7283の代わりにmysite.com/story/32を使用しますか？

web-applicationmongodb
5
userMod2

サーバーに応じて作成時間をユーザーに公開する以外に、mongoDB IDを公開すること（他のカウンターIDを除く）に実際のセキュリティリスクを考えることはできません。 mongoの主キーと他の一意のキー（カウンターなど）を用意しても、露出の点で違いはありません。

ご存知のとおり、mongo __id_は次のもので構成されています。

  • unixエポックからの秒数を表す4バイトの値
  • 3バイトのマシンID、
  • 2バイトのプロセスID、および
  • ランダムな値で始まる3バイトのカウンター。

そして、おそらくあなたはこの情報の一部をユーザーに公開したくないでしょう（作成時間など）。

したがって、ID _56ede7f0dfdsfdsfs2a7283_（16進数ではないsがあり、最後に16進数がないと思われる場合）は、12バイトまたは24 hex（0 -9a-f）数字なので、「s」を「0」に置き換えました）、_56ede7f0_から_2016-03-19T23:59:44.000Z_で作成されたことがわかります。 （例： https://steveridout.github.io/mongo-object-time/ またはシェルでObjectId("56ede7f0dfd0fd0f20a72830").getTimestamp()を試してください）。

4
dr jimbob

[〜＃〜] owasp [〜＃〜] は、 Top 10 2007-Insecure Direct Object Reference で説明されているように、単純な種類の直接識別子を持つことは悪いことであると述べています= =および トップ10 2010-A4-安全でない直接オブジェクト参照 エントリ。このような直接参照を悪用する方法を理解できる攻撃者は、本来よりもはるかに強力な権限を持つことになります。

ここで質問したように、OWASPは実際にはインデックス値の使用を推奨していますが、これらには独自の問題が伴う場合があります。攻撃者にすべてのデータにシーケンシャルにアクセスするためのすばらしく簡単な方法を与えることで、認証や権限昇格の悪用を発見した場合、データベース全体を簡単に読み取り、更新、または削除することさえできます。

現実の世界では、そのような出来事は以前にも起こりました。パスワードリセットページで単純な主キーを使用してサービスから取得したいくつかの電子メールアドレスダンプのように。または、システムからすべてのメッセージをサービスから削除します。リストは続きますが、要点はif自動インクリメントフィールドを主キーとして使用することを決定した場合、そのIDを使用してリクエストを検証し、（a）ユーザーに十分な権限があること、（b）リクエストが偽造されていないこと、おそらくクロスサイトリクエストフォージェリトークン、本質的​​にはリクエストが正当です。

2
phyrfox

dr jimbob からの回答で述べられているように、これはMongoDB IDのメタ情報を公開します。

この質問を投稿する別の方法は

リンクとURIでDBのエントリに関するメタ情報を公開しないためのベストプラクティスは何ですか？

その質問への答えは簡単です。メタ情報に関連付けられていないエントリには、一意の識別子フィールドを使用してください。これらは簡単に生成でき、他のエントリと照合して確認できます。衝突が見つかった場合は、別のエントリを生成できます。次に、これをハッシュ/インデックス/ MongoDBがこれらのドキュメントをより速く見つけるために使用するシステムに保存できます。

ただし、これはソーシャルメディアで共有しているユーザーには対応していないため、セキュリティモデルでそれを考慮に入れて、他のユーザーが表示してはいけないものを表示しないようにしてください。

1
Robert Mennell

URLに情報を提供する

URLは、それが導く実際のページにアクセスすることを想定されていない人でもアクセスできる場合があります。すべてのURLがWeb全体のリンクに表示されたり、リファラーヘッダーを介してリークしたりする可能性があります。したがって、URLに機密情報を含めないでください。

Mongo IDには、オブジェクトが（最初の部分から）作成された時刻に関する情報が含まれています。カウンターには、オブジェクトが作成された順序に関する情報のみが含まれます。

カウンターは、オブジェクトの合計数に関する情報も提供します（ ドイツ戦車の問題 を参照）。ただし、最後の部分はグローバルカウンターであるため、Mongo IDも同様です。乱数から始まるため、伝達する情報は少なくなりますが、URLが多い攻撃者は、ドキュメントの総数を推定できます。

列挙攻撃

URLが連続している場合、攻撃者がすべてのリソースのリストを取得するのは簡単です。これは列挙型攻撃と呼ばれます。

カウンターの場合、これは明らかに簡単です。 Mongo IDの場合は、作成されたミリ秒のオブジェクトを推測する必要があるため、より困難です。オブジェクトが作成される時間について漠然とした考えがある場合でも、それを総当たりにすることができます。

結論

URLでドキュメントに関する情報を提供したり、ユーザーにすべてのドキュメントを列挙させたりすることが心配な場合は、どちらのアプローチもかなり悪いです。そうでない場合は、どちらの方法でも問題ありません。

3番目のソリューション

上記の問題が心配な場合は、代わりに ランダムID を使用できます。衝突の可能性を減らすために大きなスペースを使用し、運が悪い場合に問題が発生しないようにいくつかのエラー処理を行います。

IDは、_id（デフォルトを上書きできます）として、またはurl_idという名前のフィールドに、またはそのようなものに格納できます。一意のハッシュインデックスを配置して、検索を高速化します。

1
Anders