今回はCookie、セッションに関して色々調べたのでまとめたいと思います。

ステートフルとステートレス

HTTPはシンプルなプロトコルで特徴としてステートレスであると言うことが挙げられます。

ステートレスとは状態を保持しないと言う意味で、HTTPではリクエスト/レスポンスの一往復のやりとりが完結した処理とみなされます。

つまり、複数の処理を関連づける仕組みがありません。

一方、ステートフルと言う言葉があります。ステートフルは状態を保持しておき、次の処理に反映させるような方式のことを言います。

これを見ると、ステートフルの方が便利に見えますが、サーバーは一度に多くのクライアントとやり取りをしなければならないために、常に全てのクライアントの状態を保持しなければならないとなると非常に負担が大きくなってしまいます。

これらを踏まえHTTPは、多数のクライアントが接続し、多くの処理を素早くこなさなければならないので、状態を保持することなく要求された内容を応答するだけのステートレス設計が向いていると言えます。

それぞれ特徴をまとめてみると

メリット/デメリット

・ステートレス
メリット→多くの処理を素早く処理できる
デメリット→状態を保持できない
活用されているプロトコル→HTTP、UDP、IP、DNS
（TCPはデータが届いたか確認するプロトコル、UDPはyoutubeみたいに送りっ放し）

・ステートフル
メリット→状態を保持することができる。1対1のやりとりなら十分。
デメリット→多くの処理を処理するには負担が大きい
活用されているプロトコル→FTP、TCP、BGPなど

しかし、Webが進化するにあたってステートレスでは困る状況が増えてきました。

何だかわかりますか？

ショッピングサイトで例えます。ショッピングサイトでは「商品を選ぶ」「商品を買い物カゴに入れる」「買い物カゴの中身を確認する」「商品を購入する」などといった動作はWebサーバーから見るとWebブラウザからの異なる動作（HTTPリクエスト）になります。そのために、商品を買い物カゴに入れるという動作をしたとしても「商品を買い物カゴに入れた」という状態を保持できないため、次の動作で商品の買い物カゴを確認したとしても商品が入っていないということになってしまいます。

しかし、実際のショッピングサイトでは、買い物カゴに入れた商品を確認したり、商品を購入できたりします。これはHTTPを補完する別の仕組みとして、以前の状態を踏まえた上で次の動作をするといった、状態を保持し管理する仕組み、Cookieやセッションが導入されているからです。

Cookieとセッション

クッキーはWebサーバーが発行し、ブラウザ内に保存される小さなテキストデータのことです。ブラウザは同じサイトにアクセスする際には、そのサイトが発行したクッキーをWebサーバーに送ります。会員証みたいなイメージです。

そしてセッションは一連の関連ある処理をサーバ内に保存しておくものになります。この保存されたユーザ情報と紐づいたセッションIDというものがサーバーで発行されます。このセッションIDをCookieに格納し、レスポンスをします。リクエストの際にはサーバーはこのセッションIDを見て、どのユーザーなのか？どんなユーザー情報を持っているのか？などを確認します。

わざわざ、セッションを使用しているのは、保存先を見てもらえばわかるかもしれません。Cookieにユーザーのidを記載しておくと、Cookieはブラウザに保存されているので改竄することができてしまいます。しかし、セッションはサーバー側で保存されていること。セッションIDはハッシュになっていることから改竄は難しいと言えます。

cookieの送信方法

Cookieの送信方法ではメッセージヘッダー（HTTPヘッダ）が利用されます。

メッセージヘッダーって何だ？て思ったので調べました。

HTTPリクエストの中身は３つに分けることができます。それは「リクエスト行」「メッセージヘッダー」「メッセージボディ」の三つです。

①リクエスト行ではサーバーに対してどのような処理をして欲しいのかというリクエストの内容記述しており、具体的には「情報を取得したい」とか「情報を送信したい」といった情報を伝えます。
ex) GET/index.html HTTP/1.1

②メッセージヘッダーではWebブラウザの種類やバージョン、対応するデータ形式・データの圧縮方法・言語など付加的な情報を記述しています。

③Webサーバーにデータを送るための用途。メッセージボディではWebページのフォーム欄などに入力したテキストデータなどをWebサーバーに送る目的で使用されます。空白行は一行空けることでメッセージヘッダーの終わり伝える役割を担っています。

HTTPレスポンスの方も同様に３つに分けることができます。「ステータス行」「メッセージヘッダー」「メッセージボディ」です。

①ステータス行ではWebブラウザから受け取ったHTTPリクエストに対してWebサーバー内での処理結果を伝えます。
ex) HTTP/1.1 200 ok

②メッセージヘッダーではWebサーバーの種類や送信するデータの形式など付加的な情報を記述しています。

③メッセージボディにはWebブラウザからリクエストされたHTMLが格納されています。

WebサーバーはHTTPレスポンスにSet-cookieヘッダーを含めることでCookieを送信することができます。対して、WebブラウザはHTTPリクエストにCookieヘッダーを含めることで送信ができます。Set-cookieヘッダーにオプションでCookieの有効期限を設定したり、またHTTPSのみを使用してCookieを送信する設定も可能です。

セッションcookie

有効期限が設定されていないCookieはwebブラウザが閉じられようとすると同時に削除されます。このようなCookieのことをセッションCookieと呼びます。

対して、有効期限が設定されたCookieはWebブラウザが閉じられても削除されず有効期限がくるまでWebブラウザに残ります。

トラッキングcookie

Cookieの発行元は２種類あります。1st Party Cookie ,3rd Party Cookieです。

1st party Cookieは訪問先のWEBサイト（ドメイン）から発行されるCookieで、主に訪問先のWEBサイトのアクセス履歴などが保存されています。(ECサイトなど)

3rd Party Cookieは訪問先のサイト以外から発行されるもののことを言います。バナー広告などは3rd party Cookieを使用していることが多いです。

バナー広告には訪問したWEBサイトとは別の、広告出稿企業のドメインからCookieが発行されブラウザに保存されます。後日、同様の広告出稿企業のバーナー広告を含んだWEBサイトに訪問した際にユーザーが興味を持つ商品に関してのバーナー広告が表示されるという仕組みでして、トラッキングCookieとも呼ばれるそうです。

セキュリティ問題

最後にセキュリティ問題に関してご紹介したいと思います。

セッションハイジャック

ログインしてから利用するようなWebシステムでは、CookieやセッションIDを使って、アクセスしてきたユーザーがログイン済みか？どんなユーザーなのか判断します。そのため、何らかの手段で第三者がCookieの中身やセッションIDを取得できれば、ユーザーIDやパスワードを知らなくてもその情報を使ってログイン済みのユーザーとしてそのシステムを利用できるようになり、容易に個人情報を取得されてしまいます。これをセッションハイジャックと言います。

クロスサイトスクリプティング(XSS)

掲示板サイトのような、ユーザーの入力内容を表示するタイプのWebサイトの脆弱性を突く攻撃のことです。

攻撃者が「脆弱性を持つWebサイトに対してスクリプトを書き込む」リンクを表示するWebページを公開したとします。そのリンクにアクセスしてしまうと、脆弱性のあるWebサイトを介してスクリプトがユーザーのWebブラウザに送り込まれ、クライアントサイド・スクリプトとして実行されてしまいます。送り込まれるスクリプトとしては、セッションハイジャックのためのCookie情報を公開するものやウイルスをダウンロードするものなどがあります。

【参考記事】
この一冊で全部わかるWeb技術の基本（書籍）
Webを支える技術 -HTTP、URI、HTML、そしてREST （書籍）
https://cybersecurity-jp.com/security-measures/18427