Tweet

第7回 基礎のキソ、エブリバディ・セッション管理！

　セッション管理はHTTPの基本

　今回の勉強会は、Webアプリケーションにおけるセッション管理の基本の話が中心であった。

　Webアプリケーションでは、HTTPによって通信を行っている。しかし、HTTP通信ではブラウザからの要求（リクエスト）とサーバからの応答（レスポンス）を1つの単位として通信が完結する形となっているため、通常複数の通信間の関連性を管理することは困難である。そのため、Webアプリケーション（またはWebサーバ）レベルで管理番号のようなものを発行することで、複数にわたる通信間の関連性の管理を実現している。この仕組みを「セッション管理」と呼ぶ。

図1　セッション管理の概要

　このセッション管理を利用する代表的な例として｢ログイン状態の管理｣や「画面遷移状態の管理」が挙げられる。特に「ログイン」を必要とするサイトなどは、今日では非常に一般的なものとなっているため、セッション管理を理解することは、Webアプリケーションを正しく理解するために非常に重要な要素となる。

　セッション管理を行う際には管理番号のようなものを利用すると前述したが、これを一般的に「セッションID」と呼ぶ。システム上で一意となるセッションIDをユーザーのブラウザとWebアプリケーションで共有することによって、Webアプリケーションがユーザーを特定することが可能となる。共有する仕組みは、Cookieを利用するものと、GET／POSTパラメータなどを利用するものとで大きく2つに分けられる。いずれの仕組みもWebアプリケーション側がセッションIDを発行してユーザーへの送信を行い、ユーザーが以降のアクセスでそのセッションIDを毎回Webアプリケーションへ送信する形となる。

図2　HTTPリクエスト、レスポンスの例

　Cookieを利用したセッション管理では、ブラウザが自動でCookieを送信する仕組みを持っているので、Webアプリケーションの自由度が高くなるため採用されているケースが多い。GET／POSTパラメータなどを利用したセッション管理では、画面遷移をする際には必ず（リンクをクリックするときなどでも）セッションIDを送信する必要があり、安全にセッションIDを送信するための仕組みを組み込む必要がある。また、パラメータを使用したセッション管理は、画面遷移の自由度が低くなり、ユーザビリティの低下にもつながる場合がある。

　Cookieを利用したセッション管理では、Cookieはブラウザから自動で送信されるため、別のユーザーが同じURL（例えば、http://www.example.co.jp/MemberInfoなど）にアクセスをした場合でも、Webアプリケーション側で各ユーザーに合わせた情報を表示することができる。この性質は非常に便利であり、Webアプリケーションでリンクを作成する際に特別な処理が必要ない。また、外部サイトからの遷移でもセッション管理を行うことが可能となる。

　しかし便利な半面、Cookieだけに頼ってしまった場合、例えば登録情報の変更完了画面や掲示板のような画面でも同様に別のユーザーでアクセスを行った場合、別の処理を行ってしまうので、クロスサイトリクエストフォージェリ（CSRF）のような問題につながる場合もある。

図3　同じリンクをクリックした際の違うユーザーのリクエスト＋同じ登録情報変更の処理（クリックで拡大します）

　そのため、Cookieを利用したセッション管理でも、POSTパラメータなどでもセッション管理用の値を利用する必要がある。一般的に「トークン」と呼ばれるこのセッション管理用のパラメータは、第三者が推測できない値で、かつセッションIDと関連付けがなされているべきである。そうしておけば上記のようなクロスサイトリクエストフォージェリの問題は起きず、Webアプリケーション側でエラーとすることができる。

2/3

Index
基礎のキソ、エブリバディ・セッション管理！
	Page1 勉強、勉強、また勉強！ この業界は狭いのです
	Page2 セッション管理はHTTPの基本
	Page3 間違った認識は脆弱性のモト――でも何が間違いなの？

もいちどイチから！ HTTP基礎訓練中 連載インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード