選択ボックスなどのフォームを介して内部データベースの主キーを公開する Web アプリケーションによく出くわします。また、ロジックを切り替える int または guid マジック値に対して JavaScript が一致する場合もあります。
これは、部外者がシステムを理解しすぎてシステムを悪用する可能性を防ぐために、Web アプリケーション内の行のすべての内部識別子を漏らさないようにするためのベスト プラクティスです。もしそうなら、この問題を解決する最善の方法は何ですか?
主キーに変換できる他の値を Web アプリに公開する必要がありますか?
ありがとう
編集
完璧な世界では、アプリケーションは 100% 安全であるため、何かを隠しても問題ありません。明らかにそうではないので、注意を怠ってこの情報を公開しないようにする必要がありますか?
Stackoverflow が URL でキーを公開している可能性が高いと指摘する人もいますが、これはおそらく問題ありません。ただし、エンタープライズ アプリケーションでは考慮事項が異なりますか?
主キーを公開することが問題であるというスタンスには同意しません。ユーザーに見えるようにすると、システムの外で意味が与えられるため、問題になる可能性があります。これは通常、回避しようとしていることです。
しかし、ID をコンボ ボックス リスト アイテムの値として使用するにはどうすればよいでしょうか。頑張れよ。中間値との間の変換を行う意味は何ですか? 使用する一意のキーがない場合があります。このような変換では、バグが発生する可能性が高くなります。
セキュリティをおろそかにしないでください。
ユーザーに 6 つのアイテム (ID 1 から 6) を提示するとしても、それらの値のみがユーザーから返されるとは決して考えないでください。誰かが ID 7 を送り返すことでセキュリティを侵害しようとする可能性があるため、返されたものが許可されていることを確認する必要があります。
しかし、それを完全に回避しますか？とんでもない。必要なし。
別の回答のコメントにあるように、ここの URL を見てください。これには、SO データベース内の質問の主キーであることは間違いないものが含まれます。技術的な使用のためにキーを公開することはまったく問題ありません。
また、代わりにサロゲート値を使用する場合、必ずしもより安全であるとは限りません。
はい、すべての質問にお答えします。「主キーに変換できる他の値をWebアプリに公開する」必要があるというあなたの主張に同意します
そうしないと、潜在的な問題に自分自身を開くことができます。
編集
「ささいなキーにペナルティ ヒットを取る理由はありません。今すぐブラウザの URL を確認してください。キーが表示されているに違いありません!」というコメントについて。
私はあなたの言っていることを理解しています。はい、SO URL にキーがあり、おそらくデータベース PK を参照していることに同意します。このような場合、より良い代替手段がなければ、おそらく問題ないことを認めます。
PK 以外のもの、つまりセマンティックな値を持つものを公開したいと思います。質問のタイトルも URL に含まれていますが、これは一意であることを確認する (またはユーザー間で口頭でやり取りする) のが難しいため、単独で確実に使用することはできません。
ただし、「タグ」URL (つまりhttps://stackoverflow.com/questions/tagged/java+j2ee ) を見ると、PK は公開されず、代わりにタグ名が使用されます。個人的には、私はそのアプローチを好み、そのために努力します。
また、PK が指すデータは時間の経過とともに変化する場合があることも付け加えたいと思います。私は、テーブルがオフライン プロセスからの情報で満たされているシステムで作業しました。つまり、月末に DB テーブルの内容が削除され、新しいデータが再入力された月次統計です。
データが別の順序でデータベースに追加されると、特定のデータ ポイントの PK が変更され、前月からそのデータへの保存されたブックマークが別のデータ セットを指すようになります。
これは、PK を公開すると、アプリのセキュリティに関係のないアプリが "壊れる" 1 つの例です。生成されたキーではそうではありません。
はい、キーを公開することは、攻撃として使用できる情報です。特にそれらが予測可能な場合。
情報が機密であると思われる場合は、別のキー/列を使用してください。
たとえば、ユーザー数を表示しないようにするには、次のことを考慮してください。
site.com/user/123 対 site.com/user/username
いつも通り「場合による」。誰かが (時間/日/月) に実行しているトランザクションの数を知ることで (たとえば) 価値を得ることができ、トランザクション ID を単調に増加する数値として公開している場合、それはリスクです。
他の人が言ったように、値のドロップダウン リストの場合、通常は問題ありません。
主キーは、代理キーまたは内部キーと同じものではありませんが、一部重複があります。内部キーの反対は自然キーです。自然キーが主キーとして使用されることがよくあります。一般に、プライバシーの問題を扱っていない限り、自然キーを隠す理由はありません。
あなたの本当の質問は、内部キーをユーザーに公開する必要があるかどうかについてだと思います。答えは、「場合による」です。ほとんどのユーザー コミュニティでは、内部キーを公開すると、そのキーが自然キーとして使用されるようになります。これにより、内部キーとテーブル行のサブジェクトの間の 1 対 1 のマッピングが壊れたときに、混乱が生じる可能性があり、通常は混乱が生じます。
この故障は、データの不適切な管理の結果としてのみ発生する可能性があります。ただし、ほとんどの場合、現実の世界で発生するデータ管理の不備について計画する必要があります。水の管理が不適切な場合に故障するような給水システムを計画することはありません。データの管理ミスが発生するたびに故障するような情報システムを計画することはありません。
そうは言っても、最近のほとんどのデータベース設計者はソフトウェア ベンダーの下で働いており、製品のユーザーによるデータの不適切な管理によって引き起こされる問題を認識していません。
主キー以外の値を公開しても、セキュリティ チェックの負担は避けられません。実際、セキュリティに穴がある場合、「悪意のある」ユーザーは、URL の値を変更することで、意図しないオブジェクトにアクセスする可能性があります。どの値を使用するかについての手がかりは少ないかもしれませんが、値をランダムに選択すると、幸運になる可能性があります。
この方法でセキュリティを向上させたい場合は、ID の代わりに (推測を困難にするために) URL に大きなランダム文字列を使用し、バックグラウンドで適切な ID とランダム値を一致させる間接テーブルを使用する必要があります。
ほとんどの場合、手間をかける価値はないと思います。
とはいえ、たとえば、ユーザーのパスワードを変更するためのページを公開し、ログインを必要としない (ユーザーがパスワードを紛失した場合) など、「あいまいなセキュリティ」が必要な場合に役立ちます。このような場合、有効期限の日付をキーに関連付ける必要もあります。