HTTP/2 の Server Push と Signed HTTP Exchange：複数ドメインで共有される証明書と抜穴

Hackers Exploit HTTP/2 Flaw to Launch Arbitrary Cross-Site Scripting Attacks

2025/05/27 gbhackers — 清華大学と中関村研究所の画期的な研究により、現代の Web インフラに存在する深刻な脆弱性が発見された。HTTP/2 の Server Push 機能と Signed HTTP Exchange (SXG) 機能が悪用されると、Web の Same-Origin Policy (SOP) の回避にいたることが明らかになった。SOP の目的は、ある Web サイト上の悪意のスクリプトが、別の Web サイトの機密データに、不正アクセスすることを防ぐためのデザインにある。しかし、研究者たちが発見したのは、ブラウザが “生成元 (origin)” と “認証局 (authority)” を解釈する際の方法への、最近の変更が危険な抜け穴を生み出していることである。

従来において Web ブラウザは、”生成元 (origin)” を URI スキーム／ホスト／ポートの一意のタプルとして定義していた。しかし、HTTP/2 および HTTP/3 プロトコルでは、TLS 証明書の SubjectAlternativeName (SAN) フィールドに記載される、任意のドメインを “認証局 (authority)” として認識できる。

したがって、証明書が複数のドメイン (多くの場合、異なる組織によって管理されている) で共有されている場合において、HTTP/2 Server Push または SXG を使用する際に、それらのドメインのいずれかが、ブラウザにより同じ “認証局 (authority)” として扱われる可能性が生じる。

それを悪用する攻撃者が、共有証明書を取得または乗っ取ることで、悪意のリソースをプッシュする可能性が生じる。これらのリソースが、異なるドメインからのものであっても、ブラウザは正当なものとして受け入れてしまう。

CrossPUSH と CrossSXG

この研究では、新たに発見された２つの強力な攻撃手法が紹介されている。

CrossPUSH：HTTP/2 Server Push を悪用する攻撃者は、標的のサイトと証明書を共有しているドメインを制御し、”:authority” 疑似ヘッダーで標的ドメインを指定し、JavaScript ファイルなどのリソースをブラウザにプッシュできる。

このブラウザは共有証明書を信頼し、一連のリソースをキャッシュし、その後に、標的サイトのセキュリティ・コンテキストで、それらを実行する。その結果として、クロスサイト・スクリプティング (XSS)／Cookie 操作／悪意のファイルのダウンロードなどの攻撃が可能になる。

javascript// 例: Node.js HTTP/2 を使用して :authority を設定する stream.pushStream({ ‘:path’: ‘/script.js’, ‘:authority’: ‘victim.com’ }, (err, pushStream) => { pushStream.respond({ ‘:status’: 200, ‘content-type’: ‘application/javascript’ }); pushStream.end(‘alert(document.cookie);’); });

CrossSXG：SXG を悪用する攻撃者は、request-url ヘッダーと validity-url ヘッダーを操作することで、共有証明書の SAN リストに含まれる、任意のドメインから発信されたように装い、Web コンテンツに署名できる。

つまり、このブラウザは共有証明書を用いて SXG を検証し、被害者サイトからのものとして、攻撃者のコンテンツを表示する。

この攻撃は、キャッシュやサード・パーティの配信元をまたいで機能するため、さらに強力である。

どちらの攻撃も “off-path” 攻撃である。つまり、攻撃者はネットワーク・トラフィックを傍受する必要がなく、自分のサイトにユーザーを誘導するだけで済む。例として挙げられるのは、フィッシングや悪意の iframe 経由などがある。そのため、この脅威は、きわめてスケーラブルで現実的なものとなる。

広範囲に及ぶ脆弱性と悪用

この調査における大規模な測定により判明したのは、これらの脆弱性が理論上のものではなく、Web エコシステムの大半に影響を与えることである。

ブラウザへの脆弱性：Chrome や Edge などの主要ブラウザ 14 種類のうちの 11 種類が、少なくとも、いずれかの攻撃に対して脆弱である。

その一方で、Instagram や WeChat などモバイル・アプリや、ブラウザ・ライブラリにも影響が及ぶとされるが、特にブラウザ・デフォルト動作を WebView が継承するプラット・フォームでは、影響が顕著だとされる。

Web サイトの露出：11,000件を超える上位ドメインが、攻撃が可能な期間内に転売されている。また、DNS 設定が不適切な、約5,000件の宙ぶらりん “dangling” ドメインが存在し、証明書発行のために乗っ取られる可能性があるという。驚くべきことに、上位 1,000ウェブサイトの 83% において、下位ランクで安全性が低い可能性のあるドメインと証明書が共有されており、攻撃対象領域が劇的に拡大している。

攻撃の持続期間：ドメイン検証の再利用と証明書更新ポリシーにより、被害者が侵害された証明書の失効を試みた後であっても、最大で 796日間にわたり、攻撃者は証明書を制御できる。

ドメイン登録び猶予期間を追加する Add Grace Period (AGP) などの機能が、最小限のコストによる証明書の取得のために悪用される可能性があり、攻撃者が証明書の SAN リストにドメインを保持している場合において、現在の失効メカニズムが機能しないことも多々ある。

緩和策と業界による対応

研究者たちは、いくつかの緊急の緩和策を提案している。

Web ブラウザにおいて、厳格な権限チェックを実施し、権限が接続元と一致しない Server Push や SXG を拒否する必要がある。

認証局 (CA) は、ドメイン所有者による、共有証明書からのドメイン削除をサポートすることで、検証手順を改善する必要がある。

ドメイン・レジストラと購入者は、疑わしい証明書共有を検出するために、ドメイン移転時に証明書の透明性 (Certificate Transparency) ログを監視する必要がある。

中国の研究チームは、これらの調査結果を Microsoft／Google／Huawei／Baidu などの主要ベンダーに対して、適切な責任を持つかたちで開示し、初期の緩和策への認識と取り組みを促している。

この研究が明らかにしたのは、最新の Web プロトコルと証明書管理の交差点における、体系的な欠陥である。厳格なセキュリティ対策を講じているサイトであっても、安全性の低いドメインと証明書を共有することで、侵害を受ける可能性があることが実証された。

業界全体として、広範囲におよぶ悪用が発生する前に、これらの抜け穴を塞ぐための、迅速な行動が求められている。

訳していても、なかなか理解が追いつかない記事でした。まず、HTTP/2 と HTTP/3 プロトコルでは、TLS 証明書の SAN フィールドに記載される任意のドメインを “認証局 (authority)” として認識できてしまうという脆弱性があるようです。したがって、証明書が複数のドメインで共有されている場合に問題が生じ、CrossPUSH と CrossSXG という攻撃手法が生じるとのことです。でも、証明書の共有というのも不思議なものです。ドメインの転売などで起こってしまうのでしょうかね？