Cookie Chaos：__Host- と __Secure- のCookieプレフィックスはなぜ「突破」され得るのか

概要

元ソースは、PortSwigger Research の記事「Cookie Chaos: How to bypass __Host and __Secure cookie prefixes」です。この記事は、セッション保護などの目的で導入されたCookieプレフィックス（__Host- と __Secure-）が、実装や解釈の“すき間”によって想定どおりに機能しないケースがあり得る、という問題提起をしています。

__Secure- や __Host- は、Cookieの付与条件を強めることで「攻撃者が都合の良いCookieをセットして、正規のCookieと競合させる」タイプの攻撃（いわゆるCookieの競合・上書き・混入といったリスク）を減らすために設計されたものです。ただし、Webはブラウザ・サーバー・プロキシ・WAF・アプリフレームワークなど複数コンポーネントの境界で成り立っており、Cookieの解釈が常に一枚岩とは限りません。元記事が示すのは、まさにこの“境界のズレ”がセキュリティ機構の前提を崩し得る、という点です。

詳細

Cookieプレフィックスの狙いはシンプルで、Cookie名に規約を持たせることで「安全な属性が付いていないCookie」や「意図しないスコープ（ドメインやパス）で設定されたCookie」を拒否し、重要なCookie（例：セッション識別子）の取り扱いを堅くすることにあります。特に __Host- は“ホスト限定”を強く意識した設計で、誤ったスコープでの設定や、別のサブドメイン経由での混入を抑えたい、という動機と相性がよい考え方です。

一方で、元記事が焦点を当てるのは「防御が“ブラウザの側”で成立していても、“サーバーの側”が同じ前提でCookieを解釈・選別しているとは限らない」という点です。例えば、同名Cookieが複数送られてきたときに、どれを優先するか、どのように分割・正規化して扱うかは、サーバーの実装（言語・フレームワーク・ミドルウェア・ライブラリ）に依存します。ここに差分があると、ブラウザ側の制約で守られているはずのCookie名・属性の“意図”が、サーバー側の取り扱いによって相殺され、攻撃者に都合のよい値が採用される余地が生まれます。

この種の問題が厄介なのは、アプリ開発者が「プレフィックスを付けたから安全になった」と思い込みやすい一方で、実際には“最終的にどのCookie値を採用するか”という意思決定が、アプリケーションの受信側スタックのどこかに散らばっていることです。負荷分散やCDN、WAF、アプリサーバー、アプリ本体の順に通過する途中でCookieヘッダーが再構成されたり、ログや計測の都合で正規化されたりすると、境界条件の挙動が変わり、想定外の優先順位・解析結果になる可能性があります。

では実務として何をすべきか。第一に、重要Cookie（認証・セッション・CSRF等）については、プレフィックスに頼るだけでなく、サーバー側で「受理するCookie名の厳格な許可リスト」「属性要件（Secure、SameSite、Path等）を満たさないCookieを無視する」「同名Cookieが複数来たら拒否または安全側に倒す」といった検証戦略を持つのが現実的です。第二に、環境差（ブラウザ差、プロキシ差、言語ライブラリ差）を前提に、ステージングで“同名Cookie複数”や“属性差分”を含むケースを再現して、どの値が採用されるのかを観測・テストできる状態にしておくことが重要です。

元ソースに関連して、PortSwigger ResearchにはCookieやパーサ挙動を悪用する観点の研究記事が複数あり、個別論点は違っても「仕様・実装・境界条件の隙間が攻撃面になる」という共通の教訓が読み取れます。防御側としては、単発の設定で完了させず、受信処理の“最後の採用点”まで含めて安全性を設計する、という姿勢が求められます。

なお、こうした手法は攻撃に直結し得るため、検証は必ず自組織の許可範囲・検証環境で行い、脆弱性が疑われる場合は責任ある開示プロセスに従うべきです。