The Great Request Robbery: An Empirical Study of Client-side Request Hijacking Vulnerabilities on the Web

The Great Request Robbery: An Empirical Study of Client-side Request Hijacking Vulnerabilities on the Web

Speakers: Soheil Khodayari, Researcher, CISPA Helmholtz Center for Information Security; Thomas Barber, Researcher, SAP Security Research Group; Giancarlo Pellegrino, Research Group Leader, CISPA Helmholtz Center for Information Security

Conference: IEEE S&P

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

Overview

This talk, "The Great Request Robbery: An Empirical Study of Client-side Request Hijacking Vulnerabilities on the Web," presented by Soheil Khodayari, Thomas Barber, and Giancarlo Pellegrino, delves into a critical evolution of web security threats. While Cross-Site Request Forgery (CSRF) has historically been a well-understood and largely mitigated server-side vulnerability, recent advancements in client-side technologies have paved the way for new attack vectors. The speakers highlight that attackers are no longer solely reliant on the "confused deputy" flaw of traditional CSRF but are now exploiting insufficient input validation in client-side JavaScript to hijack requests originating from the victim's browser. This paradigm shift broadens the scope of potential attacks beyond mere state changes to include information leakage, arbitrary code execution, and open redirections.

The core of this research expands the concept of client-side CSRF into a more comprehensive category: client-side request hijacking. The presentation details an empirical study that identifies previously overlooked browser APIs capable of sending network requests, explores the vast attack surface these APIs present, and quantifies the prevalence of these vulnerabilities across a large dataset of popular websites. Furthermore, the researchers assess the efficacy of existing security countermeasures, revealing significant gaps in their ability to protect against these modern threats.

The importance of this work lies in its comprehensive identification of new attack primitives and its large-scale measurement of their prevalence. By demonstrating that nearly 10% of popular websites are vulnerable to some form of client-side request hijacking, the research underscores an urgent need for developers and security professionals to reconsider their defensive strategies. This talk not only exposes a widespread and underappreciated class of vulnerabilities but also provides a robust methodology for their detection and a critical evaluation of current mitigation techniques, urging a shift towards more robust client-side input validation and a deeper understanding of browser API security.

Background

▶ Watch: Introduction and traditional CSRF vulnerabilities (0:00)

Traditional Cross-Site Request Forgery (CSRF) has long been a notorious threat to web applications. In a classic CSRF attack, an attacker tricks a victim's browser into sending an unintentional, sensitive HTTP request to a vulnerable site where the victim is authenticated. This leverages the "confused deputy" flaw, where the server cannot distinguish between legitimate, user-initiated requests and malicious ones triggered by an attacker's page. Such attacks can lead to significant consequences, including account takeovers or unauthorized data modifications. Over the years, numerous defenses have been developed and widely adopted to combat traditional CSRF, such as origin checks, SameSite cookies (which prevent browsers from automatically submitting cookies in cross-site request contexts), and random anti-forgery tokens (which prevent attackers from reliably reconstructing and replaying requests). When properly enforced, these defenses have largely relegated traditional CSRF to a less critical concern.

However, the proliferation of client-side JavaScript frameworks and asynchronous communication patterns has introduced new variants of CSRF. As the speakers explain, attackers no longer need to rely on server-side confusion. Instead, they exploit insufficient input validation within client-side JavaScript programs. A prime example is when a script reads user-controlled input (like a URL hash fragment) and then uses it as an endpoint for an asynchronous request, potentially including a valid anti-forgery token. An attacker can craft a malicious URL containing a forged hash fragment and lure a victim to it. When the victim's browser loads the page, the client-side JavaScript executes, constructs a malicious request using the attacker-controlled input, and sends it, leading to a state change without the victim's consent or awareness. A similar vulnerability affected Instagram in 2018, demonstrating the real-world impact of this "client-side CSRF."

While prior work, including some by the speakers themselves, focused on client-side CSRF primarily through the lens of common asynchronous request APIs like XMLHttpRequest and fetch, a significant gap remained. Many other types of outgoing HTTP requests exist within JavaScript programs that could potentially be hijacked but had remained largely unexplored. These include WebSockets, Server-Sent Events, Push Notifications, and other asynchronous request APIs such as the sendBeacon API, which alone accounts for approximately 35% of asynchronous API calls on Tranco's top 10K domains. This realization prompted the researchers to pose several critical questions: Which browser APIs facilitate network requests? What are the full spectrum of consequences when an attacker controls inputs to these APIs? How prevalent are these vulnerabilities on the web, and what detection techniques can quantify this at scale? Finally, how effective are existing countermeasures against this broader class of client-side request hijacking vulnerabilities?

Key Findings

▶ Watch: Expanding scope to general client-side request hijacking (3:30)

The research presented in this talk yielded several significant findings that redefine the landscape of client-side web security:

1. Expanded Attack Surface: New Request APIs and Vulnerability Types Identified: The team compiled a comprehensive list of request-sending APIs by meticulously searching web request specifications. This led to the identification of 10 distinct request APIs across six broad request types (e.g., location, XMLHttpRequest, sendBeacon, WebSockets, Server-Sent Events, Push Notifications). For each API, they examined its capabilities (e.g., supported schemes, methods, configurable request parts like URL, body, headers) and default constraints (e.g., Same-Origin Policy). From this analysis, they identified 10 distinct client-side request hijacking vulnerabilities, of which seven are entirely new and two are new variants (meaning a new API or exploitation method for a known vulnerability). These expanded vulnerabilities include not only client-side CSRF but also information leakage, client-side XSS via JavaScript schemes, and open redirections.

1. Widespread API Usage and Unaddressed Attack Surface: A large-scale measurement of API usage on Tranco's top 10K domains revealed the ubiquity of request-related APIs. They observed approximately 7.9 million API calls across 1 million web pages in their dataset. Top-level navigation requests via location.href were present on over 8,000 sites, while asynchronous requests by XMLHttpRequest were the most widely used, with almost 3 million calls across over 400,000 pages. Crucially, the study found that over 44% of these API calls had not been considered by prior research, primarily due to the focus on new types of requests and APIs like sendBeacon. This highlights a vast, unaddressed attack surface.

1. High Prevalence of Request Hijacking Vulnerabilities: Using their novel detection framework, the researchers visited the top 10,000 most popular websites. After processing over 300,000 unique web pages, 11 million scripts, and 30 billion lines of code, they detected over 200,000 verified data flows across almost 1,000 sites. This means roughly 10% of the visited sites were vulnerable in some capacity. A significant portion of these findings — 36% of the cases — involved the new vulnerability types identified in their research, underscoring the importance of their expanded attack surface analysis.

1. Limitations of Purely Static Analysis and the Power of Hybrid Detection: The study revealed a critical limitation of traditional static analysis techniques: nearly two-thirds (66%) of the detected data flows would not have been found if the team had relied solely on static methods. This finding strongly validates their methodological contribution of a hybrid static-dynamic analysis approach, demonstrating that dynamic taint information is essential for reconstructing missing edges in program graphs and accurately identifying these complex client-side vulnerabilities.

1. Proven Exploitability on High-Profile Sites: To confirm the real-world impact, the researchers conducted exploitability analysis on a random subset of two pages from each vulnerable site. They successfully created Proof of Concepts (PoCs) for 49 sites, including several high-profile domains. These exploits led to severe consequences such as arbitrary code execution, account takeover, data exfiltration, and open redirects, confirming that these theoretical data flows translate into practical, high-impact attacks.

1. Ineffectiveness of Current Defenses: The analysis of existing policy-based and custom defenses revealed significant shortcomings. Content Security Policy (CSP) with connect-src could only mitigate 41% of detected vulnerabilities, primarily failing against same-site CSRF attacks. Cross-Origin Opener Policy (COOP) was even less effective, mitigating only 7% of vulnerabilities. Similarly, other defense-in-depth solutions like Cross-Origin Embedder Policy (COEP) and Fetch Metadata showed very low effectiveness. Furthermore, a deep dive into input validation patterns showed that about half of vulnerable data flows had no checks, and many others had insufficient (e.g., length, type, substring checks) or logically flawed checks, demonstrating a critical failure in developer practices.

Technical Deep Dive

▶ Watch: Identification of 10 different request-sending APIs (5:30)

To systematically study client-side request hijacking at scale, the researchers developed a sophisticated hybrid static-dynamic framework. This framework, dubbed Sheriff (the third iteration of the Draw analysis platform), is designed to overcome the limitations of purely static analysis by incorporating dynamic taint flows.

The pipeline of their framework consists of four major blocks:

1. Data Collection:

• The process begins with a list of target websites (Tranco top 10K domains).
• A custom crawler/orchestrator, built upon the Playwright browser automation framework, visits each site.
• During these visits, the crawler collects two primary types of data:
• All HTML and JavaScript web pages.
• Dynamic taint flows, gathered using a specially instrumented browser called Foxhound (based on Firefox). Foxhound tracks how user-controlled data propagates through the client-side JavaScript execution.

1. Pre-processing:

• The collected web pages undergo deduplication and prioritization to manage the large dataset efficiently.

1. Model Building (Hybrid Property Graphs):

• This is a key contribution of their methodology. Unique web pages are combined with the dynamic taint flows to construct taint-aware hybrid property graphs (HPGs).
• HPGs are a program representation that combines static structural information (like Control Flow Graphs - CFGs and Abstract Syntax Trees) with dynamic execution details (like concrete values for program variables).
• The crucial innovation here is the enhancement of these static graphs with dynamic taint flows obtained from Foxhound. Static analysis often suffers from missing edges in its graph representation due to the complexities of JavaScript's dynamic nature (e.g., reflection, dynamic property access). Foxhound's dynamic taint tracking allows the researchers to reconstruct these missing edges, providing a more complete and accurate representation of data flow within the client-side program.

1. Analysis:

• The HPGs are loaded into a Neo4j graph database.
• The researchers then formulate data flow analysis queries against this database. These queries identify paths where attacker-controlled input (the "source," such as a URL parameter or hash fragment) flows into a sensitive API call (the "sink," which are the 10 identified request-sending APIs).
• The queries are designed to detect various types of request hijacking, including URL forging, body manipulation, or header injection.

1. Verification:

• Once potential vulnerable data flows are identified, a final verification stage is performed.
• This involves instrumenting the identified APIs to confirm that the attacker-controlled data, when injected at the source, indeed manifests in the outgoing network request as predicted. This step ensures that the detected flows are not merely theoretical but represent actual, exploitable vulnerabilities.

The Foxhound browser, which is central to collecting dynamic taint flows, plays a critical role in addressing the inherent challenges of static JavaScript analysis. By tracking data propagation during runtime, it provides concrete paths and values that static analyzers might miss due to their inability to fully resolve dynamic constructs or execution paths. This hybrid approach allows for a far more accurate and comprehensive detection of client-side request hijacking vulnerabilities across a vast number of web applications.

Demo / Proof of Concept

▶ Watch: Discovery of 10 distinct request hijacking vulnerabilities (7 new) (6:15)

While the talk did not feature a live demo, the researchers extensively detailed their process for exploitability analysis and presented compelling case studies to demonstrate the practical impact of the identified client-side request hijacking vulnerabilities. Given the vast dataset of over 200,000 potentially vulnerable data flows, they focused their exploitability analysis on a random subset, specifically two pages from each of the approximately 1,000 vulnerable sites.

Their methodology for verifying exploitability involved building specific potential attacks:

• For Cross-Site Scripting (XSS), they checked if the JavaScript scheme could be used for request forgery.
• For CSRF-like attacks, they inspected server endpoints to determine which state changes could be triggered.
• For information leakage, they analyzed request bodies or parameters for sensitive data.
• For open redirects, they verified if top-level requests could redirect to arbitrary locations.

Through this rigorous process, they successfully created functional Proof of Concepts (PoCs) for 49 sites, including several high-profile domains. These PoCs demonstrated severe consequences such as arbitrary code execution, account takeover, data exfiltration, and open redirects.

The speakers highlighted three specific case studies:

1. Microsoft Azure (Confirmed and Patched): This was presented as the most prominent finding. The vulnerability involved a piece of JavaScript code that extracted a specific parameter from the URL's search query and then assigned this value directly to document.location for a top-level navigation request. In its mildest form, this could lead to client-side CSRF, allowing an attacker to manipulate user sessions. However, the researchers were able to escalate this to client-side XSS due to insufficient input validation. While some basic checks were performed, they were not effective enough to prevent the injection of malicious JavaScript.

1. TP-Link (Client-side XSS): A similar vulnerability was discovered in a TP-Link website. Here, the JavaScript code read query parameters and assigned them to location.href. This direct assignment, without adequate sanitization, allowed for escalation to client-side XSS. The only input validation observed was a check to ensure the screen width was below a certain value, which is entirely irrelevant and ineffective for mitigating URL-based injection attacks.

1. BBC Website (CSRF Token Leakage): This case study illustrated the power of their hybrid static-dynamic analysis. The vulnerability involved a complex data flow where a string, constructed from parameters, was used to create a function. This function was then stored in an array, and later, the function was retrieved from the array and called. This call, in turn, triggered a sendBeacon request, potentially leaking CSRF tokens or other sensitive information. The speakers explicitly noted that purely static analysis would have failed to detect these specific data flow edges due to the dynamic nature of function creation and array manipulation. Their Foxhound-augmented hybrid property graphs were crucial for tracing this complex, multi-stage data flow, demonstrating how the dynamic taint information filled the gaps left by static analysis.

These case studies vividly illustrate the diverse nature and severe impact of client-side request hijacking vulnerabilities, from session manipulation and arbitrary code execution to sensitive data leakage, and underscore the necessity of their advanced detection methodology.

Defensive Implications

▶ Watch: Introducing the hybrid static-dynamic detection framework (8:15)

The research unequivocally demonstrates that existing web security defenses, while necessary, are largely insufficient to completely mitigate the broad spectrum of client-side request hijacking vulnerabilities. Defenders must evolve their strategies to address these new attack vectors.

The speakers analyzed the efficacy of current countermeasures:

• Policy-Based Defenses:
• Content Security Policy (CSP): Specifically, the connect-src directive of CSP can constrain request endpoints to trusted domains, which is effective in preventing data exfiltration to arbitrary external sites. However, it falls short when the attack abuses same-site endpoints. The research found that even with a correctly configured CSP, 41% of the request hijacking vulnerabilities in their dataset could not be mitigated by CSP because they involve requests to the same origin.
• Cross-Origin Opener Policy (COOP): This policy restricts the browsing context to same-origin documents. While it can be effective in scenarios where window.open is used to provide malicious input (e.g., via postMessage broadcasts), the study found that COOP could not mitigate 93% of the detected vulnerabilities. Its limited scope makes it largely ineffective against the prevalent forms of client-side request hijacking.
• Cross-Origin Embedder Policy (COEP) and Fetch Metadata: These are other defense-in-depth solutions designed to control cross-origin embedding and provide request context to servers. However, similar to CSP and COOP, the researchers concluded that they have very low effectiveness against the identified client-side request hijacking vulnerabilities, failing to provide comprehensive protection.

• Custom Defenses: Input Validation:
• The most critical defensive implication highlighted is the dire state of input validation in client-side JavaScript. The researchers analyzed vulnerable data flows to understand common patterns and failures in validation. Their findings were alarming:
• No Checks: Approximately half of the detected data flows did not have any input checks whatsoever, leaving them completely exposed.
• Insufficient Checks: A significant number of data flows had trivial or insufficient checks. Examples include basic length or type checks, which are easily bypassed. Substring searches (e.g., checking for "bad.com") are also common but can be trivially circumvented (e.g., with "bad.com.evil.com").
• Logically Flawed Checks: Some checks were even logically flawed, such as comparing two attacker-controlled query parameters against one another, which provides no real security.

The core defensive implication is that developers must adopt a holistic and robust approach to client-side input validation. This goes beyond simple checks and requires a deep understanding of how user-controlled data can flow through JavaScript applications and influence network requests. Developers need to:

1. Identify all client-side APIs that can initiate network requests.
2. Treat all inputs derived from URL parameters, hash fragments, or other external sources as untrusted.
3. Implement strict allow-listing validation for all components of URLs, headers, and request bodies that are constructed using user-controlled input. This means explicitly defining what is allowed, rather than trying to block malicious patterns.
4. Recognize that server-side CSRF tokens and traditional CSRF defenses are not sufficient for client-side request hijacking.
5. Consider adopting sophisticated taint tracking mechanisms during development and testing to identify potential data flow vulnerabilities early.

In essence, the talk serves as a stark warning that the web's evolving client-side landscape demands a fundamental re-evaluation of security practices, placing a much greater emphasis on client-side input validation and a comprehensive understanding of browser API security.

Key Takeaways

• Client-side request hijacking is a broader and more dangerous threat than traditional client-side CSRF. It encompasses a wider range of browser APIs and attack consequences, extending beyond state changes to include information leakage, XSS, and open redirects.
• A vast, previously unaddressed attack surface exists. The research identified 10 distinct request-sending APIs, with over 44% of API calls in popular websites not considered by prior security studies.
• These vulnerabilities are ubiquitous and impactful. Nearly 10% of the top 10,000 websites were found to be vulnerable, with verified exploits leading to severe consequences like account takeovers and arbitrary code execution.
• Hybrid static-dynamic analysis is crucial for detection. Purely static analysis alone missed two-thirds of the detected vulnerabilities, highlighting the necessity of combining static program analysis with dynamic taint tracking (e.g., using Foxhound) to accurately identify complex data flows.
• Existing defenses are largely insufficient. Policy-based countermeasures like CSP and COOP offer limited protection, particularly against same-site request hijacking.
• Client-side input validation is critically flawed. A significant portion of vulnerable data flows either lacks any validation or employs easily bypassable or logically incorrect checks, making robust input sanitization an urgent priority for developers.

About the Speaker(s)

Soheil Khodayari is a researcher at CISPA Helmholtz Center for Information Security in Germany, where his work focuses on identifying and analyzing web security vulnerabilities.

Thomas Barber is a researcher with the SAP Security Research Group, contributing to the understanding and mitigation of security threats in enterprise software and web applications.

Giancarlo Pellegrino is a Research Group Leader at CISPA Helmholtz Center for Information Security in Germany. He is also Soheil Khodayari's advisor, guiding research into web security and privacy.