安全なウェブサイトの作り方 - 1.4 セッション管理の不備

概要

ウェブアプリケーションの中には、セッションID（利用者を識別するための情報）を発行し、セッション管理を行っているものがあります。このセッションIDの発行や管理に不備がある場合、悪意のある人にログイン中の利用者のセッションIDを不正に取得され、その利用者になりすましてアクセスされてしまう可能性があります。この問題を悪用した攻撃手法を、「セッション・ハイジャック」と呼びます。

また、推測や盗用以外に、セッション管理の不備を狙ったもう一つの攻撃手法として、「セッションIDの固定化（Session Fixation）」と呼ばれる攻撃手法があります。悪意ある人があらかじめ用意したセッションIDを、何らかの方法（脚注1）で利用者に送り込み、利用者がこれに気付かずにパスワードを入力するなどしてログインすると起こりうる問題です。悪意のある人がこの攻撃に成功すると、あらかじめ用意したセッションIDを利用し、利用者になりすましてウェブサイトにアクセスすることができてしまいます。

発生しうる脅威

セッション管理の不備を狙った攻撃が成功した場合、攻撃者は利用者になりすまし、その利用者本人に許可されている操作を不正に行う可能性があります。具体的には、次の脅威が発生します。

ログイン後の利用者のみが利用可能なサービスの悪用: 不正な送金、利用者が意図しない商品購入、利用者が意図しない退会処理等

ログイン後の利用者のみが編集可能な情報の改ざん、新規登録: 各種設定の不正な変更（管理者画面、パスワード等）、掲示板への不適切な書き込み等

ログイン後の利用者のみが閲覧可能な情報の閲覧: 非公開の個人情報を不正閲覧、ウェブメールを不正閲覧、コミュニティ会員専用の掲示板を不正閲覧等

注意が必要なウェブサイトの特徴

運営主体やウェブサイトの性質を問わず、ログイン機能を持つウェブサイト全般に注意が必要な問題です。ログイン後に決済処理等の重要な処理を行うサイトは、攻撃による被害が大きくなるため、特に注意が必要です。

金銭処理が発生するサイト: ネットバンキング、ネット証券、ショッピング、オークション等

非公開情報を扱うサイト: 転職サイト、コミュニティサイト、ウェブメール等

その他、ログイン機能を持つサイト: 管理者画面、会員専用サイト、日記サイト等

届出状況

セッション管理の不備に関する届出がウェブサイトの届出全体に占める割合は、数パーセントと多くはありません。しかしながら、これらの脆弱性については受付開始当初から継続して届出を受けています。下記は、IPAが届出を受け、同脆弱性の対策が施されたソフトウェア製品の例です。

根本的解決

4-(i) セッションIDを推測が困難なものにする。

セッションIDが時刻情報等を基に単純なアルゴリズムで生成されている場合、その値は第三者に容易に予測されてしまいます（脚注2）。利用者がログインするタイミングで発行されるセッションIDの値を悪意ある人によって推測されると、悪意ある人がそのセッションID を使って利用者になりすまし、本来は利用者しかアクセスできないウェブサイト等にアクセスできてしまいます。セッションIDは、生成アルゴリズムに暗号論的擬似乱数生成器を用いるなどして、予測困難なものにしてください。

セッション管理の仕組みが提供されるウェブアプリケーションサーバ製品を利用する場合は、その製品が提供するセッション管理の仕組みを利用している限り、自前でセッションIDを生成する必要はありません。自前でセッション管理の仕組みを構築しようとせず、そうしたウェブアプリケーション製品を利用することをお勧めします。

4-(ii) セッションIDをURLパラメータに格納しない。

セッションIDをURLパラメータに格納していると、利用者のブラウザが、Referer送信機能によって、セッションIDの含まれたURLをリンク先のサイトへ送信してしまいます。悪意ある人にそのURLを入手されると、セッション・ハイジャックされてしまいます。セッションIDは、Cookieに格納するか、POSTメソッドの hiddenパラメータに格納して受け渡しするようにしてください。

なお、ウェブアプリケーションサーバ製品によっては、利用者がCookieの受け入れを拒否している場合、セッションIDをURLパラメータに格納する実装に自動的に切り替えてしまうものがあります。そのような機能は、製品の設定変更を行う等によって、自動切り替え機能を無効化することを検討してください。

4-(iii) HTTPS通信で利用するCookieにはsecure属性を加える。

ウェブサイトが発行するCookieには、secure属性という設定項目があり、これが設定されたCookieはHTTPS通信のみで利用されます。Cookieにsecure属性がない場合、HTTPS通信で発行したCookieは、経路が暗号化されていないHTTP通信でも利用されるため、このHTTP通信の盗聴によりCookie情報を不正に取得されてしまう可能性があります。HTTPS通信で利用するCookieにはsecure属性を必ず加えてください。かつ、HTTP通信でCookieを利用する場合は、HTTPSで発行するCookieとは別のものを発行してください。

4-(iv)-a ログイン成功後に、新しくセッションを開始する。

ウェブアプリケーションによっては、ユーザがログインする前の段階（例えばサイトの閲覧を開始した時点）でセッションIDを発行してセッションを開始し、そのセッションをログイン後も継続して使用する実装のものがあります。しかしながら、この実装はセッションIDの固定化攻撃に対して脆弱な場合があります。このような実装を避け、ログインが成功した時点から新しいセッションを開始する（新しいセッションIDでセッション管理をする）ようにします。また、新しいセッションを開始する際には、既存のセッションIDを無効化します（脚注3）。こうすることにより、利用者が新しくログインしたセッションに対し、悪意のある人は事前に手に入れたセッションIDではアクセスできなくなります。

4-(iv)-b ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページの遷移ごとにその値を確認する。

セッションIDとは別に、ログイン成功時に秘密情報を作成してCookieにセットし、この秘密情報とCookieの値が一致することを全てのページで確認する（脚注4）ようにします。なお、この秘密情報の作成には、前述の根本的解決 4-(i) の「セッションIDを推測が困難なものにする」と同様の生成アルゴリズムや、暗号処理を用います。

ただし、次の場合には本対策は不要です。

上記根本的解決 4-(iv)-a の実装方法を採用している場合
セッションIDをログイン前には発行せず、ログイン成功後に発行する実装のウェブアプリケーションの場合

保険的対策

4-(v) セッションIDを固定値にしない。

発行するセッションIDが利用者ごとに固定の値である場合、この情報が攻撃者に入手されると、時間の経過に関係なく、いつでも攻撃者からセッション・ハイジャックされてしまいます。セッションIDは、利用者のログインごとに新しく発行し、固定値にしないようにしてください。

4-(vi) セッションIDをCookieにセットする場合、有効期限の設定に注意する。

Cookieは有効期限が過ぎるまでブラウザに保持されます。このため、ブラウザの脆弱性を悪用する等何らかの方法でCookieを盗むことが可能な場合、その時点で保持されていたCookieが盗まれる可能性があります。Cookieを発行する場合は、有効期限の設定に注意してください。　たとえば、Cookieの有効期限を短い日時に設定し、必要以上の期間、Cookieがブラウザに保存されないようにする等の対策をとります。

なお、Cookieをブラウザに残す必要が無い場合は、有効期限の設定（expires=）を省略し、発行したCookieをブラウザ終了後に破棄させる方法もあります。しかし、この方法は、利用者がブラウザを終了させずに使い続けた場合にはCookieは破棄されないため、期待する効果を得られない可能性があります。

以上の対策により、セッション・ハイジャック攻撃に対する安全性の向上が期待できます。セッション管理に関する情報については、次の資料も参考にしてください。

脚注

(脚注1) 用意したセッションIDを利用者に送り込むことができてしまうのは、次のいずれかに該当する場合です。
- 1.ウェブアプリケーションがセッションIDをPOSTメソッドのhiddenパラメータに格納して受け渡しする実装となっている場合
- 2.ウェブアプリケーションがセッションIDをCookieに格納して受け渡しする実装となっている場合で、利用者のウェブブラウザが、ドメインをまたがったCookie のセットができてしまう「Cookie Monster（※1）」と呼ばれる問題を抱えている場合
- 3.ウェブアプリケーションがセッションIDをCookieに格納して受け渡しする実装となっている場合で、ウェブアプリケーションサーバ製品に、「Session Adoption（※2）」の脆弱性がある場合
- 4.ウェブアプリケーションにクロスサイト・スクリプティング(後述1.5参照)等他の脆弱性がある場合

(脚注2) 3.4のよくある失敗例1～2を参照。(PDF:2.2 MB)

(脚注3) ログイン後にログイン前のセッション情報を引き継ぐ必要がある場合には、セッションデータのコピー方式に注意が必要です。オブジェクト変数を浅いコピー(shallow copy)で引き継いだ場合、ログイン前セッションとログイン後セッションが、同一のデータを共有して参照することになり、ログイン前のセッションIDによるアクセスで、ログイン後セッションのデータの一部を操作できてしまう危険性があります。また、ログイン後セッションのデータを、ログイン前のセッションIDによるアクセスで閲覧できてしまうことが、脆弱性となる場合も考えられます。これを防止するには、深いコピー(deep copy)で引き継ぐ方法も考えられますが、それだけではデータベースへの参照の共有や、一時ファイルへの参照の共有等が残り、脆弱性となる場合もあると考えられるので、ログイン成功時にログイン前のセッションを破棄する方法をお勧めします。
(脚注4) 一部のウェブアプリケーションサーバ製品では、このような処理を自動的に行う実装のものもあります。