セッション状態の保護
更新 : 2007 年 11 月
ASP.NET のセッション状態を使用すると、Web アプリケーションを構成する別の ASP.NET ページにユーザーが移動したときにユーザーの値を格納および取得できます。ASP.NET のセッション状態は、制限された時間ウィンドウ内での同一ブラウザからの要求を 1 つのセッションとして識別し、変数値をそのセッションの存続期間中保持できます。セッション状態が "Cookie なし" として構成されている場合、ブラウザ セッションは、セッションの Cookie、または URL で識別されます。
ASP.NET セッション状態は、すべての ASP.NET アプリケーションで既定で有効になり、セッション Cookie を使用してブラウザのセッションを識別するように構成されています。
ASP.NET セッション状態では、既定でメモリにセッション変数値が格納されますが、セッション変数値が状態サーバー、SQL Server、またはカスタムのセッション状態ストアに格納されるように構成することもできます。
コーディングと構成のベスト プラクティスに従うことでアプリケーションのセキュリティを強化できますが、Microsoft Windows およびインターネット インフォメーション サービス (IIS : Internet Information Services) の最新セキュリティ パッチ、および Microsoft SQL Server、Active Directory、およびアプリケーションのその他のデータ ソースのパッチを適用して、アプリケーション サーバーを最新の状態に保つことも重要です。
安全なコードの記述とアプリケーションのセキュリティ保護のためのベスト プラクティスの詳細については、Michael Howard と David LeBlanc 共著『Writing Secure Code』、および Microsoft Patterns and Practices が提供するガイダンス (https://www.microsoft.com/resources/practices/default.mspx) を参照してください。
安全なセッション状態の構成
セッション状態機能は既定で有効にされています。既定の構成は、最も安全な値に設定されていますが、アプリケーションに必要がない場合は、セッション状態を無効にする必要があります。セッション状態の構成設定とその既定値の詳細については、「sessionState 要素 (ASP.NET 設定スキーマ)」を参照してください。
構成値の保護
アプリケーションの構成ファイル内に機密情報を格納する場合は、プロテクト構成を使用して機密情報を暗号化する必要があります。特に慎重を要する情報としては、machineKey 構成要素に格納される暗号キーや、connectionStrings 構成要素に格納されるデータ ソース接続文字列などがあります。詳細については、「保護された構成を使用した構成情報の暗号化」を参照してください。
セッション状態データ ソースへの接続の保護
接続文字列
前述のとおり、SQL Server を実行するコンピュータ、セッション状態サービス、または別のデータ ソースへの接続文字列に格納されている機密情報を保護することは重要です。データ サーバーへの接続を安全に保つには、プロテクト構成を使用して構成内の接続文字列情報を暗号化することをお勧めします。詳細については、「保護された構成を使用した構成情報の暗号化」を参照してください。
統合セキュリティを使用した SQL Server への接続
接続文字列が危険にさらされ、ユーザー ID とパスワードが公開される可能性を回避するには、統合セキュリティを使用して SQL Server を実行しているコンピュータに接続する必要があります。統合セキュリティを使用する接続を指定して SQL Server を実行しているコンピュータに接続すると、セッション状態機能はプロセスの ID に戻ります。ASP.NET を実行しているプロセス (たとえばアプリケーション プールなど) の ID が既定のプロセス アカウントまたは制限付きのユーザー カウントであることを確認する必要があります。詳細については、「ASP.NET の偽装」および「セッション状態モード」を参照してください。
セッション ID の保護
アプリケーションとデータを保護する場合、セッション ID がネットワークを介して望ましくないソースに公開され、アプリケーションに対する再生攻撃で使用されることを防ぐことが重要です。次の作業を行ってセッション ID のセキュリティを強化することをお勧めします。
アプリケーションを SSL (Secure Sockets Layer) で保護します。
Timeout セッションにより小さい値を指定します。また、クライアント スクリプトを使用したり、次の例に示すように AddHeader メソッドを使用して更新ヘッダーを追加したりすることによって、セッションのタイムアウトと同じ長さのクライアントにリダイレクトを強制することも検討します。
Response.AddHeader("Refresh", Session.Timeout & ";URL=Logoff.htm" Response.AddHeader("Refresh", Session.Timeout + ";URL=Logoff.htm";Cookie なしのセッションは使用しないようにします。Cookie なしのセッションを指定する場合は、ユーザーにセッション ID を含むリンクの電子メールによる送信、ブックマークへの追加、または保存などを行わないように警告します。
AutoDetect と UseDeviceProfile の Cookie モードを指定しないようにします。
HttpSessionState.Abandon メソッドを呼び出す必要のある時点で、ユーザーがログアウトできるようにします。ユーザーにログアウト後はブラウザを閉じるように警告します。
Cookie なしのセッションを使用する場合、regenerateExpiredSessionID を true に設定して、有効期限が切れたセッション ID が提供された場合には必ず新しいセッションを開始するようにします。
セッション状態を使用する Web ページの保護
重要情報を扱うアプリケーション ページは、SSL を使用したり、個人情報の更新やアカウントの削除などの慎重を要する操作を実行する場合は、ユーザーにログインを求めたりするなど、標準的な Web セキュリティ機構を使用して保護する必要があります。
さらに、パスワードや場合によってはユーザー名などの機密機能データがクリア テキストでページに公開されないようにする必要があります。そのような情報を表示するページには SSL を使用し、認証されたユーザーのみが閲覧できるようにします。
エラー メッセージとイベント
例外
機密情報が望ましくないソースに公開されることを防ぐには、詳細なエラー情報を表示しないようにするか、またはクライアントが Web サーバーそのものであるときだけ詳細なエラー メッセージ情報を表示するように、アプリケーションを構成する必要があります。詳細については、「customErrors 要素 (ASP.NET 設定スキーマ)」を参照してください。
[イベント ログ]
サーバーが Windows Server 2003 を実行している場合、イベント ログをセキュリティ保護したり、イベント ログのサイズや保持期間などのパラメータを設定したりすることによってアプリケーションのセキュリティを強化し、アプリケーションに対する間接的なサービス拒否攻撃を防ぐことができます。
カスタム セッション状態ストア プロバイダ
カスタムのセッション状態ストア プロバイダを作成する場合は、セキュリティ上のベスト プラクティスに従って、データベースの操作時の SQL インジェクション攻撃などの攻撃を回避します。カスタムのセッション状態ストア プロバイダを利用する場合は、セキュリティ上のベスト プラクティスに従ってプロバイダを必ず点検します。