実務で使えるペネトレーションテスト大全

セッション管理と CSRF

本章では、Web アプリケーションの認証状態を維持する仕組みとしての「セッション管理」と、その前提を悪用する攻撃である CSRF（Cross-Site Request Forgery）について整理する。

本章のゴール

  • 前提：Cookie ベースの認証とセッションの概念、および SameSite の概要（前章）を把握している。
  • 到達目標：セッション管理の確認観点（再発行、無効化、タイムアウト等）と、CSRF の成立条件・代表的対策を説明できる。
  • 対応演習：exercises/dvwa/ などで、ログイン前後の Cookie 変化や、CSRF 対策（トークン、SameSite 等）の有無を確認する。
    起動手順は 付録「演習環境クイックスタート」 を参照し、観察結果は 学習ログテンプレート（Burp Academy / 演習） に記録する。

セッション管理の基本

多くの Web アプリケーションでは、ユーザー認証後に「セッション ID」を発行し、それを Cookie などを通じてクライアントと共有することでログイン状態を維持する。

代表的な設計パターンは以下のとおりである。

  • サーバサイドセッション
    セッション ID はランダムなトークンとしてのみ意味を持ち、実際のユーザー情報や状態はサーバ側ストア（メモリ、RDB、KVS など）に保持する。
  • トークンベースセッション
    JWT 等のトークンにユーザー情報や権限情報を埋め込み、サーバ側は署名検証のみによって状態を確認する（詳細は次節）。

Pentest の観点では、セッション管理において次の点を確認する。

  • セッション ID の推測困難性（十分な長さとエントロピーがあるか）
  • ログイン直後や権限昇格時にセッション ID の再発行（Session Fixation 対策）が行われているか
  • ログアウト時やパスワード変更時に、古いセッションが無効化されるか
  • タイムアウト（アイドルタイムアウト／絶対タイムアウト）が適切に設定されているか

セッションハイジャックと Session Fixation

セッション管理に関連する代表的な攻撃として、次のようなものがある。

  • セッションハイジャック
    XSS やネットワーク盗聴などにより、正当なユーザーのセッション ID を窃取し、そのままなりすます攻撃。
  • Session Fixation
    攻撃者が事前に発行させたセッション ID を被害者に利用させ、ログイン後も同じ ID が継続使用されることで、攻撃者がそのセッションを引き継ぐ攻撃。

Session Fixation 対策としては、「ログイン成功時に必ず新しいセッション ID を発行する」ことが基本となる。Pentest では、ログイン前後で Cookie の値が適切に変化するかを確認する。

CSRF の成立条件

CSRF は、認証済みユーザーに成り代わって、攻撃者が意図するリクエストをターゲットサイトに送信させる攻撃である。典型的な成立条件は次のとおりである。

  • ユーザーがターゲットサイトにログインし、ブラウザが有効なセッション Cookie を保持している
  • ターゲットサイトが、状態変更を伴うリクエスト（例：振込、メールアドレス変更）を Cookie ベースの認証のみに依存している
  • 攻撃者が用意したページ（悪意のあるフォームや JavaScript）を被害者が閲覧し、その結果としてターゲットサイトに対してリクエストが送信される

ブラウザは、送信先が同じドメインである限り自動的に Cookie を付与するため、被害者の意思と無関係に「正当なセッションを伴うリクエスト」が実行されることになる。

図2-3: CSRF の成立イメージ（概要）

flowchart LR
    P[前提：ログイン済み\nセッション Cookie を保持] --> B[被害者ブラウザ]
    A[攻撃者サイト（悪意あるページ）] -->|被害者が閲覧| B
    B -->|状態変更リクエスト\nCookie を自動付与| T[ターゲット Web アプリ]
    T --> V{CSRF 対策検証\n（トークン / Origin 等）}
    V -->|OK| S[処理]
    V -->|NG| R[拒否]

図2-3 のように、被害者がログイン済みでセッション Cookie を保持している状態で、攻撃者サイトを閲覧すると、ブラウザが Cookie を自動付与した状態で状態変更リクエストが送信され得る。サーバ側で CSRF トークンや Origin などを検証し、正当な操作からのリクエストであることを確認できなければ、CSRF が成立する。

代表的な CSRF 対策

実務で利用される代表的な CSRF 対策は次のとおりである。

  • 同一サイトトークン（Synchronizer Token Pattern）
    HTML フォームや JavaScript から送信されるリクエストに、サーバ側で生成した CSRF トークンを付与し、サーバ側で検証する。トークンはユーザーセッションと紐づけ、推測不能とする。
  • ダブルサブミット Cookie
    CSRF トークンを Cookie とリクエストボディ（またはヘッダ）の両方に送信し、両者の一致を確認する。
  • SameSite Cookie
    先述のとおり、SameSite=Lax / Strict を利用してクロスサイトからの Cookie 送信を抑制する。ただし、ブラウザ依存性や UX への影響を考慮する必要がある。
  • Referer / Origin ヘッダ検証
    リクエストの送信元オリジンが期待するドメインであるかを検証する。ただし、プライバシー設定やプロキシ環境によりヘッダが送信されないケースもあるため、単独対策としては不十分な場合が多い。

多くの場合、これらの対策を組み合わせて実装することが望ましい。Pentest では、実装されている対策の有無だけでなく、「対象エンドポイントごとに対策が適用されているか」「トークンが適切に検証されているか」を確認する。

CSRF と CORS / SameSite の関係

CSRF は、同一生成元ポリシーを前提としたブラウザの挙動を悪用する攻撃であり、CORS や SameSite の設定と密接に関係する。

  • CORS
    CORS は主に「レスポンスの JavaScript からの読み取り」を制御する仕組みであり、CSRF そのものを防ぐものではない。ただし、誤設定により第三者オリジンから認証付き API レスポンスが読み取れる場合、CSRF や XSS と組み合わせて情報漏えいの影響が増大する。
  • SameSite
    SameSite は「どのリクエストで Cookie を送信するか」を制御するため、CSRF リスクの低減には直接的に寄与する。ただし、ブラウザ実装差異やバックワードコンパチビリティの観点から、完全な防御とは言えない。

Pentest の報告では、「CSRF トークンが実装されていない」「SameSite 設定が不適切」といった個別指摘に留まらず、「どのビジネス操作が CSRF により悪用され得るか」をシナリオとして示すことが重要である。

次に読む章

本章のポイント

  • セッション管理では、セッション ID の推測困難性、ログイン時の再発行（Session Fixation 対策）、無効化とタイムアウトが確認ポイントとなる。
  • CSRF は「ブラウザが Cookie を自動送信する」挙動を悪用するため、状態変更系リクエストの保護が重要である。
  • 対策は CSRF トークンや SameSite などの組み合わせが基本であり、エンドポイント単位で適用状況と検証の厳密さを確認する。
Edit this page on GitHub