私の同僚は、クエリ文字列 ID をマスクするためにグローバルな変更番号を使用することは良い考えだと主張しています。
public static readonly int ModificationNumber = 9081234;
そして他の場所：
_addressID = Convert.ToInt32(Request.QueryString["AddressId"]) - ModificationNumber;
私はこれについて頭をつかむことができないようです。誰かが URL のハッキングを試みた場合、修正番号はまったく関係ありません。
これがサイトをより安全にする他の理由はありますか?
さらに、これが悪い明確な理由はありますか? 私の考えでは、グローバルが少ないほど良いです。
IMVHO あなたの同僚は正しい道を進んでいますが、完全ではありません。
従うべき良いルールは、クエリ文字列で実際の ID を公開しないことです。これにより、データベースの構造に関する手がかりが得られ、誰かが SQL インジェクション タイプの攻撃を実行しやすくなります ( ID を知っているため、特定のレコードをターゲットにすることができます)。
つまり、あなたの同僚は、非常に回りくどい方法ではありますが、これを達成しようとしています。個人的には、賢い攻撃者があなたが何をしているかを理解し、マジック ナンバーが何であるかを理解するのは時間の問題なので、私はこのようにはしません。また、生成された数値が既存のキーと一致する可能性があるため、特定のレコードに対する SQL インジェクション攻撃を防ぐために実際には何もしません。SQL 攻撃を回避するためにこの方法論に依存している場合は、対処する必要があるより深い問題があります。
代替案について言及することは、おそらく公正なことです。C# を使用してクエリ文字列からパラメーターを取得しているため、ASP.NET を使用していると仮定します。その場合、重要な ID はセッションまたはキャッシュに保持できます。一連のアイテムをカスタム データ オブジェクトに保存し、それを Session に保存できます (これにより、多くの ID を追跡する必要がなくなります。1 つだけ知っていればよいのです)。ASP.NET は Web アプリのセッションを管理します。これは各ユーザーに固有のものであり、ページからページに移行するときにそれを使用してデータを保存できます。
手動でセッションを追跡している場合、またはデータベースを使用してセッション関連情報を保持している場合でも、生成された GUID をキーとして使用して前述のデータ オブジェクトをデータベースにシリアル化し、その GUID をクエリ文字列に追加できます (信じられないほどユーザーが GUID をいじって他の誰かのセッションを引き受けようとした場合、成功する可能性は低くなります。2 つの GUID をキーとして連結することで、その可能性をさらに下げることができます)。