XSSのその先へ：HttpOnly属性を「ただの定石」と侮るな
「HttpOnlyを付与せよ」。この言葉はセキュリティガイドラインの第1章に書かれるような、いわば「挨拶」のようなものだ。しかし、世界中のインシデント現場で死屍累々たるセッションハイジャックの光景を見てきた者から言わせれば、この設定一つを理解しきれていないエンジニアがいかに多いことか。
今回は、XSS（クロスサイトスクリプティング）という古典的な脆弱性を、単なるJavaScriptの挙動の問題としてではなく、ブラウザのメモリ管理、プロトコル仕様の境界線、そして現代の脅威モデルという俯瞰的な視点から解剖する。
1. なぜ「HttpOnly」が究極の防衛線なのか
XSSの本質は、攻撃者がサンドボックス化されたブラウザのメモリ空間で、正当なユーザーの権限を借用することにある。document.cookie は、ブラウザのAPIが提供する「クッキーへの窓口」に過ぎない。
攻撃者が window.location を操作したり、fetch で外部サーバーにセッションIDを送信したりする際、HttpOnly属性が設定されていないクッキーは、ブラウザのメモリから攻撃者の制御下に容易にコピーされる。
HttpOnlyは、単なる設定値ではない。これはブラウザエンジンに対する「メモリ読み取り拒否」の強制命令だ。この属性が付与されると、ブラウザのクッキー管理モジュールは、HTTP(S)通信のヘッダー処理以外では、そのクッキーをJavaScript APIに一切露出させない。たとえDOM型XSSで脆弱なコードが実行されたとしても、攻撃者はそのクッキーを読み取ることができず、セッションハイジャックという「ゲームオーバー」を回避できる可能性が高まる。
2. アーキテクチャ視点での実装：Cookie設定の厳格化
多くのテックリードは、フレームワークのデフォルト設定を信じ込んでいる。しかし、堅牢なアーキテクチャは「明示的な制御」によって築かれる。
以下は、Node.js (Express) における、防御レイヤーを最大化したセッションクッキーの定義例だ。
// セッションクッキーを強固に保護するための設定
app.use(session({
name: ‘__Secure-SessionID’, // __Secure- を冠することでブラウザにHTTPS強制を促す
secret: process.env.SESSION_SECRET,
resave: false,
saveUninitialized: false,
cookie: {
httpOnly: true, // JSからのアクセスを物理的に遮断
secure: true, // HTTPS通信以外での送信を禁止
sameSite: ‘strict’, // クロスサイトリクエスト時の送信を抑制（CSRF対策）
maxAge: 3600000 // セッション寿命を極限まで短縮する（攻撃窓を閉じる）
}
}));
ここで重要なのは、__Secure- プレフィックスの活用だ。これはCookieの仕様（RFC 6265bis）に基づき、HTTPS通信を強制する強力なセパレーターとなる。たとえアプリケーションコードでミスがあり secure: false と設定されても、ブラウザがこれを拒否する。こうした「ブラウザ側の仕様」を味方につける設計こそが、プロの仕事だ。
3. 生成AI時代の「インジェクション」に対するガードレイル
昨今、開発現場に浸透しつつあるAIコーディング支援ツールや、RAG（検索拡張生成）を用いたアプリケーションでは、プロンプトインジェクションが新たなXSSの温床となりつつある。
AIが生成したコードがHTMLコンテキストに出力される際、エスケープが不完全であれば、攻撃者はAIを介して悪意あるペイロードを注入できる。ここでHttpOnlyの価値が再評価される。「たとえアプリケーションのロジックがAIによって汚染されても、セッションIDだけは盗ませない」という、多層防御の最後の砦としての機能だ。
防御側は、以下の観点でアーキテクチャを再監査すべきである。
- Content Security Policy (CSP) の厳格化:
script-src 'self'をベースにし、インラインスクリプトを一切排除する。 - メモリダンプとセッションローテーション: HttpOnlyで守られているとはいえ、長期間のセッション維持はリスクである。アイドリング時間が一定を超えたら即座にセッションを破棄し、再認証を求めるべきだ。
- 耐量子暗号とTLS: 現代のインフラでは、HTTPSは前提だが、量子コンピュータ時代の到来を見据え、TLS 1.3の採用とPFS（完全前方秘匿性）の確保は必須の要件である。
結論：技術的知見を「文化」に昇華させる
XSSは消滅しない。なぜなら、Webの柔軟性という仕様そのものが、攻撃者にとっての都合の良い「広場」だからだ。
HttpOnly属性は、たった一つのフラグに過ぎない。だが、その背後にある「ブラウザというOS」の仕様を理解し、それを防御の基盤として設計に組み込めるかどうかが、脆弱なシステムと堅牢なシステムの分水嶺となる。
コードを書くとき、サーバーを設定するとき、今一度考えてみてほしい。あなたが守っているのは、ただのデータか、それともユーザーの信頼という名の「デジタルなアイデンティティ」か。セキュリティの本質は、常にこの泥臭い防衛の積み重ねの中にある。
コメント