今さら聞けないCookieとセッション
ーー Cookieに詰めた値を取り回せば出来るんじゃない？
ーー 認証情報はセッションを使えばいいんじゃない？
Cookieやセッション、なんとなく知っているけどもセットで語られることが多く、Cookieが実際何をしてくれているのか、セッションは何をするものなのか、ちゃんと理解していない私がいたことに気づきました。
Cookieセッション、それぞれを調べて簡単にまとめてみました。
Cookie
WebサーバからWebブラウザへ送ることのできる小さな情報。
HTTPレスポンスヘッダを利用して送られる。（Webサーバ → Webブラウザ）
Webブラウザに保存された情報はサーバにアクセスするたびにサーバに自動送信される。
Webサーバ側では、Webブラウザから送られたCookieから情報を取り出して利用する。
HTTPリクエストのヘッダを利用して送られる。（Webブラウザ → Webサーバ）
名前=値 の組み合わせで構成される。
Cookie: user=hoge; _ga=GA1.1.XXXXXXXXXX.XXXXXXXXXX
属性
属性を設定してCookieの振る舞いを変えることができる。
Domain=<domain-value>
設定したドメイン配下の場合のみサーバにCookieが送られる。
ドメインの設定がない場合はCookieを生成したサーバにのみCookieが送られる。（推奨）
Path=<path-value>
設定したパス配下の場合のみサーバにCookieが送られる。
Expires=<date>
Cookieの有効期限を設定する。
設定しない場合はセッションクッキーの寿命になる。
SameSite=<samesite-value>
クロスサイトリクエストでCookieを送信するか制御する。
- Strict
- 同一サイトのリクエストに対してのみCookieを送信する。
- Lax（標準）
- 画像やフレームの読み込みによるクロスサイトリクエストでは送信されない。
- 外部サイトから元のサイトへのリンク遷移時には送信される。
- None
- クロスサイト/同一サイト両方でCookieを送信する。
参考
セッション
ユーザを判定する情報をCookieに入れて管理する？
→ 顧客IDが欲しいから顧客IDをCookieに入れよう
→ 課金状態が欲しいから課金フラグをCookieに入れよう
→ 顧客名が欲しいから顧客名をCookieに入れよう
→ 性別が欲しいから性別をCookieに入れよう
→ 電話番号が欲しいから電話番号をCookieに入れよう
ほんとうに？
Cookieによるセッション管理
- Cookieが保持できる値の個数や文字列長には制限がある
- Cookieの値は参照・変更できるので機密情報の保持には向かない
じゃあどうするの？
→ 「整理番号」としてのセッションIDをCookieに保持しておき、実際の値はサーバ側に置いておく
セッションID
- 推測できない値にすること
- フレームワークや言語の機能で生成すること
- URLにセッションIDを埋め込む方法だとReffererヘッダを通して外部に漏洩する恐れあり
脆弱性
セッションアダプション
参考： https://gihyo.jp/dev/serial/01/php-security/0025
ブラウザ等から送信された未初期化セッションIDをそのまま利用してセッションを初期化してしまう脆弱性。
Discussion