Webセッション管理とCookieセキュリティ｜セッションハイジャック・Secure属性・CSRFトークン検証

セッションを守るでは、Cookieの保護と、意図しない操作への対策を分けて考えます。用語を覚えるだけでなく、事例の条件に合う対策を選べるように整理しましょう。

科目Aで基本的な意味を確認し、科目Bでは「守る情報・起きた事象・組織のルール・担当者の権限」を読み取ります。本文の確認問題は、考え方を練習するためのオリジナル問題です。

1. Cookieの仕組みと3大セキュリティ属性

Webサーバはログインに成功したクライアントに対し、`Set-Cookie` レスポンスヘッダーで「セッションID」を発行します。ブラウザは以降のリクエスト時に自動的にこのCookieをサーバへ送り返すことで、ログイン状態を証明します。

Cookie属性	属性の意味と機能	防御できる脅威・攻撃
Secure属性	HTTPS（暗号化通信）接続時のみCookieを送信し、暗号化されていないHTTP接続ではCookieを送信させない。	公衆Wi-Fiやネットワーク通信の盗聴（スニッフィング）によるセッションID漏えい
HttpOnly属性	JavaScript（`document.cookie` 等）からのCookie読み取りをブラウザ側で禁止する。	XSS（クロスサイトスクリプティング）攻撃によるセッションIDの不正持ち出し
SameSite属性	別サイト（クロスサイト）からのリンクやリクエストに伴うCookie自動送信を制御する（Strict, Lax, None）。	CSRF（クロスサイトリクエストフォージェリ）攻撃の抑止

2. セッション管理における主要な攻撃手口

攻撃名称	手口とメカニズム	最も効果的な防御策
セッションハイジャック	正当な利用者のセッションIDを盗聴・推測・XSS等で窃取し、そのIDを使って利用者になりすます。	HTTPS通信の強制（Secure属性）、HttpOnly属性、セッションIDの十分な暗号学的乱数生成
セッション固定化（Session Fixation）	攻撃者が事前に取得したセッションIDを利用者に送りつけ、そのIDのまま利用者にログインさせた後、攻撃者も同じIDでログイン領域に侵入する。	ログイン成功時に「セッションIDを再発行（新IDへ振り替え）」する
CSRF（クロスサイトリクエストフォージェリ）	攻撃者が罠ページを用意し、ログイン中の利用者のブラウザから意図しないリクエスト（パスワード変更、送金等）を強制送信させる。	リクエスト内に推測不能な「ワンタイムトークン」を含めて検証する、SameSite属性の適用

3. CSRF（クロスサイトリクエストフォージェリ）の完全理解

CSRFの恐ろしい点は、「攻撃者のリクエストではなく、ログイン中の本人のブラウザが正規のCookieを付けてリクエストを送信してしまう」という点です。サーバ側から見ると、正当なセッションCookieが付いているため、本人からの正規リクエストと区別がつきません。

利用者がネット銀行サイトにログインし、セッションCookieをブラウザに保持する。
利用者が別タブで悪意ある罠サイト（掲示板やメール内のリンク）を閲覧する。
罠サイト内のスクリプトが、ブラウザの裏で自動的にネット銀行の「送金API（POST /transfer）」へ不正なリクエストを送信させる。
ブラウザは仕様に従い、ネット銀行宛ての正規Cookieを自動添付して送信する。
ネット銀行サーバは「ログイン中の本人からの正当な要求」と誤認し、送金処理を実行してしまう。

CSRF対策
根拠：推測困難なトークンを適切に生成・保持し、状態を変更するリクエストで検証します。SameSiteやOriginの確認等も構成に応じて組み合わせます。
確認する点：トークンは毎回使い捨てでなければ成立しない仕組みではありません。XSSでトークンを読まれる場合などもあり、不正な要求を100％防ぐ保証ではありません。

4. 科目B形式実戦シナリオ演習

演習1：Cookieセキュリティ属性の設定漏れによるセッション窃取

〔背景〕ECサイトを運営するE社では、ユーザーのログインセッションをCookieで管理している。セキュリティ診断を実施したところ、「掲示板投稿欄にXSS脆弱性が存在し、第三者のJavaScriptが実行可能である」との指摘を受けた。

〔設問〕XSS脆弱性が突かれた場合であっても、攻撃者のスクリプトによってセッションCookie（セッションID）が直接外部へ送信される被害をブラウザ側の制御で阻止するために、Cookieに付与すべき必須属性はどれか。

ア：Domain属性
イ：HttpOnly属性
ウ：Path属性
エ：Expires属性

【解答と解説】

正解：イ

イが正解です。HttpOnly属性により、JavaScriptから対象Cookieを読み取れなくなり、XSSでセッションIDを持ち出すリスクを減らせます。ただし、XSSから利用者の権限で要求を送る等の被害は残るため、XSSそのものへの対策も必要です。

演習2：セッション固定化攻撃の防止とログイン時のトークン更新

〔背景〕F社の会員制Webサイトでは、トップページにアクセスした未ログインの訪問者に対しても、アクセス解析目的でセッションIDをCookieに発行していた。利用者がログインボタンを押し、IDとパスワードの認証に成功した後も、ログイン前に発行されたセッションIDをそのまま使い続けていた。

〔設問〕この実装が抱えるセキュリティリスク（セッション固定化攻撃）を排除するために、Webアプリケーションがログイン成功時に実施すべき処理として、最も適切なものはどれか。

ア：ログイン成功時に、既存のセッションIDを破棄し、暗号学的に安全な乱数を用いて「新しいセッションID」を再生成してCookieを更新する。
イ：ログイン成功時に、セッションIDの有効期限を1年間に延長する。
ウ：ログイン成功時に、パスワードをセッションIDとしてCookieに直接書き込む。
エ：利用者にブラウザのCookie機能を無効化するよう警告画面を表示する。

【解答と解説】

正解：ア

解説：ログイン前とログイン後で同一のセッションIDを引き継いで運用していると、攻撃者が事前に指定したセッションIDを利用者に踏ませてログインさせる「セッション固定化（Session Fixation）攻撃」に対して極めて脆弱になります。防御策は、認証が成功した瞬間にそれまでのセッションIDを完全に破棄し、「新しいセッションIDを再発行（Regenerate Session ID）」して利用者に再割り当てすることです。

5. まとめと試験直前チェックリスト

SecureはHTTPS経由の送信を要求する。Cookieを暗号化保存する機能ではない。
HttpOnlyはスクリプトからのCookie参照を制限する。XSS全体を防ぐ機能ではない。
SameSiteはクロスサイトの送信を制御する。設定と操作内容に応じてCSRF対策を組み合わせる。
ログイン時のセッションID更新、旧IDの無効化、ログアウト時の失効を適切に行う。
CSRFトークンは推測できないよう管理し、対象の要求で検証する。

出典と仕様を確認する

IPA：情報セキュリティマネジメント試験シラバス Ver.4.1

OWASP：CSRF防止の実装指針