title: “HTTP / Cookie / CORS / SameSite” part: “Part 2” chapter: “2-1”

HTTP / Cookie / CORS / SameSite

本章では、Web セキュリティの前提となる HTTP プロトコルと、状態管理・同一生成元制御に関わる要素（Cookie、CORS、SameSite）を整理する。特にブラウザベースの攻撃（XSS、CSRF など）を理解するためには、ブラウザがどのタイミングでどの情報を送出するかを正確に把握しておく必要がある。

本章のゴール

• 前提：HTTP リクエスト／レスポンス、ステータスコードの概念を理解している（Part 2 の前提範囲）。
• 到達目標：Cookie の主要属性（Domain / Path / Secure / HttpOnly / SameSite）と、CORS の基本動作・典型的な誤設定を説明できる。
• 対応演習：exercises/juice-shop/ または exercises/dvwa/ を Burp Suite 経由で操作し、Set-Cookie と CORS 関連ヘッダの挙動を観察する（起動手順は 付録「演習環境クイックスタート」 を参照）。

HTTP の基本

HTTP は原則としてステートレスなプロトコルであり、各リクエストは独立して処理される。代表的な要素は次のとおりである。

• メソッド：GET、POST、PUT、DELETE など
• ステータスコード：200 台（成功）、300 台（リダイレクト）、400 台（クライアントエラー）、500 台（サーバエラー）など
• ヘッダ：Host、User-Agent、Cookie、Authorization、Content-Type など

図2-1 は、1 回の HTTP の往復（リクエスト／レスポンス）と、Cookie によるセッション維持の最小構成を示す。Cookie 属性や CORS ヘッダも、まずは「リクエストに含まれるもの」「レスポンスで設定されるもの」を分けて整理すると理解しやすい。

図2-1: HTTP リクエスト／レスポンス概要図

sequenceDiagram
    participant B as Browser
    participant S as Web Server

    B->>S: GET /example HTTP/1.1\nHost: example.com\nCookie: session=...
    S-->>B: 200 OK\nSet-Cookie: session=...

    note over B,S: ステートレスなリクエスト／レスポンスのやり取り<br/>Cookie によりセッション状態を維持

Pentest では、HTTP トラフィックを正確に読み解くことが、脆弱性の有無を判断する基礎となる。Burp Suite 等のプロキシツールを用いて、「どのヘッダがどのように変更されると挙動が変わるか」を意識的に観察することが重要である。

Cookie と属性

HTTP がステートレスであるため、Web アプリケーションはログイン状態などの「セッション情報」を Cookie などの仕組みで維持する。Cookie はレスポンスヘッダ Set-Cookie でクライアントに送信され、以降のリクエストで Cookie ヘッダとして自動送信される。

主な属性は以下のとおりである。

• Domain：Cookie が送信されるドメイン範囲（例：example.com、.example.com）
• Path：Cookie が送信されるパス範囲（例：/app/）
• Secure：HTTPS 通信時にのみ Cookie を送信する
• HttpOnly：JavaScript（document.cookie）から参照できないようにする
• SameSite：クロスサイト環境での Cookie 送信を制御する（後述）

セッション ID を格納する Cookie については、少なくとも Secure と HttpOnly の付与が推奨される。これらが適切に設定されていない場合、平文通信や XSS を通じて Cookie が窃取されるリスクが高まる。

CORS（Cross-Origin Resource Sharing）

ブラウザは、同一生成元ポリシー（Same-Origin Policy, SOP）により、異なるオリジン間のリソースアクセスを制限している。ここでのオリジンは、「スキーム（http/https）」「ホスト」「ポート」の組み合わせで定義される。

CORS は、この制限を緩和するための仕組みであり、サーバ側が適切なレスポンスヘッダを返すことで、特定のオリジンからのクロスオリジンアクセスを許可できる。

代表的なヘッダは以下のとおりである。

• Access-Control-Allow-Origin
  許可するオリジン。* を安易に指定すると、意図せぬ情報共有が発生する恐れがある。
• Access-Control-Allow-Credentials
  Cookie を含む認証情報付きリクエストを許可するかどうか。
• Access-Control-Allow-Methods / Access-Control-Allow-Headers
  プリフライトリクエストに対する許可メソッドやヘッダの指定。

ブラウザは、Authorization ヘッダを付与するなど、いわゆる「シンプルリクエスト」に該当しない場合、事前にプリフライト（OPTIONS）で許可条件を確認する。プリフライトの結果が許可されない場合、ブラウザは実リクエストをブロックする。

図2-2 は、CORS のプリフライト（OPTIONS）と実リクエストの最小フローを示す。Pentest では、Origin の扱い（反射許可の有無）と、認証情報付きリクエスト（Access-Control-Allow-Credentials）が許可される条件を重点的に確認する。

図2-2: CORS プリフライトと認証情報付きリクエスト（概要）

sequenceDiagram
    participant B as Browser
    participant S as Server / API

    B->>S: Preflight (OPTIONS)\nOrigin: https://app.example\nAccess-Control-Request-Method: POST\nAccess-Control-Request-Headers: Authorization
    S-->>B: Preflight response\nAccess-Control-Allow-Origin: https://app.example\nAccess-Control-Allow-Methods: POST\nAccess-Control-Allow-Headers: Authorization\nAccess-Control-Allow-Credentials: true
    B->>S: Actual request (POST)\nOrigin: https://app.example\nCookie / Authorization: ...
    S-->>B: Response\nAccess-Control-Allow-Origin: https://app.example\nAccess-Control-Allow-Credentials: true\n(body)
    Note right of B: `Access-Control-Allow-Credentials: true` の場合、\n`Access-Control-Allow-Origin: *` は利用できない

CORS 誤設定は、単体で致命的な脆弱性になる場合もあれば、他の脆弱性（XSS 等）と組み合わせて情報漏えいを引き起こす「増幅要因」となる場合もある。Pentest では、以下の点を重点的に確認する。

• 認証が必要な API に対して、Access-Control-Allow-Origin: * が設定されていないか
• 任意のオリジンを反射して許可していないか（例：Origin ヘッダをそのまま返す実装）
• Access-Control-Allow-Credentials: true と * の組み合わせなど、仕様上禁止されている設定を行っていないか

SameSite 属性

SameSite 属性は、ブラウザがクロスサイト環境で Cookie を送信するかどうかを制御する仕組みであり、主に CSRF リスクの低減に用いられる。代表的な値は次の 3 つである（ブラウザ実装により挙動の差異あり）。

• Strict
  完全な同一サイトナビゲーション以外では Cookie を送信しない。UX への影響が大きいため、限定的な用途で用いられる。
• Lax
  トップレベルナビゲーションの GET など、一部のケースに限り Cookie を送信する。近年、多くのブラウザでデフォルト相当の挙動となっている。
• None
  クロスサイト環境でも Cookie を送信する。この場合は Secure 属性の付与が必須となる。

CSRF は「ユーザが意図しないリクエストに対して、ブラウザが Cookie を自動送信する」ことを悪用する攻撃であるため、SameSite を適切に設定することでリスクを一定程度低減できる。ただし、ブラウザ間での実装差異や、サブドメイン間の挙動など考慮すべき点も多く、SameSite の設定だけで完全な対策とはならない点に留意が必要である。

SameSite の詳細な挙動と CSRF との関係については、次節の「セッション管理と CSRF」で改めて整理する。

次に読む章

• セッション管理と CSRF

本章のポイント

• HTTP はステートレスであり、リクエスト／レスポンス、メソッド、ステータスコード、ヘッダを正確に読み解くことが Pentest の基礎である。
• Cookie はセッション維持の要であり、Secure / HttpOnly / SameSite などの属性設定が脆弱性の成立条件に直結する。
• CORS と SameSite はいずれもブラウザの制約と密接に関係し、誤設定は情報漏えい・CSRF などのリスクを増幅しうる。