セッション管理の「穴」を埋める：Cookie属性を極めて、攻撃者の侵入路を断つ
エンジニア諸君、今日も運用お疲れ様。
インシデント対応の現場でよく見る光景がある。「認証機能はログイン処理さえうまく作ればOK」という勘違いだ。しかし、攻撃者はログイン後の「セッション」を執拗に狙ってくる。
セッションハイジャックやCSRF（クロスサイトリクエストフォージェリ）は、Webアプリにおける「玄関の鍵はかけたが、窓が開けっ放し」という状態と似ている。今回は、Cookie属性の最適化という、地味だが最も確実な防御策について、実務レベルの知見を叩き込む。
—
1. なぜCookie属性の設定が「生死」を分けるのか
まず、攻撃者が何を狙っているかを理解しよう。
- HttpOnly欠如: JSの `document.cookie` でセッションIDが筒抜けになる。XSSで一発アウトだ。
- Secure欠如: HTTP通信でセッションIDが平文で流れる。公衆Wi-Fiでの盗聴が捗る。
- SameSite欠如: CSRFの温床。ユーザーが知らない間に、悪意あるサイトからブラウザを介して「あなたの権限」でリクエストが送られる。
これらは設定一つで防げる。教科書には「設定しましょう」としか書いていないが、現場では「どの値を、どうコードに埋め込むか」が全てだ。
—
2. 【実装編】セッションCookieを鉄壁にする
PHPの場合 (php.ini または コード内)
PHPのセッション管理はデフォルト設定が甘いことが多い。`php.ini` で一括設定するか、アプリケーションの起動時に強制指定する。
0, // ブラウザ終了まで
‘path’ => ‘/’, // 全パスで有効
‘domain’ => ‘example.com’, // サブドメインに漏らさない
‘secure’ => true, // HTTPS必須
‘httponly’ => true, // JSからのアクセス禁止
‘samesite’ => ‘Lax’ // CSRF対策の黄金律
]);
session_start();
Python (Flask) の場合
Flaskの場合は、設定ファイル（`config.py`）で明示的に制御する。
config.py
SESSION_COOKIE_SECURE = True # HTTPS通信のみ
SESSION_COOKIE_HTTPONLY = True # JSからのアクセス禁止
SESSION_COOKIE_SAMESITE = ‘Lax’ # CSRFを大幅に抑制
—
3. 【インフラ編】Nginxで「念押し」の防御
アプリケーション側で設定を忘れた場合に備え、Webサーバー側で強制的にヘッダーを付与する「多層防御」がセキュリティの鉄則だ。Nginxの `add_header` を活用せよ。
nginx.conf の server または location ブロック内
Set-Cookieヘッダーに属性を強制追加する
proxy_cookie_path / “/; HTTPOnly; Secure; SameSite=Lax”;
※注意：すでに属性が付与されている場合は二重設定になる可能性がある。環境に応じて `more_set_headers` モジュールを使うか、アプリ側の実装を優先するように設計してくれ。
—
4. SameSite属性の「Lax」と「Strict」をどう使い分けるか
よく聞かれる質問だが、基本は `SameSite=Lax` でいい。
- Lax: ユーザーがリンクをクリックしてサイトを訪れた時はCookieを送信する。利便性を損なわず、多くのCSRF攻撃をブロックできる。
- Strict: サイト内遷移しか許さない。ログイン状態が頻繁に切れるため、ユーザー体験（UX）とのトレードオフが激しい。
「厳しければいい」わけじゃない。セキュリティは、ユーザーが不便を感じて「この設定をオフにしよう」と思わせたら負けだ。`Lax` で防げる範囲を理解した上で、極めて高い機密性が要求される管理画面などに限り `Strict` を検討するのがプロの判断だ。
—
5. 最後に：現場のエンジニアへ
今日紹介した設定は、いわば「基本のキ」だ。しかし、この基本を徹底できているチームとそうでないチームでは、インシデント発生時の被害規模が天と地ほど変わる。
コードを書くとき、インフラを構築するとき、常に自問してくれ。
「このCookieは、敵に奪われたら何ができる？」
もし回答に詰まるなら、まだそのアプリは未完成だ。技術はただ動くものを作るためではなく、守るためにある。次のデプロイから、この設定がデフォルトになることを期待している。
何か不明点があればいつでも相談に来てくれ。共に堅牢なプロダクトを作っていこう。
コメント