普段は意識しないが、ウェブの証明書には複数のドメイン名が登録されていることがある。実際、大規模なサービスでは 1 枚の証明書を複数のサイトで共有する運用が珍しくない。1 枚の証明書に複数のサイト名をまとめる運用は、HTTPSが常態化しLet's Encryptが普及した現代のウェブでは、ごく一般的な効率化手法だ。
問題は、その「身分証の共有」が条件次第でなりすましの踏み台になることだ。清華大学の Pinji Chen 氏らは、2025 年 8 月の Black Hat USA 2025 Briefings で、この共有証明書を悪用する新たなクロスオリジン攻撃「CrossPUSH」「CrossSXG」を発表した。注目すべきは、なりすまされた本物の企業が、その不正な証明書を自力で無効にできないという点である。
● 証明書は「お店の身分証」
なぜ「共有」がリスクになるのか。まず前提を押さえたい。カギマークは、「このサイトは本物で、通信も暗号化されている」という店の身分証明書が確認できた印だ。この身分証があるから、私たちは安心してパスワードやカード番号を打ち込める。
証明書には SAN（Subject Alternative Name）という欄があり、複数のサイト名を登録できる。1 枚の身分証を複数の店舗で使うようなものだ。Chen 氏らが引用した ACM CCS 2016 の調査によれば、証明書の 96 ％は複数ドメインを含んでいた。一方で、3.2 ％には異なる組織のドメインが同居していたという。複数ドメイン証明書はウェブ上で広く利用されているが、本研究が着目したのは、その一部で生じている「組織をまたいだ証明書共有」だった。
● 「誰を名乗ってよいか」の判定が甘い
今回の攻撃は、ブラウザの基本ルール「同一オリジンポリシー（SOP）」そのものを破るものではない。JavaScript が他サイトのデータを勝手に読む、という従来型の突破ではない。
狙われたのは、性能改善のために設けられた 2 つの配信の仕組み、HTTP/2 サーバープッシュと署名交換（SXG:Signed HTTP Exchange）における、「サーバーがどのサイトを名乗ってよいか」という権限判定だ。この 2 つの仕組みでは、その判定が証明書の SAN ベースで行われる。SAN に名前が載っていれば、そのサーバーは「そのサイトの正当な配信元」として振る舞えてしまう。
例えるなら、大企業の社員証に別人の名前を 1 行だけ書き足すようなものだ。受付は「この人も社員ですね」と、その別人を社内に通してしまう。攻撃者が標的サイトと共有された証明書を保有していれば、共有証明書を信頼根拠とする配信機構では、標的サイト由来と誤認させたコンテンツ配信が可能になる。これが攻撃の核心である。
● 標的が無傷でも、休業中でも成立する
攻撃の流れはシンプルだ。
・攻撃者が標的と共有された証明書を保有する
・被害者を悪意あるリンクへ誘導する
・サーバープッシュまたは SXG でスクリプトを送り込み、:authority 疑似ヘッダ等でオリジンを標的サイトに偽装する
・ブラウザはそれを「同一オリジンの正規スクリプト」として受理・実行する
Chen 氏は従来の攻撃との違いを次のように対比した。
