ID列とセキュリティ

Question

質問

は、RESTfulなWebアプリケーションで使用する場合、ID列がデフォルト以外のシード/増分を持っているオートインクリメントすべきか？

背景

私は私の最初のASP.NET MVCアプリケーションでの作業とRESTful私のURLを維持しようとしています。アプリケーションの管理Webサイトは別個にありません。私は属性を使用して、サイト内のどの部分にアクセスできるのか、現在のユーザーがシステム内の役割に基づいてどのメニュー項目を表示できるのかを制御します。私は（ほとんど）ActiveRecordのDBパターンに従い、idが自動生成されたID列であるuserテーブルを含め、私のテーブルに合成IDを使用します。

RESTfulアプリケーションのID列にデフォルトのシードを使用することには、微妙なセキュリティリスクがありました。管理ID（特に最も強力なもの）がアプリケーション内で最初に作成されると仮定すると、システム内のID番号が最も低くなります。実際にアプリケーションで穴を開けていない間に、シード/インクリメントにデフォルト値を使用すると、RESTfulなアクション（ChangePasswordなど）を使用して低い番号のIDをターゲットにするだけで、クラッカーが高価値のターゲットを攻撃しやすくなります。 ASP.NET MVCサイトテンプレートのすぐに使用できるアクション）。

セキュリティベストプラクティスのベストプラクティスに、デフォルトではないシードを、少なくとも私のユーザーテーブルに追加する必要がありますか？それに価値があることの効果はありますか？それとも、私はあまりにも過敏症ですか？関連する質問として、私はアカウント関連のアクションのテンプレートテンプレート名を変更する必要があります。

Answer 1

ここでは、自動インクリメント列のデフォルトのシードを変更することでリスクを解決することに決めました。これは難しいことではなく、アプリケーションまたはActiveRecordパターンの特性を変更しません。これらの列は外部キー関係にも使用されるので、インデックスをより効率的にするために整数を保持したいと考えています。

別の動詞が理にかなっていない限り、デフォルトのアクションを変更する予定はありません。インターフェースを直感的にすることは、あいまいな名前の後ろにアクションを隠すことよりも重要です。

Answer 2

私のアドバイスは、IDを自動インクリメントする代わりにGUIDを使用することです。それは「推測ゲーム」を完全に取り除きます。

Answer 3

私はGuid'sを使うことについて非常に懐疑的でした。 Lucernoが指摘しているように、Guidがどのように生成されて使用されるかに応じて推測ゲームを最小限に抑えるのに役立ちます。 SQL Serverからシーケンシャルを使用して生成されたガイドは、たとえば推測ゲームを防ぐことはできません。

ドメインモデルがあり、nHibernateのようなORMを使用している場合や独自のロールを使用している場合でも、ガイドは非常に便利です。これは、すべてのオブジェクトにIDを早期に与えることができるため、後方参照を挿入する際の複雑さを大幅に簡素化するためです。

あなたのIDがURLに含まれているとすれば、非常にパブリックなデータとして扱われるはずです。 HTTPS上でさえ悪意のある攻撃がURL全体を取得する可能性があります。たとえば、Googleアナリティクスなどのサードパーティのコンテンツをリクエストした場合、URLクエリ文字列とすべてがリファラーとしてサードパーティに送信されます。

Answer 4

ログインしたユーザーは、サーバー側のセッションでクライアントに渡すのではなく、悪意のあるクエリでユーザーIDを変更することはできません。