概要
情報処理安全確保支援士を目指してCookieの属性を勉強していると、
どの属性がどういう用途なのか混乱してきたので整理。
Cookieの主なセキュリティ属性
| 属性名 | 概要 | 主な目的 |
|---|---|---|
| HttpOnly | JavaScriptからアクセスできなくする | XSS対策 |
| Secure | HTTPS通信でのみCookieを送信 | 通信の盗聴対策 |
| SameSite | クロスサイトからのリクエストでのCookie送信制御 | CSRF対策 |
※クロスサイト
Cookieの発行元以外のWebサイトにそのCookieを送信すること。
HttpOnly
ずばりクロスサイトスクリプティング（XSS）対策のための属性
XSSは簡単に言うと、攻撃者が用意したJavascriptをブラウザで実行してしまう攻撃
※XSSについてはこちらにまとめたので参考にしてもらえれば。
https://qiita.com/muramasa03/items/6e1ad421b12962103d22
Javascriptをブラウザで実行してしまったとき、スクリプトがCookieを利用できてしまうと
セッションIDなどの大事な情報が攻撃者に転送されてしまいかねない。
そもそもスクリプト内で
document.cookie
を実行するとアクセス可能なCookie一覧が取得できるのだが、
HttpOnly属性のCookieは一覧に含まれないので、スクリプトで利用されることがなくなる。
めも１
HttpOnly属性はスクリプトにCookieを使われることを防ぐものであって、スクリプトの実行自体を防ぐものではない。
スクリプトの実行防止は別の対策（CSPとか）が必要。
めも2
どうやらHttpOnly属性では、すべてのスクリプトからのCookie利用を禁止するしかできない模様。
（特定のスクリプトからは利用可能。。といった柔軟な設定はない。）
Secure
盗聴防止。「HTTPでの通信ではこのCookieを送信できないよ。HTTPSならOK」という属性。
セッションIDなど盗聴されると困るCookieに対して暗号通信を必須化したいときにSecure属性をつける。
試験で「Cookieの盗聴が」みたいな記載があればSecureを思い浮かべるとよさそう。
めも３
Secure属性はXSSには無力。
Javascriptはあくまでブラウザ内で実行されるので、HTTPSかどうかは関係ない。
そしてJavascriptはブラウザ内でCookie情報を取得した後、攻撃者のサイトにHTTPS通信で情報を送れてしまう。
SameSite
クロスサイトリクエストフォージェリ（CSRF）対策。
Secure属性を付与した場合、Cookieの平文での送信を防ぐ（HTTPSプロトコルに制限する）ことはできるが、
HTTPS通信であればどこにでも遅れてしまう。（攻撃者が用意したサイトにも送れちゃう。）
それでは困るのでCookieの送信先を制限するのが、SameSite。
SameSiteは3段階のセキュリティとなっている。
| 属性 | 仕様 |
|---|---|
| strict | Cookieの発行元にしか送信しない |
| lax | GETリクエストだけは許可 |
| none | すべて許可 |
strict
前提：
そもそもCookieはWebサイト（サーバ）側が発行するので、
そのCookieを発行したWebサイトが存在する。
仕様：
strictの場合、Cookieの発行元と送信先の以下3要素が完全一致する場合のみCookieを送信する。
・スキーム（http / https）
・ホスト（例：example.com）
・ポート番号（通常 http→80, https→443）
例：
"https://example.com" が発行したCookie情報は、"https://example.com" にしか送らない。
（"https://sub.example.com" とか "http://example.com" でも別物扱い。）
lax
仕様：
基本的にはstrict準拠。
ただし、Getリクエストのみは「Cookieの発行元と送信先が不一致でもOK」
補足：なぜGetだけ許すのか。
結論から書くとGetはPostリクエストより安全性が高いから。
例えば、SNSに銀行口座Webサイトのリンクが貼ってあり、リンクをクリックしたとする。
Postリクエストを許していたら、攻撃者口座に振り込みができてしまう。（データ操作）
Deleteリクエストを許せば、攻撃者口座への振込履歴を削除できてしまう。（データ削除）
と、被害が大きい。
一方で、Getリクエストは口座残高を取得される（データ取得）ものの、POSTとかより被害は小さい。
なので、利便性を優先しようという考えがLax。
例：
SNSに貼られた通販商品へのリンクをクリックした際にセッション情報の取得を許可することで
商品ページが表示される。（毎回ログインページに誘導されることはない。）
めも４
laxは”ゆるい”という意味の英単語。
None
何も制限しない！
そもそも属性ってどうやってつけるのか。
繰り返すが、Cookieを発行するのはWebサーバ側。
ブラウザからのHTTPリクエストに対して、WebサーバがセッションIDなどのCookieを発行した際、
HTTPレスポンスに
Set-Cookie: session_id=abc123; SameSite=Lax; Secure; HttpOnly
と表記することでsession_idというCookieの発行と属性付与を行うことができる。