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, Chinuan University

Conference: NDSS Symposium

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

Overview

The talk "Cross-Origin Web Attacks via HTTP/2 Server Push and Signed HTTP Exchange," presented by Pinji Chen from Chinuan University, unveils a critical reinterpretation of web security's foundational Same-Origin Policy (SOP). The research demonstrates how modern web protocols, specifically HTTP/2 Server Push and Signed HTTP Exchange (SXG), inadvertently broaden the definition of an "origin" from the traditional URI-based approach to a more permissive Subject Alternative Name (SAN)-based model. This shift fundamentally undermines the SOP, creating novel attack vectors that allow malicious actors to bypass established security boundaries.

Chen's presentation highlights two new attack types: Cross-Push and Cross-SXG. These attacks leverage shared multi-domain certificates to deliver malicious scripts or content from an attacker-controlled domain to a victim's website, even if those domains belong to different organizations. Crucially, these are off-path attacks, meaning the attacker does not need to intercept network traffic, a significant departure from prior certificate-based attacks that typically required a man-in-the-middle (MiTM) position. The findings have profound implications for web security, affecting widely used browsers, mobile applications, and notable websites, necessitating urgent re-evaluation of how certificates and modern web delivery mechanisms interact with core security policies.

The research not only details the theoretical underpinnings of these vulnerabilities but also explores their practical feasibility, including methods for acquiring shared certificates, extending attack durations for up to 796 days, and even rendering illegitimate certificates effectively irrevocable. Through a large-scale measurement study, the team confirmed the widespread impact of these attacks across client-side browsers and server-side websites, presenting a compelling case for immediate action from browser vendors, certificate authorities, and domain owners to patch these architectural weaknesses.

Background

▶ Watch: Introduction: Undermining SOP with HTTP/2 Server Push & SXG (0:00)

The Same-Origin Policy (SOP) is a cornerstone of web security, a critical mechanism designed to isolate web resources from different origins. Its primary purpose is to prevent malicious scripts on one website from accessing sensitive data or manipulating content on another, thereby safeguarding user information against various cross-origin attacks like Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF). Traditionally, the SOP operates on a URI-based definition of origin, meaning two resources are considered to have the same origin only if their protocol, host, and port tuple are identical. Any deviation in these three components triggers the SOP, preventing direct interaction between the resources.

However, recent advancements in the HTTP protocol have introduced complexities that challenge this long-standing URI-based model. Specifically, HTTP/2 Server Push and Signed HTTP Exchange (SXG), two mechanisms designed to optimize web content delivery, have inadvertently broadened the concept of an origin. HTTP/2 Server Push allows a server to proactively send resources to a client before they are explicitly requested, anticipating future needs and reducing latency. Signed HTTP Exchange, on the other hand, enables content to be cryptographically signed by its original server and then delivered by a third-party server (like a CDN) while still retaining its original origin's integrity and security context.

The specifications for both HTTP/2 Server Push and SXG introduce a relaxed interpretation of origin, treating all domains listed in the Subject Alternative Name (SAN) field of a shared TLS certificate as belonging to the "same origin." The SAN field allows a single certificate to secure multiple domain names (e.g., example.com, www.example.com, blog.example.org). While useful for consolidating certificate management, this SAN-based origin model is significantly more permissive than the URI-based SOP. Prior research published at the CCS conference has already highlighted a potential issue, revealing that 96% of certificates contain multiple domains in their SAN list, and notably, 3.2% of these include domains belonging to entirely different organizations. This implies that a SAN-based origin can encompass disparate entities, creating a security gap where the relaxed origin policy of these modern web protocols interacts dangerously with the traditional SOP, laying the groundwork for novel cross-origin attacks.

Key Findings

▶ Watch: Methods for acquiring shared certificates: Reselling & Takeover (3:45)

The core discovery of this research is that the SAN-based origin model adopted by HTTP/2 Server Push and Signed HTTP Exchange fundamentally undermines the URI-based Same-Origin Policy. This architectural flaw allows attackers to deliver malicious content across distinct domains that merely share a common TLS certificate, even if these domains are owned by different organizations. Based on this, the researchers propose two novel attack vectors: Cross-Push and Cross-SXG.

The general attack flow for both vectors is as follows:

1. Acquire Shared Certificate: The attacker first obtains a multi-domain TLS certificate that includes both an attacker-controlled domain and a victim's domain.
2. Lure Victim: The attacker then lures the victim into visiting a malicious website controlled by the attacker.
3. Deliver Malicious Resource: When the victim visits the attacker's website, the attacker uses either HTTP/2 Server Push or Signed HTTP Exchange to deliver a script resource. Crucially, this resource is "signed" or "pushed" with its origin explicitly set to the victim's website (e.g., via the authority pseudo-header in HTTP/2).
4. Browser Execution: Due to the relaxed SAN-based origin policy, the browser accepts this malicious cross-origin resource as if it originated from the victim's domain. When the victim subsequently loads their legitimate website, this malicious script is executed in the context of the victim's origin.

This execution ultimately leads to severe consequences such as Cross-Site Scripting (XSS), allowing attackers to inject arbitrary client-side scripts, and cookie manipulation, enabling session hijacking or unauthorized data access.

A critical distinction of these attacks is their nature: they enable off-path attackers to launch practical web attacks. In contrast, prior work leveraging shared certificates for attacks typically required a man-in-the-middle (MiTM) position to intercept and modify traffic. Cross-Push and Cross-SXG, however, allow an attacker to initiate the attack from their own server, delivering the malicious payload directly to the victim's browser without needing to be on the network path between the victim and their legitimate website. This significantly lowers the barrier for exploitation and broadens the scope of potential threats.

The research also delved into the practicality of these attacks, addressing key questions:

• How to acquire the shared certificate? They identified methods like domain reselling and domain takeover.
• How to extend attack duration? They discovered domain validation reuse can prolong the attack window.
• How to bypass potential countermeasures? They demonstrated that an attacker-issued shared certificate can be made effectively irrevocable.

These findings collectively highlight a significant, previously overlooked vulnerability in the interaction between modern web protocols, certificate issuance practices, and fundamental web security policies, posing a substantial risk to user data and web application integrity.

Technical Deep Dive

▶ Watch: Extending attack duration with domain validation reuse (4:40)

The core technical vulnerability stems from the discrepancy between the traditional URI-based Same-Origin Policy and the SAN-based origin model introduced by HTTP/2 Server Push and Signed HTTP Exchange. For HTTP/2 Server Push, the server can specify the intended origin of a pushed resource using the :authority pseudo-header. If this authority matches any domain in the SAN list of the certificate used for the connection, browsers following the relaxed SAN-based origin interpretation will treat the pushed resource as coming from that origin, regardless of the actual server pushing it. Similarly, Signed HTTP Exchange, designed for pre-fetching and caching, cryptographically binds content to an origin derived from the certificate used to sign it. If an attacker controls a domain within a multi-domain certificate that also includes a victim's domain, they can craft SXG content that, when delivered, is perceived by the browser as legitimate content from the victim's origin.

To execute these attacks, an attacker must first acquire a shared multi-domain certificate. The researchers identified two primary methods:

1. Domain Reselling: An attacker can purchase numerous domain names and then obtain a multi-domain certificate covering all of them. Subsequently, they can resell some of these domains to unsuspecting victims while retaining the original shared certificate. Even after the victim purchases and uses the domain, the attacker still possesses the shared certificate, allowing them to impersonate the victim's domain via the SAN-based origin relaxation.
2. Domain Takeover: This method exploits vulnerabilities in domain lifecycle management. It occurs when domain names point to deprovisioned Virtual Private Servers (VPS) or expired domain names, leaving dangling DNS records. Since these targets are publicly available, an attacker can register these abandoned services, reconfigure their DNS records to point to attacker-controlled infrastructure, and then issue a new certificate via automated certificate management protocols (like ACME, utilizing the HTTP-01 challenge). This new certificate will include the hijacked domain name alongside the attacker's own domains, thereby creating the shared certificate condition. A notable example cited was a subdomain of windowsupdate.com from Microsoft, which was found to be dangling and potentially susceptible to takeover.

The practicality of an attack is also heavily influenced by its duration. Traditional domain takeover attacks are often invalidated once the legitimate owner removes the dangling DNS record. However, the researchers found that their attacks are more persistent, remaining valid until the certificate expires, which typically takes 398 days. Furthermore, they discovered a mechanism called domain validation reuse that can significantly extend this period. Many Certificate Authorities (CAs) allow applicants who have previously passed domain ownership validation to skip revalidation when applying for a new certificate within a specific timeframe (often up to 398 days). An attacker can exploit this by reapplying for a new certificate on the last day before the current certificate expires, effectively extending the attack duration from 398 days to a maximum of 796 days.

A critical aspect of the research involved exploring countermeasures and how to bypass them, particularly certificate revocation. To revoke a certificate, one of two conditions must typically be met: the issuer must pass domain ownership validation for all domains included in the certificate, or they must possess the private key. If an attacker issues a shared certificate that includes both their domain and a victim's domain, the victim, only owning their specific domain, does not meet the condition of validating all domains on the certificate. Consequently, the victim cannot independently initiate a revocation request for the entire shared certificate. The researchers conducted an experiment with ZeroSSL, reporting an illegitimate certificate shared with their domains on the official problem reporting platform, but received no reply, demonstrating the practical difficulty of revoking such certificates. This makes attacker-issued shared certificates effectively irrevocable from the victim's perspective.

To evaluate the real-world impact, a large-scale measurement study was conducted:

• Client-side Measurements: Tested top-used browsers (from StatCounter), default browsers on leading mobile operating systems, and popular applications from app stores. The results showed that the latest versions of 11 top-used browsers and five default mobile browsers were vulnerable to at least one of the proposed attacks. Mobile browsers were deemed a more severe threat due to their higher traffic contribution. Surprisingly, many "celebrated applications" used built-in browsers based on mobile OS web view components, inheriting the same vulnerabilities and significantly extending the attack surface from browsers to third-party applications.
• Server-side Measurements: Analyzed the Tranco 1 million domains to identify websites vulnerable to shared certificate acquisition via domain reselling or dangling domains. Additionally, they measured existing certificate-sharing domains within the Tranco top 10,000. Numerous websites were found to be affected. For instance, ftstatic.com, ranked 3,895, was once resold from an Australian food company to an American advertising agency, creating a potential exploitation scenario for the original domain owner. The aforementioned dangling subdomain of windowsupdate.com from Microsoft was also identified. Furthermore, many top-ranked domains were found to share certificates with low-ranked domains, often from different organizations, a fact confirmed by analysis of bad.com. These findings underscore the widespread and practical nature of these vulnerabilities across both client and server ecosystems.

Demo / Proof of Concept

▶ Watch: Real-world impact: Vulnerable browsers and mobile apps (7:00)

The presentation included a demonstration of the proposed attacks. While the specific steps of the live demo were not detailed in the transcript, the speaker explicitly mentioned, "You can scan the QR code below to see our attack demo." Based on the technical findings, this demonstration would likely have showcased a Cross-Push or Cross-SXG attack in action.

A typical proof-of-concept for these attacks would involve:

1. An attacker setting up a server with a multi-domain certificate, including a domain controlled by the attacker and a domain meant to represent a victim's website.
2. The attacker's server then uses HTTP/2 Server Push or crafts a Signed HTTP Exchange to deliver a malicious JavaScript payload, setting its origin to the victim's domain name (as listed in the shared certificate).
3. When a vulnerable browser loads the attacker's page and then subsequently navigates to or loads content from the victim's site (or if the pushed/SXG content targets the victim's origin directly), the malicious script would be executed within the security context of the victim's domain.
4. The demonstration would then visually confirm the success of the attack, for example, by displaying an alert box showing the victim's cookies (document.cookie), demonstrating XSS, or performing unauthorized actions on the victim's behalf, thus proving cookie manipulation or other exploitations. The mention of affected notable websites like Microsoft and Baidu suggests that the demo might have illustrated potential impact on such platforms, albeit in a controlled environment.

Defensive Implications

▶ Watch: Proposed countermeasures for browsers, CAs, and users (9:00)

The findings presented by Pinji Chen necessitate a multi-faceted approach to mitigation, requiring action from browser vendors, certificate authorities, and domain owners/users. The current state of affairs, where SAN-based origin relaxation interacts with certificate issuance practices, creates significant security gaps that must be addressed.

For browser vendors, the primary responsibility lies in tightening their interpretation of the Same-Origin Policy in the context of modern web protocols:

• Enforce Consistent Authority Checks: Browsers should enforce stricter, URI-based authority checks for resources delivered via HTTP/2 Server Push. This would prevent an attacker from pushing content to a victim's origin simply because they share a certificate. The :authority pseudo-header should be validated against the exact origin of the connection, not just any domain in the certificate's SAN list. This would directly mitigate Cross-Push attacks.
• Enforce Single-Domain Certificates (for SXG): While challenging to implement universally without impacting legitimate use cases, browsers could consider stricter origin validation for Signed HTTP Exchange. One radical proposal is to enforce that SXG content is only considered valid if the certificate used for signing covers only the specific domain of the content's origin, or at least that the origin specified in the SXG metadata strictly matches the primary domain of the certificate, rather than any domain in the SAN list. This would prevent Cross-SXG attacks where an attacker uses a multi-domain certificate to deliver content for a victim's origin.

Certificate Authorities (CAs) play a crucial role in preventing the initial conditions for these attacks:

• Provide a Mechanism for Domain Owners to Remove Domains: CAs should implement a user-friendly and robust mechanism that allows individual domain owners to remove their specific domain from any shared certificate that they did not explicitly authorize or that they no longer wish to be associated with. This would empower victims to revoke the "shared" aspect of a certificate without needing to own all domains on it, directly addressing the issue of effectively irrevocable certificates.
• Stricter Validation for Multi-Domain Certificates: CAs should review and potentially strengthen their validation procedures for multi-domain certificates, especially when domains belong to different organizational entities. While challenging to automate, flags or warnings could be raised for certificates covering domains with disparate WHOIS information, requiring additional manual verification.

For users and domain owners, proactive measures are essential to detect and prevent these attacks:

• Regularly Inspect Certificate Status: Domain owners should regularly inspect the TLS certificates issued for their domains using tools like Certificate Transparency logs. This allows them to detect any unauthorized multi-domain certificates that include their domain alongside others they do not control.
• Monitor Domain Registration and DNS Records: Vigilance is key to preventing domain takeover. Domain owners must ensure that their DNS records are always pointing to active, controlled infrastructure and that expired domains are properly managed to prevent their reclamation by malicious actors.
• Implement Content Security Policy (CSP): While not a direct mitigation for the underlying SAN-based origin issue, a robust Content Security Policy (CSP) can act as a secondary defense layer. By strictly defining allowed sources for scripts, styles, and other resources, CSP can help prevent the execution of malicious scripts even if they are successfully delivered and perceived as same-origin by the browser. For example, a strict script-src 'self' policy would prevent scripts from executing if they were pushed from an attacker's server, even if the browser considered them same-origin due to a shared certificate.

The responsible disclosure to vendors like Huawei, Baidu, and Microsoft, and the positive feedback received, indicates a recognition of the severity of these vulnerabilities. Collaborative efforts across the web ecosystem are crucial to fully mitigate these sophisticated cross-origin attacks.

Key Takeaways

• The traditional URI-based Same-Origin Policy (SOP) is undermined by modern web protocols like HTTP/2 Server Push and Signed HTTP Exchange (SXG), which adopt a more permissive Subject Alternative Name (SAN)-based origin model.
• This discrepancy enables two novel off-path cross-origin attacks: Cross-Push and Cross-SXG, allowing attackers to deliver malicious scripts from their domain to a victim's domain if they share a TLS certificate.
• Attackers can acquire shared certificates through methods like domain reselling and domain takeover (e.g., exploiting dangling DNS records), and can extend the attack duration for up to 796 days using domain validation reuse.
• Crucially, attacker-issued shared certificates can be made effectively irrevocable from the victim's perspective, as victims often cannot meet the full revocation criteria for multi-domain certificates.
• The attacks have a widespread impact, affecting top-used browsers (e.g., Chrome, Edge), mobile browsers, third-party applications using web views, and notable websites including those from Microsoft and Baidu.
• Mitigation requires concerted efforts: browser vendors must enforce stricter authority checks and potentially single-domain certificate policies, Certificate Authorities should provide domain removal mechanisms, and domain owners must diligently monitor certificate status and manage DNS records.

About the Speaker(s)

Pinji Chen is a researcher from Chinuan University. During the NDSS Symposium, Chen presented their team's research on novel cross-origin web attacks leveraging HTTP/2 Server Push and Signed HTTP Exchange. Their work focuses on identifying and analyzing security vulnerabilities arising from the interaction between modern web protocols and fundamental web security policies, contributing significantly to the understanding of contemporary web attack vectors and their practical implications.