Webアプリケーション攻撃

Secure属性（Cookie）せきゅあぞくせい

CookieHTTPSセッション管理盗聴TLSセッションハイジャック

CookieのSecure属性って何？

簡単に言うとこんな感じ！

CookieにSecure属性をつけると、「暗号化された通信（HTTPS）のときだけCookieを送る」というルールになるんだ！鍵のかかった封筒でしか手紙を送らないようにする設定、みたいなイメージだよ。これがないと、普通のHTTP通信でもCookieが流れてしまって、盗み見られちゃうリスクがあるってこと！

Secure属性とは

Secure属性は、HTTPレスポンスの Set-Cookie ヘッダに付与できるフラグのひとつです。この属性を設定すると、ブラウザはそのCookieを HTTPS（TLSで暗号化された通信）のリクエスト時にのみサーバーへ送信し、HTTP（平文通信）では送信しないようになります。

Webアプリケーションでは、ログイン状態を保持するために「セッションID」をCookieに格納するのが一般的です。しかしSecure属性がついていないと、ユーザーが誤ってHTTPのURLにアクセスした瞬間や、攻撃者によって通信を平文に誘導された場合に、セッションIDが盗まれてしまう危険があります。

Secure属性はあくまで「送信タイミングの制御」であり、Cookie自体を暗号化するものではありません。しかし、盗聴によるセッションハイジャックを防ぐ基本的かつ重要な防御策として、現代のWebセキュリティガイドラインで必須とされています。

Secure属性の仕組み

Set-Cookieヘッダの書き方

Set-Cookie: sessionid=abc123; Path=/; Secure; HttpOnly

Secure とひとこと書き加えるだけで有効になります。HTTPSで発行されたCookieには必ずつけるのが基本です。

Secure属性の有無による動作の違い

状況	Secure属性あり	Secure属性なし
HTTPSで通信中	✅ Cookieを送信する	✅ Cookieを送信する
HTTPで通信中	❌ Cookieを送信しない（保護）	⚠️ Cookieを送信してしまう
盗聴された場合	内容は暗号化されているので読めない	Cookieの中身が丸見えになる
セッションハイジャックリスク	低い	高い

よく一緒に使われる属性

属性	役割
Secure	HTTPS通信のときだけ送信する
HttpOnly	JavaScriptからCookieを読み取れないようにする（XSS対策）
SameSite	他サイトからのリクエストにCookieを送らない（CSRF対策）

この3つをセットで設定するのが、現在のベストプラクティスです。

覚え方

「Secureは鍵つき封筒」
普通の封筒（HTTP）では届けない。鍵つき封筒（HTTPS）でしか送らない、という封筒ルール。

歴史と背景

1994年頃 — NetscapeがCookieを発明。当時はセキュリティ属性の概念がなかった
1997年 — RFC 2109 にてCookieの仕様が初めて標準化。Secure属性もここで定義
2000年代前半 — HTTPSの普及が進むにつれ、セッション管理のセキュリティ問題が顕在化
2011年 — RFC 6265 でCookieの仕様が改訂・整理。Secure属性の動作が明確化される
2015年以降 — Let’s Encrypt の登場でHTTPS化が急速に普及、Secure属性の重要性がより高まる
2020年頃 — Chrome・Firefox などの主要ブラウザが、SameSite=None のCookieにはSecure属性を必須とする方針を採用

Secure属性がない場合の攻撃シナリオ

Secure属性が設定されていないと、具体的にどのような攻撃が成立するかを見てみましょう。

SSLストリッピング攻撃との組み合わせ

Secure属性がない場合、攻撃者は SSLストリッピング（HTTPSをHTTPに強制ダウングレードする攻撃）と組み合わせることで、ユーザーが気づかないうちにセッションCookieを盗み取れます。公共のWi-Fiなど、攻撃者が通信経路に割り込みやすい環境で特に危険です。

実務での確認方法・設定例

ブラウザの開発者ツールで確認する

ChromeやFirefoxの開発者ツール（F12）→「Application」→「Cookies」を開くと、各Cookieの属性を一覧で確認できます。「Secure」列にチェックがついているかどうかで判断できます。

主要言語・フレームワークでの設定例

# Python (Django)
SESSION_COOKIE_SECURE = True

# PHP
setcookie("sessionid", $value, [
    "secure" => true,
    "httponly" => true,
    "samesite" => "Strict"
]);

# Node.js (Express + express-session)
app.use(session({
  cookie: { secure: true, httpOnly: true, sameSite: 'strict' }
}));

# Java (Spring Boot / application.properties)
server.servlet.session.cookie.secure=true

発注・選定時のチェックポイント

確認項目	内容
セッションCookieのSecure属性	ログイン後のセッションIDにSecureがついているか
HTTPS化の徹底	サイト全体がHTTPSになっているか（HTTPリダイレクトがあるか）
HSTS設定	`Strict-Transport-Security` ヘッダで強制HTTPSが有効か
HttpOnly・SameSiteの併用	3属性がセットで設定されているか

規格・RFC番号	内容
RFC 6265	HTTPのCookieと`Set-Cookie`ヘッダの現行標準仕様。Secure属性の動作を定義
RFC 6265bis	RFC 6265の改訂版（策定中）。SameSite属性の標準化なども含む
RFC 2818	HTTP over TLS（HTTPS）の仕様