Cross-Origin Web Attacks via HTTP/2 Server Push and Signed HTTP Exchange

Cross-Origin Web Attacks via HTTP/2 Server Push and Signed HTTP Exchange

Speakers: Pinji Chen, Jianjun Chen, Qi Li, Mingming Zhang, and Haixin Duan — Tsinghua University

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=IeHGk34HG3k

Reading time: ~7 minutes

Type: Briefing

TL;DR

Researchers from Tsinghua University discovered that HTTP/2 and HTTP/3 use a broader, certificate-based ("SAN-based") definition of origin that is more permissive than the URI-based same-origin policy enforced by browsers. By exploiting this gap through HTTP/2 Server Push and Signed HTTP Exchange (SXG), an off-path attacker who holds a certificate shared with a victim domain can inject malicious scripts, manipulate cookies, strip HSTS, and force malicious file downloads — without a man-in-the-middle position. Eleven top browsers and five default mobile browsers were found vulnerable; a real-world case against a Microsoft Windows Update subdomain was demonstrated.

Introduction

The same-origin policy (SOP) is the cornerstone of browser security: two resources share an origin only if their scheme, host, and port match exactly. This URI-based definition has been the browser security model since the Web's beginning. What the Tsinghua team discovered is that the HTTP protocol layer applies a different, substantially more permissive definition of origin — one based on the Subject Alternative Names (SANs) in a TLS certificate rather than on individual hostnames.

This mismatch creates a new class of attack. An adversary who obtains a certificate that includes both an attacker-controlled domain and a victim domain — through domain reselling, domain takeover, or certificate ecosystem gaps — can use HTTP/2 Server Push or Signed HTTP Exchange to deliver malicious resources that the browser accepts as belonging to the victim's origin.

The SAN-Based Origin Problem

RFC specifications for HTTP/2 and HTTP/3 define origin using the certificate's Subject Alternative Name list. Any host covered by the same TLS certificate is considered "same origin" at the protocol layer. A concrete illustration: Google's wildcard certificate includes android.com, youtube.com, and numerous other domains — under HTTP/2, all of these are same-origin with each other.

▶ Watch: SAN-Based Origin Explained (02:00)

Multi-domain certificate sharing is not a niche practice. Prior research at the ACM CCS conference found that 96% of TLS certificates contain multiple domains in their SAN list, and 3.2% include domains from different organizations. This means SAN-based origin regularly spans organizational boundaries — the exact scenario the same-origin policy was designed to prevent.

Cross-Push and Cross-SXG Attack Vectors

The Tsinghua team built two attack variants on top of this observation:

Cross-Push: HTTP/2 Server Push allows a server to proactively deliver resources to a client before they are requested. The push uses an Authority header to declare the origin of the pushed content. Because browsers check origin at the SAN/certificate level rather than the URI level, a server holding a shared certificate can push resources claiming to belong to the victim domain — and the browser will accept and execute them in the victim's context.

Cross-SXG: Signed HTTP Exchange (SXG/SSG) is a Google-backed mechanism for pre-signed, portable web content. An SXG package cryptographically binds content to a URL using a certificate. With a shared certificate, an attacker can sign content claiming to originate from the victim's domain, and browsers that support SXG will accept it as authentic victim-origin content.

▶ Watch: Attack Overview (04:00)

The attack scenario requires:

1. The attacker acquires a TLS certificate whose SAN includes the victim's domain.
2. The victim clicks a link to the attacker's site.
3. The attacker's server pushes a malicious script (or delivers a malicious SXG) claiming the victim's origin.
4. The browser accepts the cross-origin resource as same-origin and executes it in the victim's page context.

Exploitation Primitives

Because the attacker controls the entire HTTP response (headers and body), three exploitation paths are demonstrated:

Universal XSS: Inserting malicious JavaScript into the HTTP response body yields cross-site scripting that works regardless of whether the target site is live, offline, or even exists. Content Security Policy (CSP) cannot prevent it because the attacker sets no CSP header in the malicious response.

Cookie Manipulation / Session Fixation: The attacker uses Set-Cookie in the push response to overwrite the victim site's cookies with arbitrary values — including the attacker's own session cookie, enabling session fixation.

▶ Watch: Cookie Manipulation Demo (08:01)

HSTS Bypass: Setting Strict-Transport-Security: max-age=0 in the pushed response removes HSTS protection from the victim domain, exposing subsequent connections to downgrade attacks.

Malicious File Download: Combining Content-Disposition: attachment with a malicious binary body causes the browser to save an attacker-supplied file attributed to the trusted victim domain. Demo footage showed a Kali Linux payload silently downloaded and attributed to the victim site.

Making the Attack Practical: Certificate Acquisition, Duration, and Irrevocability

The primary precondition is obtaining a certificate that shares the victim's domain. The team identified two realistic paths:

Domain Reselling: An attacker registers many domains, issues a multi-domain certificate, then resells some of the included domains to victims while retaining the shared certificate. Because no mechanism ensures that certificate ownership tracks current domain ownership, the shared certificate remains valid even after the domain is transferred.

Domain Takeover: Dangling DNS records — CNAMEs pointing to deprovisioned VPS IPs, expired CDN endpoints, or lapsed domain registrations — allow an attacker to register the abandoned target, point DNS to attacker-controlled infrastructure, pass HTTP domain-validation for that name, and issue a certificate including both the attacker's domain and the hijacked victim domain.

▶ Watch: Attack Duration and Irrevocability (12:02)

Traditional domain-takeover attacks expire when the victim fixes the dangling DNS record. This attack persists until certificate expiration — typically 398 days. Domain Validation Reuse extends this further: a certificate authority allows re-use of a passing domain-ownership validation for up to 398 days. An attacker who renews the certificate on the last day before expiration can extend the effective window to 796 days — more than two years after the DNS issue is remediated.

Irrevocable certificates: To revoke a certificate via Let's Encrypt, the requestor must either control all domains in the certificate or hold the private key. A victim domain owner who does not control the other SANs in a shared certificate — and does not hold the private key — cannot revoke it. The team filed a report with ZeroSSL about an illegitimate shared certificate and received no reply.

Measurement Results

The team built an automated system called PS Checker, using a high-traffic website under their control to direct visitors to a measurement server that attempted Server Push and SXG cross-origin delivery, then checked for script execution.

▶ Watch: Measurement Findings (16:02)

Results after months of running:

• The latest versions of 11 top-used browsers and 5 default mobile browsers are vulnerable to at least one attack variant.
• Numerous celebrated mobile applications use built-in WebView components inherited from the mobile OS, extending the attack surface to third-party apps beyond browsers.
• Among Tranco top-1,000 websites, notable cases include: a subdomain of windowsupdate.com with a dangling CNAME that could be registered by any attacker; and baidu.com sharing a certificate with lower-ranked domains from different organizations.

The real-world Microsoft case: a windowsupdate.com subdomain CNAME pointed to unregistered qtrcdnet.com. The team registered that domain, configured it to pass HTTP-based domain validation, and issued a shared certificate. They then demonstrated cross-site scripting on the Microsoft domain before reporting it. Microsoft has since fixed the issue and the certificate has been revoked.

Seven vendors confirmed the vulnerability; five — including Huawei, Baidu, and Microsoft — have implemented fixes.

Notable Quotes

"Whether the target website has vulnerabilities, is offline, or no longer exists, our attack still works."

— Pinji Chen ▶ 06:00

"Our attack is still valid for more than two years even after the dangling DNS record is removed."

— Pinji Chen ▶ 14:02

"Such shared certificates are irrevocable by victims."

— Pinji Chen ▶ 14:02

Key Takeaways

• HTTP/2 and HTTP/3 use SAN-based origin, which is broader than URI-based origin: This protocol-level design decision creates a new attack surface that most browser security models did not account for.
• A shared certificate is sufficient to launch XSS, cookie manipulation, HSTS bypass, and file injection: No MITM position is required — the attacker only needs to lure the victim to their site.
• Certificate acquisition is practical: Domain reselling and domain takeover are both realistic paths; the Tranco top-1 million contains a measurable number of dangling and resold domains that are eligible attack conditions.
• Victims may be unable to revoke malicious shared certificates: The CA revocation model requires control of all SANs or the private key — neither of which the victim possesses.
• Browser vendors should enforce consistent authority checks and prefer single-domain certificates for SXG: Addressing this fully requires coordinated action from browsers, CAs, and the DNS ecosystem.

Slides PDF not available for this talk.