Webアプリのソースで主キーを公開しないようにしますか？

Question

多くの場合、選択ボックスなどのフォームを介して内部データベースのプライマリキーを公開するWebアプリケーションに遭遇します。また、ロジックを切り替えるintまたはguidのマジック値に対してjavascriptが一致することもあります。

は、Webアプリケーションの行のすべての内部識別子の漏洩を回避し、部外者がシステムを理解しすぎて、システムを悪用するのを防ぐためのベストプラクティスです。もしそうなら、この問題を解決する最良の方法は何ですか？

主キーに戻すことができる他の値をWebアプリに公開する必要がありますか？

ありがとう

編集

完璧な世界では、アプリケーションは100％安全であるため、物を隠しても問題になりません。明らかにそうではないので、注意してエラーを起こしてこの情報を公開しないようにすべきですか？

StackoverflowがUrlのキーを公開している可能性が高いと指摘する人もいます。ただし、エンタープライズアプリケーションでは考慮事項が異なりますか？

Answer 1

主キーの公開が問題であるというスタンスには同意しません。ユーザーがシステムの外部で意味を与えられるため、ユーザーに見えるようにすると問題になる可能性があります。これは通常、回避しようとしていることです。

ただし、IDをコンボボックスリストアイテムの値として使用するには？それのために私が言う。いくつかの中間的な価値との間で翻訳を行う意味は何ですか？使用する一意のキーがない場合があります。このような翻訳は、バグの可能性を高めます。

セキュリティを無視しないでください。

ユーザーに6つのアイテム（ID 1から6）を提示すると言った場合、ユーザーからそれらの値のみを取得すると仮定しないでください。誰かがID 7を送り返すことでセキュリティを侵害しようとする可能性があるので、戻ってきたものが許可されていることを確認する必要があります。

しかし、それを完全に回避しますか？とんでもない。必要ありません。

別の回答のコメントにあるように、ここのURLを見てください。これには、間違いなくSOデータベース内の質問の主キーが含まれます。技術的な用途のためにキーを公開することはまったく問題ありません。

また、代わりにサロゲート値を使用する場合、必ずしも安全ではありません。

Answer 2

はい、キーを公開することは攻撃として使用できる情報です。特に予測可能な場合。

情報が機密であると思われる場合は、別のキー/列を使用します。

たとえば、あなたがどのくらいのユーザーを持っているかを示すことを避けるために、考慮してください：

site.com/user/123 vs site.com/user/username

Answer 3

はい、すべての質問に答えます。 ＆quot; 主キーに変換できる他の値をウェブアプリに公開する必要がある＆quot;

という主張に同意します

それ以外の場合、潜在的な問題に自分自身を開放できます。

編集

簡単なキーのペナルティヒットを取る理由がないというコメントについて。ブラウザのURLを今すぐ見てください。キーが表示されているはずです！＆quot;。

私はあなたの言っていることを理解しています。そして、はい、SO URLにキーがあり、おそらくデータベースPKを参照していることに同意します。このような例では、より良い代替手段がない場合はおそらく大丈夫だと認めています。

PK以外の何か-セマンティックな値を持つものを公開したいのです。質問のタイトルもURLにありますが、これは一意である（またはユーザー間で言葉でやり取りする）ことを確認するのが難しいため、単独で確実に使用することはできません。

「タグ」を見るときただし、URL（つまり https://stackoverflow.com/questions/tagged/java+j2ee ）の場合、PKは公開されず、代わりにタグ名が使用されます。個人的に、私はそのアプローチを好み、そのために努力します。

また、PKが指すデータは時間とともに変化する場合があることを付け加えました。オフラインプロセスからの情報でテーブルがいっぱいになったシステムで作業しました。つまり、月末にDBテーブルの内容がドロップされ、新しいデータが再入力された月次統計です。

データが異なる順序でデータベースに追加されると、特定のデータポイントのPKが変更され、前月からそのデータに保存されたブックマークは異なるデータセットを指すようになります。

これは、PKを公開すると「壊れる」インスタンスの1つです。アプリのセキュリティとは無関係のアプリ。生成されたキーではそうではありません。

Answer 4

いつものように、「依存する」。あなたが（時間/日/月）ごとに実行しているトランザクションの数を知ることで誰かが（例えば）価値を得ることができ、トランザクションIDを単調に増加する数として公開している場合、それはリスクです。

他の人が言ったように、値のドロップダウンリストについては、通常は問題ありません。

Answer 5

主キー以外の値を公開しても、セキュリティをチェックする負担を回避できません。実際、セキュリティに穴がある場合、「悪」ユーザーは、URLの値を変更することで、意図していないオブジェクトにアクセスする可能性があります。どの値を使用するかについての手がかりは少ないかもしれませんが、値をランダムに選択すると、幸運になるかもしれません。

この方法でセキュリティを向上させる場合は、URLで（推測を困難にするために）IDの代わりに大きなランダム文字列を使用し、ランダム値とバックグラウンドで適切なIDに一致する間接テーブルを使用する必要があります。

ほとんどの場合、手間をかける価値はないと思います。

それは、たとえば、ユーザーパスワードを変更するためのページを公開し、ログインを必要としない（パスワードを失ったユーザー）など、「セキュリティを不明瞭にする」ことを望む場合に役立ちます。このような場合、有効期限の制限もキーに関連付ける必要があります。

Answer 6

主キーは、多少の重複はありますが、代理キーまたは内部キーと同じものではありません。内部キーの反対は自然なキーです。自然キーが主キーとして使用される場合が多くあります。一般に、プライバシーの問題に対処していない限り、自然なキーを隠す理由はありません。

あなたの本当の質問は、内部キーをユーザーに公開すべきかどうかです。答えは「依存する」です。ほとんどのユーザーコミュニティでは、内部キーを公開すると、キーが自然キーとして使用されるようになります。これにより、内部キーとテーブル行のサブジェクトとの間の1対1のマッピングが崩れたときに混乱が生じる可能性があり、通常はそうなります。

この内訳は、データの誤った管理の結果としてのみ発生します。ただし、ほとんどの場合、現実世界で発生するデータの誤管理を計画する必要があります。あなたは、水が誤って管理されるたびに故障する給水システムを計画しないでしょう。データの誤管理があるたびに故障する情報システムを計画していません。

とはいえ、最近のデータベース設計者のほとんどはソフトウェアベンダーで働いており、製品のユーザーによるデータの誤管理によって引き起こされる問題を認識していません。