2

SOや他のサイトが、ユーザーテーブルの自動インクリメント主キーを公開されているユーザーIDとして使用していることに気づきました（少なくとも、これが彼らが行っていることだと思います）。SOの場合、ユーザーIDを知っているか推測できる場合は、ユーザーのプロファイルを表示できます。

同様のスタイルのユーザーID生成を実装する前に考慮すべき点は何ですか？ユーザー間でさまざまな権限を割り当てる際に「友達」の概念に依存する非商用アプリを開発していますが、すべてのユーザーの基本プロファイルをなどの単純なURLで表示できるようにしたいと思いますapp.com/users/userid。より詳細なプロファイル情報には、そのユーザーによって確認されたそのユーザーの「友達」のみがアクセスできます。

私の質問は、ユーザーIDの「推測可能性」は、このようなシステムの固有のセキュリティについて何かを示しているのか、それとも個々の機能が実際に実装されているのかということです。これについて私が考えていないかもしれない何かが賢明ではないでしょうか？これらのユーザーIDで絶対に避けるべきことはありますか？

注：「競合他社」が、最新のユーザーの数やユーザー間の変化率に基づいて、自分が何人のユーザーを持っているかを知っている、または推測していることについては心配していません。

4

2 に答える 2

2

OWASP - 安全でない直接オブジェクト参照

主題のかなり良い扱いをします。実際、Web アプリケーションを開発する際のセキュリティ ガイドラインとして、一般的に OWASP を強くお勧めします。私は常に、サイトで見つかった上位 10 のセキュリティ脅威に対して自分の Web プロジェクトを評価しています。

于 2012-02-23T20:07:15.510 に答える
1

まったく問題ありません。実際、私はほぼ反対のことを言っています。セキュリティのために URL のパラメーターを不明瞭にする必要がある場合は、それが間違っています。セキュリティはコードで処理する必要があります。

あなたの質問から、あなたはすでにセキュリティについて正しい方法で考えているように見えるので、URL の主キーで問題ないはずです。

情報を格納しない primary_key (auto_incremented id など) を使用することも、決して変更されないため有効です。ユーザー名のような情報を URL に入れる場合、ユーザー名を編集できるように実装したくないか、ユーザー名を編集したときに残る可能性のある壊れたリンクに対処する必要があります (それらはあなたのサイト以外にある可能性があることに注意してください)。 ）。

URL に auto_incremented id を持つ唯一の情報が漏洩する可能性があるのは、あるユーザーが別のユーザーの前または後のユーザーであったかどうかを知ることです。これが問題になる可能性は低いです (とにかく信頼できないかもしれません)。

于 2012-02-23T19:52:27.323 に答える