アプリケーションのフロントエンドでデータベースの主キー（ID）を隠す必要がありますか？
モデレーターがユーザーの情報を編集できるアプリケーションを開発しています。だから、現時点では、私は次のようなURLを持っています
http://www.example.com/user/1/edit
http://www.example.com/user/2/edit
データベースからユーザーテーブルの主キー（ID）を直接公開しているので、ここでは少し心配です。私は単にURLからIDを取得し（例：上記のURLの1および2）、IDを使用してデータベースにクエリを実行し、ユーザー情報を取得します（もちろん、入力をサニタイズしています-URLからのID）。
モデレーターにそのユーザーを編集するためのアクセス権があるかどうかを確認するすべてのリクエストを検証していますであることに注意してください。
安全なことは何ですか？そうでない場合、どうすればよいですか？
私は1つの代替案を考えることができます。つまり、25文字のキーを持つユーザーテーブル用の個別の列を持ち、URLのキーを使用し、それらのキーでデータベースをクエリします。
しかしながら、
- どんな違いがあるの？ （現在、キーが公開されているため）
- 主キーによるクエリは、他の列よりも結果が速くなります
「非表示」にしたい唯一の情報はsequenceです。データベースは主キーの値をカウンターで割り当てるため、それらのキーを見る人は推測することができますいつ対応するユーザーアカウントが作成されました。それ以外には、不明瞭なスキームが実際に非表示にする可能性のある他の情報はありません。攻撃者は、個別のユーザーが個別のキーを介して参照されることをすでに知っており、それがデータベースの「主キー」のセマンティクスの範囲です。
したがって、アカウントの作成順序は非表示にする必要がある個人情報であると考えない限り、あいまいなスキームは無意味だと思います。
簡単な方法の1つは、youtubeや他のWebサイトで使用されている方法を使用することです。これはハッシュ（ http://hashids.org ）です。
この方法を使用すると、次のようなリンクを提供できます： http://www.example.org/user/fce7db/edit fce7dbは数値に等しくなります。
これには、データベースで別のランダムハッシュを生成するのとは対照的に、パフォーマンスの利点があります。これは、ハッシュを1回変換するだけで、以前と同じように元の主キーでデータベースを検索できるためです。
ユーザーが他のIDをランダムに見つけるのをより困難にするために、1つの最小の長さのシークレットソルトを使用して、それらの「総当たり」を防止することができます。
http://www.example.com/image/c8yDa のような場合でも、1つの秘密のソルトを使用することで、人々は引き続きURLを交換できます。
いいえ。何らかの方法で、URL内の一意の識別子で特定のレコードを識別する必要があります。それは主キーまたは何か他のことができます。順序またはシーケンスを非表示にする必要がある場合は、Z2wDKo0ubb1D2VngFh4Nのようなランダムで一意の文字列を持つ2番目の列を使用できます。
セキュリティを強化する場合は、SSLを使用します。 @eggyalが指摘したように、これによってユーザーがURLとパラメーターを表示することは妨げられません。
SSLを使用して、URLパラメータは暗号化され、盗聴を防止します。そして、はい、SSLには欠陥があり、実際には安全ではないことがわかっていますが、SSLを使用しない場合よりもセキュリティが向上します。ただし、パスワードにURLを使用しないでください。ログインしてデータを送信するにはPOSTを使用し、情報を取得するにはGETを使用します。これはいつものことです。
参照 https://stackoverflow.com/questions/499591/are-https-urls-encrypted
URLで秘密情報を使用しない理由：DNSリクエストはおそらく暗号化されていません（ただし、コメントに@tgiesと記されているように、リクエスト部分は含まれていないため、ここにはIDがありません）、ブラウザ履歴、サーバーログ。
URLで主キー（または他の識別子）を使用するか使用しないいくつかのシステムを作成しました。どちらを使用するかは、完全に危害要因に依存します。たとえば、データ駆動型の読み取り専用のサイトでは、URLの主キーを使用します。誰かが製品を順番に通過してもかまいません。
セキュリティ要件のあるシステムでは、連続した予測可能なIDを使用する代わりに、2つのスキームのいずれかを使用しました。
- ブラウザのセッションの重要な情報を保持します。単純明快で、サーバーが安全でない場合、さらに大きな問題が発生します。
- レコードが作成されたときに、乱数が生成され（一意性がチェックされました）、ORセッションでのみ使用され、URL内でその乱数が使用されました。
幸運を、
ラリー
はい、情報を漏らしているため、これらのIDを難読化する必要があります。
アプリケーションが完全に安全である場合、（ab）ユーザーが知ることができる唯一の情報は、 Doomsday Argument と呼ばれるものを使用してユーザー数を推定することです。‡。また、複数のユーザーのIDを知っていれば、最初にサインアップしたユーザーがわかるので、どれだけ離れているかを推測できます。また、他のユーザーのIDについても知識に基づいた推測を行うことができます。
Ifアプリケーションは完全に安全です。
そうでない場合、そうでない可能性があると常に想定する必要がある場合は、有用な情報を提供しています。ユーザーIDが単なる乱数である場合、攻撃者は別の有効なIDを簡単に特定することはできません。通常、自動主キーによって（ほとんど連続した）番号が与えられるため、それは取るに足らないことです。
内部使用のために小さい数値の使いやすさを維持したい場合は、主キーを変更するか、または副キーを追加できます。この新しいキーは通常 [〜＃〜] guid [〜＃〜] である必要があります。
‡：もちろんこれはxkcdリンクです。
アプリケーションを不明瞭にする必要があるかどうかを知るために、アプリケーションに関する十分な情報を提供していません。そのため、あなたの質問のこの部分は答えられません。ただし、質問する必要がある場合、答えはおそらくはいです。そうでない場合でも、義務の要請を超えて、代替案よりも多くの保護を提供します。
主キーを隠したり隠したりするのではなく、変更することを検討してください。連続している必要はありません。新しいユーザーを作成するときは、ランダムな32ビットの数値を作成し、クイック選択を行って使用されていないことを確認し、それを主キーとして使用します。
誰かがユーザーを編集している場合、ユーザーはユーザー番号から情報を取得できず、現在アクセスできる番号のすぐ隣にある番号を試すと、存在しないレコードが生成される可能性があります。
このシステムのオーバーヘッド/負担は最小限です。アカウントの作成時に選択を1つ追加する必要がありますが、これはまれであり、後の追加オーバーヘッドを課すことはありません。URLで主キーを提供しているため、DB検索は高速ですが、キーには情報がありません。