Webのセッションとは？一連の手続きの流れのこと
目次
Webのセッションとは？
Webにおけるセッションとは「ユーザーごとに行われる一連の処理の流れ」のことを指します。
例えばネットショッピング。
ネットショッピングは↓のようなセッションです。
ログインする
商品をカートにいれる
注文する
Webでは↑の1, 2, 3の流れのことをセッションと言います。
ちなみにWeb解析のセッションとは違う意味で使われます。
さて、なぜこの一連の流れに「セッション」などという名前が付いているのでしょうか？
ネットの仕組み
みなさんが使っているネットを構成するものの1つに「HTTP」というものがあります。
これはプロトコルと呼ばれるもののひとつで、プロトコルとは「約束事」という意味です。
なんの約束事かと言うと、ブラウザにテキストを表示するための約束事です。
サイトにアクセスしてブラウザにテキストを表示するとき、↓のような約束事が行われます。
ブラウザがサーバーにリクエストを送る
サーバーがブラウザにレスポンスを返す
ブラウザが画面にレスポンスを表示する
ブラウザを使ったネットサーフィンでは↑のような過程を経て、サイトの内容がブラウザに表示されるわけです。
これをHTTPと言います。
ステートレスなHTTP
このHTTPですが、ブラウザがリクエストを出してサーバーからレスポンスを貰うと、そこで終了です。
つまり、別のページでも全く同様のことが行われますが、HTTPは前の状態を記憶しません。
これを「ステートレス（状態が無い）」と言います。
HTTPはステートレスなプロトコルなわけですね。
ですので、このHTTPだけではネットショッピングのような次々とページが切り替わっても状態が維持される仕組みは実現できないということになります。
そこで考え出されたのがCookieとセッションです。
Cookieとは
Cookie（クッキー）とはサーバーがブラウザに発行するデータが入ったファイルのことです。
このファイルはブラウザで一定期間保存されます。
データとはたとえばユーザーIDや何かのキーとかの文字列です。
サーバーはHTTPレスポンスのヘッダにこのCookieのデータを仕込み、ブラウザに読み取らせます。
このデータは「名前=値」の形で記述されます。
ブラウザはサーバーにリクエストを送るときに、このCookieのデータをリクエストのヘッダに仕込み送信します。
こうしてサーバーとブラウザの間で保存されたデータをやり取りできるようになり、HTTPを使いながら状態が持てるということになります。
Cookieの安全性
Cookieは機密性の高い情報の保存には向いていません。
なぜかというとブラウザを使うユーザーが簡単に中身を見ることができるからです。
たとえばCookieにパスワードを保存したとします。
そのパスワードはハッシュ化などされずに平文のままCookieに保存されていたとします。
そして、あなたの友人があなたのパソコンを借りてブラウザを使用したとします。
友人は何かのはずみでクッキーの中身を見てしまい、結果的にあなたのパスワードが第三者に漏れてしまうことになります。
セッションとは
セッションとは先ほども説明しましたが「一連の処理の流れ」ことです。
そしてその流れを具体的に実現するために次のようなことをします。
それはサーバー側で「セッションID」をブラウザに発行し、ブラウザにそのセッションIDを保存させます。
そしてHTTPのリクエストでブラウザからそのセッションIDをサーバー側に送信させます。
サーバーはそのセッションIDを受け取り、そのセッションIDを持つユーザーの状態をサーバー側で復元します。
サーバーからブラウザにセッションIDを発行
ブラウザ側でセッションIDを保存
ブラウザからサーバーへセッションIDを送信
サーバー側でセッションIDのユーザーの状態を復元
このような仕組みにすることで、サーバー側でユーザーの状態を復元できるようにします。
セッションIDとは
セッションIDとはサーバーがユーザーに発行する文字列のことです。
これは第3者に推測されにくい英数字が入り混じった長い文字列です。
このセッションIDはユーザーがセッションを開始すると発行されます。
サーバーはユーザーのセッションを、このセッションIDを見て認識します。
セッションIDのやり取り
ここで問題になるのがサーバとブラウザにおけるセッションIDのやり取り方法です。
セッションIDが第3者に漏れると、セッションハイジャックなどの攻撃対象になってしまいます。
セッションIDのやり取りで代表的な方法に以下があります。
URLリライティング
HTTP Cookie
hiddenフィールド
URLリライティング
URLリライティングとはURLにセッションIDを含める方法です。
当然ながらセッションIDは丸見えです。
ショルダーハックなどでセッションIDを盗み見られる可能性があります。
HTTP Cookie
CookieにセッションIDを保存する方法です。
サーバーはブラウザに発行したCookieにセッションIDを埋め込み、ブラウザはそのセッションIDをリクエストでサーバーに送信します。
ショルダーハックなどの危険性はありませんが、たとえば友人のパソコンを借りてショッピングサイトにアクセスし、自分のアカウントにログインなどした場合に、そのパソコンのブラウザにセッションIDが記録されることになります。
そうなると、何かの拍子でその友人に自分のセッションIDが漏れる可能性も出てきます。
| （^ _ ^） | 他人のパソコンでログインしないように |
また、CookieはHTTPでやり取りされるため、機密性の低い通信では第3者に通信内容を盗聴される可能性も出てきます。
そうなると盗聴されてセッションIDが盗み見られるという可能性もあります。
Cookieのsecure属性を指定すればHTTPSなどの機密性の高い通信時のみにCookieの送信を許可することができます。
Cookieを使う場合secure属性の利用を検討しましょう。
Cookieを使ったセッションIDのやり取りは多くのWebフレームワークで一般的に行われています。
hiddenフィールド
WebページのフォームのhiddenフィールドにセッションIDを埋め込む方法です。
ページの遷移の時はフォームのhiddenフィールドのセッションIDがサーバーに送信されます。
サーバーはそのセッションIDでユーザーの状態を復元し、次のページのフォームにセッションIDを埋め込みます。
通信がHTTPのときはやはりセッションIDの盗聴の恐れがあります。
HTTPSによる通信が必須です。
セッションデータの保存
セッションに利用されるデータはサーバー側のファイルやDBに保存されるのが一般的です。
このデータはセッションIDと紐付けられており、セッションIDから任意に取得可能です。
フレームワークによってはこのデータに簡単にアクセスできる機能を提供しています。
たとえばPythonのフレームワークのDjangoではrequest.sessionからセッションデータの編集を行うことが可能です。
def view(request): request.session['user_name'] = 'Taro' user_age = request.session['user_age']
DjangoのセッションはデフォルトでDBにデータが保存されます。