清华大学 | 基于HTTP/2服务器推送和签名HTTP交换的跨源Web攻击

原文标题：Cross-Origin Web Attacks via HTTP/2 Server Push and Signed HTTP Exchange原文作者：Pinji Chen, Jianjun Chen, Mingming Zhang, Qi Wang, Yiming Zhang, Mingwei Xu, Haixin Duan会议：NDSS Symposium 2025原文链接：https://dx.doi.org/10.14722/ndss.2025.231086笔记作者：王彦@安全学术圈主编：黄诚@安全学术圈编辑：张贝宁@安全学术圈

1 引言

Same-Origin Policy (SOP) 是 Web 安全的核心机制，确保不同源之间的资源隔离，防止跨站脚本攻击（XSS）等威胁。本文揭示了HTTP/2 server push和signed HTTP exchange（SXG）在SOP 下的新型绕过方式。研究指出，这两种新兴技术通过 TLS 证书的 SAN（SubjectAlternativeName）列表放宽了传统基于 URI 的同源策略（SOP），使攻击者得以绕过传统基于URI的同源检测机制，发起包括XSS、Cookie操作与恶意文件下载在内的跨源web攻击。

本文指出，这两项新技术带来了两个关键问题：

• 浏览器和协议对“源”的理解不一致；
• 共享证书常用于多个不相关的域名，攻击者可以通过控制这些证书中的某个域来伪装其他域。

本文提出两种新型跨源攻击方式：

• CrossPUSH：利用 HTTP/2 的 Server Push 伪造资源来源；
• CrossSXG：使用 SXG 签名并冒充其他域发布内容。

本文主要贡献：提出CrossPUSH与CrossSXG两种新型跨源攻击方式证明了其可行性和严重性，能够绕过 SOP 保护执行多种 Web 攻击。在主流浏览器与真实网站上验证了攻击的广泛性和危害性。提出防御建议，强化浏览器同源策略及证书使用策略。

2 技术背景

2.1 HTTP/2 Server Push

目的：加速网页加载，避免客户端重复请求资源。

机制：服务器可在主文档响应时，主动“推送”未来会被使用的资源（如脚本、图片等）。

特点：在 HTTP/2 中，服务器可通过 :authority 伪头字段指定推送资源的来源。只要推送流的 :authority 与证书中的任何 origin 匹配，浏览器就可以接受该推送流。

2.2 Signed HTTP Exchange（SXG）

目的：在第三方缓存中转资源时，保证其内容完整性与来源可信度。

典型应用：Google Search 预抓取并缓存 SXG 资源，为用户提供快速访问体验。

特点：SXG 通过 request-url 和 validity-url 等头部指定资源来源。只要这些 URL 与证书中任一域名匹配，浏览器就认定其来源合法。

2.3 Shared Certificates（共享证书）

定义：一个 TLS 证书用于认证多个域名，通常通过 SAN（Subject Alternative Name）扩展实现。

使用背景：便于统一管理多个域名，降低证书申请成本。

特点：SAN 列表中包含不相关或被攻击者控制的域名时，浏览器将其都视为同一个“权限”范围。

2.4 安全风险归因

HTTP/2 和 SXG 对“源”的判定，过度信任了证书中的域名列表。缺乏强制的所有权一致性校验（即，证书拥有者不一定拥有所有域名）。导致 SOP 被隐式绕过，攻击者可在“合法”范围内实施跨源攻击。

3 CrossPUSH 与 CrossSXG 攻击详解

3.1 威胁模型（Threat Model）

攻击者描述：无需处于通信路径中（off-path）；与受害者网站共享证书；通过常见漏洞，例如文件上传；注册并签发多域证书，再将域名转售（domain reselling）；利用 DNS 配置错误接管悬挂域名（dangling domain takeover）；引诱用户访问攻击者控制的站点（如钓鱼、iframe 植入）；攻击目标为证书中任一合法域名。

3.2 攻击理念（Attack Concept）

基于三项关键观察构建攻击模型：

攻击流程总结（见 Fig. 1）：

获取共享证书: 攻击者获取一个包含攻击者控制的域名（例如 attacker.com）和受害者域名（例如 victim.com）的共享 TLS 证书。

搭建恶意服务器并诱骗访问: 攻击者在 attacker.com 上使用该共享证书搭建 HTTP/2 或 SXG 服务器，并诱骗用户访问 attacker.com。

推送/交付恶意跨域资源并伪造来源: 攻击者通过服务器推送或 SXG 交付恶意跨域资源（例如恶意脚本），并将其来源指定为 victim.com。

浏览器错误地执行恶意脚本: 当用户随后访问 victim.com 时，浏览器会将之前推送/交付的、来源被伪造成 victim.com 的恶意脚本误认为同源资源并执行。

3.3 新型安全隐患（Novel Security Implication）

3.4 攻击方法（Methodology）

3.4.1 CrossPUSH 攻击流程：

诱骗访问: 攻击者诱导用户访问恶意网站 (attacker.com)。

推送并伪造来源: 恶意网站通过 HTTP/2 服务器推送恶意脚本 (script.js)，并声明其来源为受害者网站 (victim.com)。

浏览器缓存: 浏览器因证书信任而缓存该恶意脚本，但由于来源与当前页面不符，暂不执行。

触发请求: 恶意网站通过 <meta> 标签等方式使浏览器请求受害者网站 (victim.com)。

缓存命中并执行: 浏览器优先检查推送缓存，发现与请求主机匹配的（伪造来源的）恶意脚本，并将其作为同源资源执行，从而实现攻击。

3.4.2 CrossSXG 攻击流程：

准备恶意签名 SXG: 攻击者创建伪装成受害者网站 (victim.com) 的恶意 Web 内容并使用共享证书签名成 SXG 包。

诱骗访问并交付 SXG: 攻击者诱导用户访问恶意网站 (attacker.com)，并将伪造来源的 SXG 包发送给用户的浏览器。

浏览器请求证书并验证: 浏览器解析 SXG 包头，请求 cert-url 进行证书验证，该 cert-url 指向攻击者控制的服务器 (attacker.com)。

攻击者提供包含受害者域名的证书: 攻击者提供包含受害者域名 (victim.com) 在 SAN 中的证书 (cert.cbor)。

验证通过并展示伪造来源: 浏览器验证证书与 validity-url，并错误地认为 request-url 与 validity-url 同源，最终在地址栏显示受害者域名，并加载攻击者提供的恶意内容。

4 攻击实践

本节展示 CrossPUSH 和 CrossSXG 在现实中低成本、高可行性的攻击路径。

无需入侵的证书获取方法：

• 域名转售：攻击者先注册多个域并申请共享证书，随后转售其中部分域名，仍保留证书使用权。
• 域名接管：利用 DNS 错误指向失效资源，攻击者接管这些域名后申请合法证书。

攻击持续时间延长方法：

• 验证复用：多数 CA 允许重复使用旧的验证结果，可将攻击延续至最多796 天。

降低攻击成本方法：

• AGP 滥用：注册域名后立即退订仍可保留证书，实现几乎“零成本”攻击。

阻止证书撤销：

• 证书不可撤销：共享证书中的 victim.com 单方无权撤销，攻击者掌控不变。

5 大规模评估

本节通过客户端与服务器端双重测量，验证 CrossPUSH 和 CrossSXG 攻击在现实世界中的广泛性与危害性。

5.1 客户端评估（浏览器 & 应用）

方法：使用 PSChecker 平台 测量浏览器对 Server Push 和 SXG 的支持；本地复现攻击，验证其能否绕过 SOP。

结果：26 款主流浏览器中，11/14 个主流浏览器存在漏洞，包括 Chrome、Edge、UC 等；所有主流移动厂商默认浏览器（华为、小米、三星等）均受影响；多个热门 App（如 WeChat、Instagram、TikTok）使用易受攻击的 WebView；部分库如 Chrome-Net 被识别为漏洞来源，说明供应链存在隐患。

5.2 服务端评估（受影响网站）

三类受影响网站：

特别案例：微软某子域 14.au.www.download.windowsupdate.com 指向未注册域名；攻击者可合法获取证书并伪装微软官网，实施恶意文件下载攻击。

第六部分：现实攻击示范（Real-World Exploitation）

本部分展示了攻击者在获得共享证书后，可通过精心构造的 HTTP 响应内容或头部字段，在目标浏览器中执行具体攻击行为。

6.1 利用 HTTP Body

Exploit 1：通用 XSS 攻击（Universal XSS）

通过注入 <script>alert(document.cookie)</script> 等脚本， 攻击者可在受害域名下执行任意 JS；即使目标网站本身没有 XSS 漏洞，也能成功攻击；绕过 CSP 等浏览器策略，因为浏览器认为来源合法。

Exploit 2：伪装钓鱼页面（Phishing）

伪造完整 HTML 响应，显示仿真网站页面；浏览器地址栏与 TLS 锁标志显示为目标网站（如 example.com）；用户易被诱骗输入敏感信息。

6.2 利用 HTTP Header

Exploit 3：设置任意 Cookie

使用 Set-Cookie 头部设置 victim.com 下的 Cookie；可实现如会话固定（Session Fixation）等攻击。

Exploit 4：删除 HSTS 设置

通过设置 Strict-Transport-Security: max-age=0 删除 victim 域名的 HSTS；使其未来请求可被强制降级为 HTTP，提升中间人攻击风险。

注：虽然 SXG 本应禁止 stateful headers，但其实现（如 Google 的 web package）并未强制验证，攻击者可通过自建工具绕过检测。

6.3 结合 Header + Body

Exploit 5：自动下载带毒文件

设置 Content-Disposition: attachment; filename="instruction.exe"；配合 body 中的二进制内容，迫使浏览器从 victim.com 下载伪装文件；用户可能在毫无防备的情况下点击运行，植入病毒或木马。

6.4 一键攻击多个域名

利用 HTTP/2 支持多个并发流（默认最多 128），可一次攻击多个共享证书中的域；在 CrossSXG 中，通过多个 iframe 同时请求多个 victim.com 的 SXG，实现多目标同时攻击。

6.5 受影响库与软件链

某些浏览器（如 UC、Baidu）表现异常，是因为它们使用了漏洞库（如 Chrome-Net）替代 WebKit 进行网络请求；说明不仅浏览器本体，软件供应链中的库同样可能成为攻击突破口。

7 防御建议

为全面防御 CrossPUSH 和 CrossSXG 攻击，论文从浏览器、协议、CA、注册商多个角度提出改进措施：

7.1  浏览器层面的防御措施

• 对 CrossPUSH 的应对：浏览器必须拒绝接受 :authority 字段与当前请求 URI 不一致的 server push 流。禁止将此类跨 authority 资源加入 Push Cache。可依照 RFC 9110 建议，在接收资源时进行 DNS 反查，确认 authority 指向的域名 IP 是否与当前连接一致。
• 对 CrossSXG 的应对：浏览器仅应接受由单域证书签名的 SXG 内容。禁止使用共享证书中任意域名进行“代签名”行为，从而杜绝域名伪装攻击。

7.2 CA（证书颁发机构）的责任与对策

• 改进证书撤销机制：当前共享证书只能被所有域名的所有者联合撤销或持有私钥一方撤销；应允许任何在证书 SAN 中列出的域名所有者单方面申请撤销证书；并建立更易用的受害方申诉机制。

7.3 域名注册商的辅助角色

在用户购买或转入域名时，主动提示该域名是否曾被包含在共享证书中；自动查询 CT 日志（Certificate Transparency），显示证书关联历史；向受影响用户和 CA 发出证书重签或撤销通知。

8.总结

本文所提出的 CrossPUSH 与 CrossSXG 攻击，不仅是协议层面的安全漏洞，更反映出现代 Web 信任模型在“证书共享”与“资源分发”之间的严重断层。 其防御不应仅靠某一方技术修补，而应浏览器厂商、CA 机构、注册商三方协作；协议标准更新；安全社区对共享证书的使用提出审慎态度。