今回は、Webセキュリティ脆弱性の中のセッション管理に関する部分について、IPAの資料をもとにおさらいする。
セッション管理の不備
セッションIDの発行や管理に不備がある場合、悪意のある人にログイン中の利用者のセッションIDを不正に取得され、その利用者に成りすましてアクセスされてしまう可能性がある。
悪意のある人は、セッションIDの生成規則を割り出し、有効なセッションIDを推測する。また、わなを仕掛けたり、ネットワークを盗聴したり、利用者のセッションIDを盗みんだりする。
推測や盗用以外に、セッション管理の不備を狙ったもう一つの攻撃手法として、「セッションIDの固定化」と呼ばれるものがある。悪意のある人があらかじめ用意したセッションIDを、何らかの方法で利用者に送り込み、利用者がこれに気づかずにパスワードを入力するなどしてログインすると起こりうる問題。この攻撃に成功すると、あらかじめ用意したセッションIDを利用し、利用者に成りすましてウェブサイトにアクセスすることができてしまう。
発生し得る脅威
- ログイン後の利用者のみが利用可能なサービスの悪用
不正な送金、利用者が意図しない商品購入、利用者が意図しない退会処理 等 - ログイン後の利用者のみが編集可能な情報の改竄、新規登録
各種設定の不正な変更（管理者画面、パスワード等）、掲示板への不適切な書き込み 等 - ログイン後の利用者のみが閲覧可能な情報の閲覧
非公開の個人情報を不正閲覧、ウェブメールを不正閲覧、コミュニティ会員専用の掲示板を不正閲覧 等
注意が必要なウェブサイトの特徴
ログイン機能を持つウェブサイト全般に注意が必要な問題。
ログイン後に決済処理等の重要な処理を行うサイトは、攻撃による被害が大きくなるため、特に注意が必要。
- 金銭処理が発生するサイト
ネットバンキング、ネット証券、ショッピング、オークション 等 - 非公開情報を扱うサイト
転職サイト、コミュニティサイト、ウェブメール 等 - その他、ログイン機能を持つサイト
管理者画面、会員専用サイト、日記サイト 等
根本的解決
- セッションIDを推測が困難なものにする
セッションIDは、生成アルゴリズムに暗号論的疑似乱数生成器を用いるなどして、予測困難なものにする。セッション管理の仕組みが提供されるウェブアプリケーションサーバ製品を利用する場合は、その製品が提供するセッション管理の仕組みを利用している限り、自前でセッションIDを生成する必要はない。 - セッションIDをURLパラメータに格納しない
セッションIDをURLパラメータに格納していると、利用者のブラウザが、Referer送信機能によってセッションIDの含まれたURLをリンク先のサイトへ送信してしまう。悪意のある人にそのURLを入手されると、セッション・ハイジャックされてしまう。セッションIDは、Cookieに格納するか、POSTメソッドのhiddenパラメータに格納して受け渡しするようにする。
ウェブアプリケーションサーバ製品によっては、利用者がCookieの受け入れを拒否している場合、セッションIDをURLに格納する実装に自動的に切り替えてしまうものがある。そのような機能は、製品の設定変更を行うなどによって、自動切り替え機能を無効化することを検討する。 - HTTP通信で利用するCookieにはsecure属性を加える
ウェブサイトが発行するCookieには、secure属性という設定項目があり、これが設定されたCookieはHTTPS通信のみで利用される。Cookieにはsecure属性がない場合、HTTPS通信で発行したCookieは、経路が暗号化されていないHTTP通信でも利用されるため、このHTTP通信の盗聴によりCookie情報を不正に取得されてしまう可能性がある。HTTPS通信で利用するCookieにはsecure属性を必ず加える。かつ、HTTP通信でCookieを利用する場合は、HTTPSで発行するCookieとは別のものを発行する。 - ログイン成功後に新しくセッションを開始する
ウェブアプリケーションによっては、ユーザーがログインする前の段階（例えば、サイトの閲覧を開始した時点）でセッションIDを発行してセッションを開始し、そのセッションをログイン後も継続して使用する実装のものがある。しかし、この実装はセッションIDの固定化攻撃に対して脆弱な場合がある。このような実装を避け、ログインが成功した時点から新しいセッションを開始する（新しいセッションIDでセッション管理する）ようにする。また、新しいセッションを開始する際には、既存のセッションIDを無効化する。 - ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページの遷移ごとにその値を確認する
セッションIDとは別に、ログイン成功時に秘密情報を作成してCookieにセットし、この秘密情報とCookieの値が一致することを全てのページで確認するようにする。この秘密情報の作成にも、生成アルゴリズムに暗号論的疑似乱数生成器を用いるなどして、予測困難なものにする。
次の場合、本対策は不要。
・上記根本的解決4の実装方法を採用している場合
・セッションIDをログイン前には発行せず、ログイン成功後に発行する実装のウェブアプリケーションの場合
保険的対策
- セッションIDを固定値にしない
セッションIDは、利用者のログインごとに新しく発行し、固定値にしないようにする。 - セッションIDをCookieにセットする場合、有効期限の設定に注意する
Cookieは有効期限が過ぎるまでブラウザに保持される。このため、ブラウザの脆弱性を悪用する等何らかの方法でCookieを盗むことが可能な場合、その時点で保持されていたCookieが盗まれる可能性がある。
Cookieの有効期限を短い日時に設定し、必要以上の期間、Cookieがブラウザに保存されないようにする等の対策を取る。
なお、Cookieをブラウザに残す必要が無い場合は、有効期限の設定（expires=）を省略し、発行したCookieをブラウザ終了後に破棄させる方法もある。しかし、この方法は利用者がブラウザを終了させずに使い続けた場合は、期待する効果を得られない可能性がある。
詳しくは以下参照。
