Webセキュリティの小部屋

Twitter のフォローはこちらから Facebook ページはこちら Google+ページはこちら RSSフィードのご登録はこちらから
公開日:2013年3月9日

セッション管理の不備と対策

セッション管理をセッション ID と Cookie で行なっている Webアプリケーションでは、適切な対策を行なっていないと、セッション管理の不備で深刻な脆弱性が発生します。

■セッションハイジャック

session01

セッションハイジャックは、利用者が Webアプリケーションにログインした際に発行されるセッション ID を、ネットワーク上で盗聴されたり、規則性から類推されることで、攻撃者が利用者になりすます攻撃です。利用者のセッションを乗っ取ってしまうので、セッションハイジャックと呼ばれます。

■セッション ID の固定化(Session Fixation/セッションフィクセーション)

session02

セッション ID の固定化は、あらかじめ攻撃者が用意しておいたセッション ID を、ブラウザや Webアプリケーションの脆弱性などを利用してセッション ID を利用者に送り込み、利用者がログインした状態になった後、攻撃者が送り込んだセッション ID を利用してなりすます攻撃です。

セッションハイジャックやセッション ID の固定化によるなりすましは深刻で以下のような影響があります。

  • ログイン後の利用者のみが利用可能なサービスの悪用、情報の閲覧、改ざん、新規投稿

また、パスワード変更前にパスワードを要求しない Webアプリケーションの場合は、パスワードが変更されて完全にアカウントが乗っ取られてしまいます。

セッション管理の不備に対する根本的対策は以下のようになります。

  • 1.推測困難なセッション ID を利用する
  • 2.セッション ID を URL に含めない
  • 3.HTTPS 通信で利用する Cookie には secure 属性を付与する
  • 4-1.ログイン後にセッションを新規に開始する
  • 4-2.ログイン後にセッション ID とは別の秘密情報を持ち、各ページでその値をチェックする

4-1 と 4-2 はどちらか一方を対策すれば問題ありません。

 

■1.推測困難なセッション ID を利用する

セッション ID は推測困難な値にする必要があります。そのためには、独自実装するのではなく、あらかじめ安全性が実証されている実行環境のセッション ID 生成機能を利用するようにします。

■2.セッション ID を URL に含めない

セッション ID が URL に含まれていると、どのページから遷移してきたかブラウザが送信してくる Referer によってセッション ID が漏洩することがあります。セッション ID は Cookie に格納し、Cookie に格納できない場合にも URL にセッション ID が含まれないように設定しておきます。

■3.HTTPS 通信で利用する Cookie には secure 属性を付与する

Cookie に secure 属性を付与すると、HTTPS 通信時のみ Cookie の値を Webサーバーに送信するようになります。HTTPS 通信時のみ送信する重要な情報には secure 属性を付与するようにします。

■4-1.ログイン後にセッションを新規に開始する

ログイン後に、既存のセッション情報を破棄し、新しいセッション ID でセッションを開始します。

■4-2.ログイン後にセッション ID とは別の秘密情報を持ち、各ページでその値をチェックする

ASP.NET などの一部環境では、セッション ID を振り直すことができません。こうした環境では、セッション ID とは別に秘密情報を持ち、各ページでその値をチェックし、値が異なる場合はエラー画面に遷移させます。

この秘密情報は暗号論的擬似乱数生成器により作成されている必要があります。要件は CSRF の独自トークンを作成する方法と同様のため以下の記事を参考にしてください。


スポンサーリンク




カテゴリー:Webアプリケーションセキュリティ

Twitter でも、いろんな情報を発信しています。



コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA