セッション ハイジャックのしくみについて私が理解していることから、ASP.NET セッションにユーザー認証情報を保存するよりも、フォーム認証に利点があるとは思えません。フォーム認証と ASP.NET セッションは両方とも、整合性を検証するためにハッシュされた Cookie を使用しますが、どちらも Cookie を盗んでユーザーになりすますハッカーから保護することはできません。セキュリティに関する限り、ASP.NET セッションに認証情報を保存するよりもフォーム認証を使用する理由はありますか?
2 に答える
1
いくつかの違い:
認証情報をセッション状態に保存し、アプリ プールがリサイクルされると、すべてのユーザーが即座にログアウトされます。対照的に、フォーム認証は必要な情報をフォーム認証 Cookie に暗号化された形式で保持し、アプリ プールのリサイクルに耐えます。
セッション ID は 120 ビットの乱数です。唯一の保護はランダム性です。改ざん防止機能はありません。実際、ハッカーは、機能するセッション ID が見つかるまで、ランダムなセッション ID で Web サイトを継続的にポーリングする可能性があります。改ざんされたセッション ID と期限切れのセッション ID を区別することは不可能であるため、この種のアクティビティに対する侵入検知メカニズムはありません。
フォーム認証チケット (Cookie) はまったく異なります。これは、128 ビットのマシン キーで暗号化された長い文字列のデータで構成されています。誰かがそれを改ざんした場合、それは単に復号化されません。復号化の失敗はトラップ可能なエラーであり、侵入検知メカニズムに関与する可能性があります。チケットの全体的なカーディナリティははるかに高く、力ずくで攻撃するのが難しくなります。
私が最近使用したすべてのサイトで、フォーム認証メカニズムと ASP.NET_SessionId の両方を実際に使用しています。また、フォーム認証チケットに挿入する内部セッション ID (ESB セッション識別子) もあります。
于 2013-10-04T23:57:47.880 に答える
0
Sessionに認証情報を保存する代わりにFormsAuthenticationを使用することについて私が聞いた唯一の興味深い議論は、Forms Auth cookie（有効期限など）にさらに制限を加えることができるが、Sessioncookieには制限できないということでした。したがって、ユーザー設定などはセッションに残り、ユーザーが30分後に再度ログインするように強制されても失われることはありません。ええ、わかりません
于 2012-01-04T15:52:07.933 に答える