Webセッション管理とCookieセキュリティ｜Secure/HttpOnly属性・CSRF防御

Web通信のプロトコルであるHTTPは、直前の通信状態を保持しない「ステートレス（Stateless）」なプロトコルです。しかし、ログイン状態の維持やショッピングカートの保持を実現するために使われるのが「セッション管理」と「Cookie（クッキー）」です。

情報セキュリティマネジメント試験（SG）では、Cookieに付与すべき3大セキュリティ属性（Secure, HttpOnly, SameSite）、セッションハイジャックの手口と防御策、そしてクロスサイトリクエストフォージェリ（CSRF）のメカニズムが実戦形式で出題されます。

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の根本防御】フォーム表示時にサーバ側でランダムな「CSRFトークン」を生成してセッションに保持し、POST送信時に画面内のトークンとサーバ側トークンが一致するかを検証する。外部の罠サイトは正規トークンの値を知り得ないため、不正リクエストを100%遮断できる。

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

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

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

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

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

【解答と解説】

正解：イ

解説：HttpOnly属性をCookieに付与すると、ブラウザ上で動作するJavaScript（`document.cookie` 等）からのCookieアクセスが完全に遮断されます。これにより、万一Webアプリケーション側にXSS（クロスサイトスクリプティング）の脆弱性が存在して悪意あるスクリプトが注入された場合でも、セッションIDを盗み出して攻撃者のサーバへ送信される被害を強力に防止できます。

演習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属性：JavaScriptからのCookie参照を禁止（XSSによるセッション窃取防止）
SameSite属性：他サイトからのリクエスト時のCookie自動送信を制御（CSRF防止）
セッション固定化防止：ログイン認証成功時に必ずセッションIDを再生成・更新する
CSRF防御：秘密のワンタイムトークンを発行し、POST送信時に一致検証を行う

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