セッションCookie（永続的なCookieではない）を使用してユーザーIDを保存し、ユーザーがログインしているかどうかを確認しています。
基本的に、ユーザーはログインし、資格情報を確認してから、セッションCookie userID = 37を設定します（この特定のユーザーの場合、別のユーザーは73または69などになります...）
Session.Add("UserID", 37);
私の質問は、ログインしているユーザーがこのセッションCookieを37から73に変更して、サーバーをだまして実際にユーザー73であると思わせることは可能ですか？はいの場合、私は何を間違っていますか、このケースをどのように処理しますか？セッションのユーザーIDとパスワードのハッシュを入力して毎回チェックするのは非常識なようです。
このユーザーID値は、後でクエリでも使用して制限します。
これが正確なコードの質問ではない場合は申し訳ありませんが、私のコードに非常に関連しています。
セッション Cookie には、セッション ID のみが含まれます。ユーザーを識別するために使用されます。それ以上のものは含まれていません。このセッションの実際の情報はサーバーに保存されます。だからこれは安全です。ユーザーは、サーバーに保存されている値を変更することはできません。これをセッション内に保存した場合、ユーザーは自分の ID を変更できません。
これは、ユーザー ID を扱う場合、フォーム認証を使用して認証済みユーザーを追跡することを検討できると言われています。
ASP.NET セッション状態は、実際の状態がサーバー側に格納され、HTTP 要求パスに沿ってクライアントやその他のネットワーク エンティティに公開されないという点で、クライアント状態管理手法よりも重要なセキュリティ上の利点を提供します。ただし、セッション状態の操作には、アプリケーションのセキュリティを維持するために考慮する必要がある重要な側面がいくつかあります。セキュリティのベスト プラクティスは、セッション ID のスプーフィングとインジェクションの防止、バックエンドでの状態ストレージの保護、および専用環境または共有環境でのセッション状態展開のセキュリティの確保という 3 つの主要なカテゴリに分類されます。
読む：セッション状態の保護
これはCookieではなく、ユーザーが変更できないため、完全に安全です。サーバー側でCookieに保存されるのは、セッションIDだけです。
他の回答が指摘しているように、実際の値 (例では 37) はクライアントではなくサーバーに保存されますが、それは潜在的な攻撃の影響を受けないという意味ではありません。このメカニズムは、クロス サイト スクリプティング攻撃に対して依然として脆弱です。基本的に、クライアントの Cookie に保存されるのは、大きな長い識別子です。実際のユーザー以外の誰かがその識別子を入手した場合、そのユーザーはそれを自分の Cookie に入れ、基本的にそのユーザーになりすますことができます。自分でクロス サイト スクリプティングをさらに調査して (私はこの分野の専門家ではありません)、悪意のあるユーザーが他のユーザーの Cookie を見て、それを自分の Cookie として設定しようとする一般的な方法をいくつか確認できます。 、およびそのような攻撃から防御する方法 (そのうちのいくつかはブラウザーと ASP によって行われると確信しています)。