セッション管理¶

セッション管理の前提知識¶

セッション管理とは

ブラウザはWebサーバ間で発生する任意のHTTPリクエスト／レスポンスのアクセスを一つの集合体として管理・制御する仕組みを指す。 HTTP通信では、クライアントがリクエストを投げて(コネクションを確立し)サーバがレスポンスを返す，

このキャッチボールを1往復したところで通信は切れるという、ステートレスなプロトコルであり、前回通信の状態を持たない。一方で、電子商取引サイトのような、ログインからログアウトまでの一連のリクエストに状態を持たせる必要がある場合、このままでは実現できない。

HTTPにはセッションという仕様はないが、JavaEEにはセッション管理機能がサポートされているため、サーブレットのHttpServletRequestからセッションIDという識別情報を取得し、ブラウザとWebサーバで交互にセッションIDをやりとりすることで、リクエストが同一セッションか否か、判別可能となる。同一セッションと判別されたリクエストにセッション情報を紐付けることで、前回リクエスト時の状態を持たせることが可能となる。

セッション管理の仕組み

セッション管理を実現するには、一般には以下のような方法が利用される。

セッション管理方法¶
方法	詳細
URLを利用	基本的な方式 (セッション・ハイジャック等のセキュリティ上の問題が多い)
Cookieを利用	最もポピュラーで基本的な方式 (マルチウィンドウ・マルチセッションは使用するブラウザによって不可)
hiddenフィールドを利用	画面単位にセッションIDを持たせる（マルチウィンドウ・マルチセッション*1を実現、セキュリティ上の問題が多い）
ワンタイムセッション	画面単位にセッションIDを持たせる（マルチウィンドウ・マルチセッション*1を実現）

Note

マルチウィンドウ・マルチセッション: 複数の画面が起動している状態で、起動画面別にHTTPセッションも別で管理されて動作していること
多重ログイン: 既にログイン済みでセッションが有効な画面が起動している状態で、新たに別の画面から同じユーザーでログインを行うこと

Cookieを利用

hiddenフィールドを利用
ワンタイムセッション

セッション管理の注意点

Cookieを利用したセッション管理の場合、注意する点はいくつかあるが、一般に考慮が必要となりそうな前提の技術情報を記載する。

ブラウザ種別によって、複数画面間でCookieのセッション情報(JSESSIONID)の共有・非共有状態が異なる

＜IE以外のブラウザの場合＞

Chormeは、画面単位でCookieを管理しているため、同じ端末上で別々のウィンドウ間でセッション情報が共有化されることはない。（マルチウィンドウ・マルチセッション可能） FireFoxも、設定によりマルチウィンドウ・マルチセッションが可能

＜IEの場合＞

Microsoftのセキュリティ上の方針により、IE8以降は同じ端末上の複数の画面間でCookieのセッション情報(JSESSIONID)を共有する仕様となっている。 (IE6,7はプロセス単位でCookie情報を管理しているため、マルチウィンドウ・マルチセッションが可能だった)

Note

IEのセッション情報共有については以下も参照のこと。

IE8 で別々のウィンドウでセッション情報が共有されてしまう問題

使用するプロセスの数

画面起動方法別、JSESSIONID共有化タイミングのパターン

複数画面のセッションオブジェクト(*)共有による、不整合が発生する(操作の辻褄が合わなくなる)パターン

(*) HttpSessionオブジェクトでセッション情報を管理する場合

セッション管理方式¶

ベースとするセッション管理方式は、Cookieを利用した一般的なセッション管理方式を採用する。セッション利用については、下記のセッション利用におけるメリット・デメリットを踏まえ、マルチタブによる操作性向上などのユーザビリティを考慮し、認証などで利用するユーザ情報のみをセッション共有し、画面遷移時にデータをリクエストパラメータで持ち回る方式とする。

セッション利用時のメリット・デメリットについて

＜メリット＞複数の画面(複数のリクエスト)をまたいで、データを持ち回ることができるため、ウィザード画面のような複数の画面で、1つ処理を構成する場合に、簡単にデータが持ち回れる等

＜デメリット＞

同一処理の画面を、複数のブラウザやタブで立ち上げた場合、互いの操作がセッション上に格納しているデータに干渉しあうため、データの整合性を保つことができなくなる。
データの整合性を保つためには、同一処理の画面を複数立ち上げることができないように、制御する必要がある。
データの整合性を保つための制御は、トランザクショントークンチェックを使用することで実現する事ができるが、ユーザビリティの低いアプリケーションとなってしまう。

Note

セッション管理のメリット・デメリットについては TERASOLUNA Guideline 「セッションの利用時のメリット・デメリット」も参照のこと。

また、セッションのライフサイクル管理は、イベントごとに以下の要領で、Spring Securityをベースとして、生成・破棄までを管理する。

No	イベント	詳細	備考
1	セッションの作成	spring-security.xml へセッション生成方法のオプションを指定する。 ※オプションは 6.5.2.4.1. セッションの作成「セッションの作成方針¶」方針を参照	脆弱性対策A、Dを参照
2	セッションの破棄	Spring Securityは以下のタイミングでセッションを破棄する。・ログアウト・認証処理が成功したタイミング（セッション固定攻撃対策として）	脆弱性対策B、E、Fを参照
3	セッションタイムアウトの指定	アプリケーションサーバーのサーブレットコンテナに対して行う。Servlet標準仕様で定められた指定方法(web.xml) か、アプリケーションサーバの機能を使ってセッションタイムアウトを検知する。	脆弱性対策E、Gを参照
4	無効なセッションを使ったリクエストの検知	SpringSecurityは無効なセッションを使ったリクエストを検知する機能を提供している。無効なセッションとして扱われるリクエストの大部分は、セッションタイムアウト後のリクエストである。	脆弱性対策Cを参照
5	多重ログインの制御	同じユーザー名(ログインID)を使った多重ログインを制御する機能を提供している。先勝ち、後勝ちの両方を選択できる。デフォルトは多重ログインの制御なし。
6	セッション利用時のセキュリティ対策（セッションハイジャック攻撃への対策）	推測困難なセッションIDの生成HTTPSを使って通信し、セッションIDはCookieを使って連携。CookieのHttpOnly属性指定（JavaScriptからCookieにアクセスできないように）CookieにSecure属性を指定 (HTTPS通信の時だけCookieをサーバーに送信する)	脆弱性対策Cを参照
7	セッション固定攻撃への対策	URL Rewriting 機能を無効可(デフォルト)有効可させると、Cookieが使用できないブラウザでURL内にJSESSIONIDが露出してしまう。ログイン後にセッションIDを変更する	脆弱性対策Bを参照
8	セッション情報の格納先	Spring Securityが用意しているデフォルト実装ではHTTPセッションを使用する。クラウド環境など複数のAPサーバからセッション情報を共有した場合は、SpringSessionを利用する。

AP層の脆弱性対策¶

セッションの利用にあたり、アプリケーションでは以下のような脆弱性対策を講じる。

No	タイトル	対策	解説
A	推測困難なセッションID	セッションIDの推測に伴うなりすましを防ぐため、他者に容易に推測されないよう、認証用セッションIDは次を満たした値を生成すること。・十分な長さの桁数・ユーザ毎かつセッション毎に異なるランダムな値	・十分な長さの桁数とは128bit以上。
B	セッション固定化攻撃対策	セッションIDの固定化攻撃に伴うなりすましを防ぐため、認証用セッションIDは、ログイン成功後に発行すること。	・ユーザがログインする前の段階で認証用セッションIDを発行し、その認証用セッションIDをログイン後も継続して使用する場合、セッションIDの固定化攻撃によって、他者になりすまされる可能性がある。・ログイン後にログイン前のセッションを引き継ぐ必要がある場合には、ログイン成功後に新たなセッションIDを発行し、ログイン前のセッションIDは無効化すること。
C	セッションIDの格納先	認証用セッションIDは、CookieもしくはPOSTメソッドのhiddenパラメータに格納して受け渡すこと。	認証用セッションIDをURLパラメータに格納した場合、ブラウザのReferer送信機能や、ファイアウォールやproxyサーバのログ等によって、認証用セッションIDが他者に漏えいし、セッション・ハイジャックによって他者になりすまされる可能性がある。
D	Cookieの設定	Cookieの盗用に伴うなりすましを防ぐため、認証用セッションIDを格納したCookieは、以下を満たすように設定すること。・有効期限はセッション限りとする。・パスとドメインは、Cookieを発行したURL（パス、ドメイン）と等しいか、より狭い範囲に制限する。・HTTPS通信で発行するCookieにはsecure属性を付与する。	Cookieのexpire/Max-Age属性を省略すると、Cookieの有効期限はセッション限りとなる。
E	セッションの破棄	セッションIDの推測に伴うなりすましを防ぐため、ユーザの連続無操作時間が一定時間続いた場合、認証用セッションをサーバ側で破棄すること。	一定時間の長さは、業務要件やアクセシビリティを考慮して決定すること。例えば、決済システムの場合は15分（PCIDSS 3.0より）。
F	セッションの終了	ユーザに対して、ユーザ自身がセッション終了できる機能（ログアウト機能）を提供すること	・ユーザが離席した際に、第三者に悪用されるリスクを低減するための対策。システム提供者の責務として実装すべきである。
G	システム管理者によるアクセスの終了/ロック	システム管理者の連続無操作時間が一定時間続いた場合、システム管理者との接続を終了もしくはロックすること	・一定時間は5分間以下とすることが望ましい。システムの業務要件に合わせて適切な時間を設定すること。・ロックは、セッションロック（アカウントロック）もしくは画面ロック（復帰時にパスワードの入力が必要なタイプ）を指している。システム管理者の操作環境（入退室管理の実施状況、リモート接続有無等）等に応じて、方法を検討すること。