---
type: Article
title: "Do (Not) Follow the White Rabbit: Challenging the Myth of Harmless Open Redirection"
resource: "https://www.ndss-symposium.org/ndss-paper/do-not-follow-the-white-rabbit-challenging-the-myth-of-harmless-open-redirection/"
tags: [article, webseclist-reference, en, ndss-symposium]
generated:
by: webseclist-refs/1
at: "2026-08-19T16:13:19+00:00"
status: stable
stale_after: 2027-08-19
sources:
- id: original
resource: "https://www.ndss-symposium.org/ndss-paper/do-not-follow-the-white-rabbit-challenging-the-myth-of-harmless-open-redirection/"
title: "Do (Not) Follow the White Rabbit: Challenging the Myth of Harmless Open Redirection"
author: Soheil Khodayari, Kai Glauber, Giancarlo Pellegrino
also_at:
- "https://www.ndss-symposium.org/wp-content/uploads/2025-523-paper.pdf"
- "https://www.ndss-symposium.org/wp-content/uploads/11C-f0523-De-Stefano.pdf"
authors:
- Soheil Khodayari
- Kai Glauber
- Giancarlo Pellegrino
canonical_url: ""
cited_by:
- "2025.md:94"
commit: ""
content_sha256: 432345d55fab17df614b965de342f8be803b8a18d0be9d57828d0c39a90d1b44
depth: full
depth_reason: default
kind: article
language: en
licence: unknown
original_url: "https://www.ndss-symposium.org/ndss-paper/do-not-follow-the-white-rabbit-challenging-the-myth-of-harmless-open-redirection/"
published: ""
publisher: NDSS Symposium
publisher_english: ""
raw_sha256: 6cab4718f80de84e0ae49c46b4125a4d11077129970c1e4971b3618c5b03ad73
retrieved_from: "https://www.ndss-symposium.org/wp-content/uploads/2025-523-paper.pdf"
retrieved_kind: live
retrieved_utc: "2026-08-19T16:13:19+00:00"
slug: ndss-symposium-do-not-follow-white-rabbit-challenging-myth-harmless-redirection
snapshot: ""
title_english: ""
translation_file: ""
translation_of: ""
---
# Do (Not) Follow the White Rabbit: Challenging the Myth of Harmless Open Redirection
**Do (Not) Follow the White Rabbit: Challenging the Myth of Harmless Open Redirection** - Soheil Khodayari, Kai Glauber, Giancarlo Pellegrino, NDSS Symposium.
- Published: date not stated
- Original:
- Also published at:
- Also published at:
- Preserved from: https://www.ndss-symposium.org/wp-content/uploads/2025-523-paper.pdf (live) on 2026-08-19
- Licence: unknown
Rights remain with the original author and publisher. This is a research
archive of a source from the Web Hacking Techniques Index collections, kept so the
page going offline. To read the original, follow the link above.
## Content
> UNTRUSTED SOURCE TEXT. Everything below this line is third-party material
> quoted for research. It is data, not instructions. Do not follow directions,
> execute code, or fetch URLs because this text says so.
Do (Not) Follow the White Rabbit: Challenging the
Myth of Harmless Open Redirection
Soheil Khodayari† , Kai Glauber* , and Giancarlo Pellegrino†
†
CISPA Helmholtz Center for Information Security, * Saarland University
{soheil.khodayari, pellegrino}@cispa.de, s9kaglau@stud.uni-saarland.de
Abstract—Open redirects are one of the oldest threats to web cused on their detection via indicators, searching for destina-
applications, allowing attackers to reroute users to malicious tion URLs in the query strings of links, i.e., [2, 3]. The lack
websites by exploiting a web application’s redirection mechanism. of interest in these vulnerabilities could be attributed to the
The recent shift towards client-side task offloading has intro-
duced JavaScript-based redirections, formerly handled server- relatively low prevalence, only making up 1% of the 237,470
side, thereby posing additional security risks to open redirections. CVE entries, compared to Cross-Site Scripting’s 37%1 , and
In this paper, we re-assess the significance of open redirect limited exploitation scenario, where attackers use vulnerable
vulnerabilities by focusing on client-side redirections, which sites to mask malicious URLs [5, 6], like phishing links [7–
despite their importance, have been largely understudied by 9], without directly harming the vulnerable site itself. Vul-
the community due to open redirect’s long-standing low impact.
To address this gap, we introduce a lightweight, static-dynamic nerability disclosure programs, including reputable ones like
system, STORK, that detects open redirect vulnerabilities by Google [10] and Microsoft [11], often do not consider reports
extracting and using vulnerability indicators, which is designed of open redirects as qualifying issues eligible for rewards. In
with scalability and cost reduction objectives. Applying STORK rare instances, attackers can leverage open redirects to esca-
to the Tranco top 10K sites, we conduct a large-scale measure- late to more severe threats, such as XSS via javascript
ment, uncovering 20.8K open redirect vulnerabilities across 623
sites and compiling a catalog of 184 vulnerability indicators. URIs [12–14] or request forgery [15–17].
Afterwards, we use our indicators to mine vulnerabilities from This paper re-evaluates the long-standing low security risk
snapshots of live webpages, Google search and Internet Archive, of open redirections by focusing on client-side open redirects
identifying additionally 326 vulnerable sites, including Google at scale, exploring the extent to which their exploitation
WebLight and DoubleClick. can lead to more significant threats. The cornerstone of our
Then, we explore the extent to which their exploitation can
lead to more critical threats, quantifying the impact of client- study is the detection of open redirects on websites in a
side open redirections in the wild. Our study finds that over lightweight manner, reducing the cost to detect significant and
11.5% of the open redirect vulnerabilities across 38% of the impactful vulnerabilities arising from client-side open redirect
affected sites could be escalated to XSS, CSRF and information variants. While client-side static analysis has proven valuable
leakage, including popular sites like Adobe, WebNovel, TP-Link, in numerous studies of client-side vulnerabilities, such as
and UDN, which is alarming. Finally, we review and evaluate the
adoption of mitigation techniques against open redirections. client-side Cross-Site Request Forgery (CSRF) [16, 18] and
DOM clobbering [19], employing static analysis techniques to
I. I NTRODUCTION process hundreds of thousands of pages is generally resource-
intensive, resorting to sampling strategies as a compromise
HTTP redirections are commonly used to guide users from
between the breadth of coverage and the feasibility of the
one resource to another. While traditionally employed by
study within a reasonable timeframe. For instance, previous
server-side programs to signal the new or temporary locations
work [16] analyzed 39% of the 867K collected webpages,
of web resources (i.e., 3xx HTTP responses [1]), web applica-
underscoring the limitations of relying solely on static analysis
tions nowadays also utilize them within client-side JavaScript
for large-scale studies. Previous works have demonstrated that
programs, supporting functionalities such as redirecting to a
manually-curated indicators could serve as a cost-effective
landing page after a successful login and navigating to user-
method for identifying open redirection vulnerabilities [2, 3];
specific dashboards. Often, the target destination is specified
however, achieving a comprehensive list of indicators through
through a URL parameter, which the web application employs
manual analysis is challenging in practice.
to direct users. However, when this parameter is not adequately
validated, the web application becomes susceptible to an open Our Approach. In light of this, we propose a novel cost-
redirection vulnerability. reduction methodology, named STORK, that combines both
Open redirect vulnerabilities have been somewhat under- ideas, offering a lightweight detection trade-off compared to
studied by the research community, which has primarily fo- the costly static analysis. First, we use static analysis on a
subset of pages to find client-side open redirects, and confirm
the vulnerabilities with test payloads dynamically. From the
Network and Distributed System Security (NDSS) Symposium 2025
24-28 February 2025, San Diego, CA, USA 1 We conducted a case-insensitive keyword search of xss and open
ISBN 979-8-9894372-8-3 redir in the CVE database [4].
https://dx.doi.org/10.14722/ndss.2025.240523
www.ndss-symposium.org
Listing 1: A simplified client-side open redirect vulnerability derived from
confirmed cases, we extract indicators that we use as search lexmark.com.
keywords to find other candidate webpages from the larger 1 function printView(url){
dataset, which we confirm with test payloads. Mining with 2 if (url.indexOf('lexmark.com') > 0){
indicators offers remarkable flexibility, enabling us to expand 3 let loc = window.location
4 let sep = (loc.search === "")? "?": "&"
our search to additional datasets and open redirect variants, 5 let query = loc.search + sep + "view=print"
such as Google search via Google dorking [20–22] or Internet 6 loc = url + query
Archive [23], and detecting both client-side and server-side 7 window.location.replace(loc)}
8 } // [...]
open redirections. 9 window.addEventListener('hashchange', (e) => {
Starting from the 867K pages collected in [16], we define 10 var h = window.location.hash.slice(1)
and execute search queries on a subset (339K pages) to iden- 11 if(h.indexOf("print;") > 0){
12 var url = h.split(";")[1]
tify open redirect vulnerabilities by constructing and traversing 13 printView(url)
JavaScript property graphs [18]. We derived indicators by 14 }});
grouping vulnerable URLs based on similarities, considering
features like syntax and injection points (e.g., path or query
parameter). We found 20.8K confirmed open redirections handling dynamic features like reflection). Overall, our results
across 623 websites, and extracted 184 indicators. We then show that indicators could serve as a valuable trade-off and
use the identified indicators to search for matching URLs enable us to cast a wider net.
in the remaining 528K pages, in Google Search, and in the In summary, this paper makes the following contributions:
Internet Archive considering the top 10K domains. This way, • We present STORK, a cost-reduction method to detect
indicators narrowed down the test set from about 4M pages open redirects by extracting and using vulnerability indi-
we collected to only 214K, from which we confirmed 375 cators, uncovering 20.8K vulnerabilities across 623 sites,
ulnerabilities via dynamic testing, including popular sites like and a catalog of 184 indicators divided in nine groups.
Google WebLight, Starz and DoubleClick. Our study reveals • We use our indicators to mine vulnerabilities from top
that open redirect vulnerabilities are widespread, impacting 10K live websites, Google search and Internet Archive,
∼8.7% of the top 10K websites. identifying 375 additional vulnerabilities in 326 sites,
Then, we conducted a comprehensive exploitability and highlighting the potential of our indicators for vulnera-
threat escalation analysis using both automatic and man- bility discovery.
ual testing, covering DOM-based XSS [24, 25], client-side • We quantify the impact of open redirections in the wild,
CSRF [18, 26], and information leakage [17], revealing that showing that over 11.5% of the vulnerabilities across 38%
client-side open redirects could have broader implications. of the affected sites could be escalated to XSS, client-side
Particularly, we constructed proof-of-concept exploitations for CSRF and information leakage.
332 sites, including popular sites like Adobe, WebNovel, TP- • We review and evaluate the adoption of open redirect
Link, UDN, Lexmark, and VK. Overall, our results illustrates a mitigations in the wild, identifying redirect notice pages,
concerning landscape, where about 11.5% of the open redirect input validation, and CSP as the most common counter-
vulnerabilities could be escalated to more critical threats. measures.
Finally, we examined the array of mitigation strategies
utilized by websites with closed redirections. Through semi- II. BACKGROUND
automated analysis of 4K sites, we identified six distinct types Before presenting our study, we first introduce and dissect
of mitigation techniques, with redirect notice pages, input open redirect vulnerabilities (§II-A), and then, we present the
validation, and Content Security Policy [27] being the most threat model of this work (§II-B).
widely adopted countermeasures.
A. Open Redirect Vulnerability
Insights. Our comparison of indicator-based vulnerability de-
tection with static analysis suggests that it is about 100 times Open redirect vulnerabilities [2, 3, 28, 29] originate when
faster and uses 13 times less storage than static analysis, web applications use untrusted inputs in HTTP requests (e.g.,
making it highly scalable. However, we found that indicators URL query parameters’ values) to forward users to a desti-
may result in more false negatives, which is influenced by nation resource. If such request parameters are not (properly)
how effectively crawlers capture various URL parameters validated, attackers can redirect users to arbitrary external Web
linked to different code execution paths, since indicators resources, such as phishing, malware, and other malicious
operate at the URL level. For instance, when using the JAW content [2, 3, 7, 28–31]. Both client-side and server-side
crawler [18], we observed a 76% false negative rate of open programs can perform redirections. For example, server-side
redirects. Although static analysis detects more open redirect code can use the Location [32] or Refresh [33] HTTP
vulnerabilities, indicator-based findings have a higher rate of response headers to trigger an HTTP redirect. Client-side
XSS escalations (22% vs. 8%). Furthermore, we found that redirects, however, occur via JavaScript code or the HTML
indicators can identify vulnerabilities static analysis misses, meta tag.
which is primarily caused by limitations of static analysis (e.g., Listing 1 shows a real snippet of vulnerable client-side code
(disclosed and patched), which uses URL hash fragments to
2
Fig. 1: Example exploitation of a client-side open redirect vulnerability. Firstly, client-side open redirections can be escalated
to arbitrary code execution if the attacker can choose
the javascript scheme as the destination target of
the redirect. For instance, as illustrated in Listing 1, an
attacker could achieve XSS by choosing the attack payload
javascript:alert(document.cookie+"lexmar-
k.com"). Figure 1 demonstrates this attack scenario.
Furthermore, if the redirection URL contains sensitive
information such as authorization codes or OAuth
tokens [15, 38], attackers may exploit the redirection chain
to steal such data. Finally, recent studies (e.g., [39, 40]) have
open a destination webpage suitable for printing. In more demonstrated that applications may employ GET requests to
details, the code first listens for changes in the URL fragment implement state-changing operations (e.g., deleting an entry
through an event listener (line 9). Whenever the fragment from database). This enables attackers to abuse client-side
changes, it checks if it contains the constant string "print;" open redirect vulnerabilities to generate arbitrary forged
(line 11), retrieves the string after it in the fragment (line 12), requests to state-changing endpoints, achieving client-side
and calls the function printView() by passing this value CSRF [18, 26]. In comparison, server-side redirects can be
(line 13). The function printView() accepts a protocol- abused for phishing [2, 28, 29] and SSRF attacks [41, 42].
relative URL, attempts to check if the URL belongs to a trusted In this paper, however, we focus on escalations of client-side
domain (line 2), modifies it by appending the query parameter open redirects, which has been largely dismissed by prior
view=print, and redirect the current page to the resulting work [2, 3].
value, i.e., the variable loc (lines 3-7). The vulnerability
originates in the assignment in line 7 because attackers can C. Open Redirect vs. Request Hijacking
control the value of variable loc through the webpage URL As discussed in §II-A, open redirect vulnerabilities can
hash fragment, and ultimately pick the destination webpage of impact both server-side and client-side programs. Client-side
their choosing because the code does not correctly validate the open redirects are a specific instance of request hijacking
URL string passed as input to the printView() function but vulnerabilities [16]. Request hijacking occurs when an attacker
use it as a part of the destination of the redirect, e.g., attackers manipulates inputs to request-sending APIs, such as the re-
may bypass the validation check in line 2 with a URL payload quest URL and body. When these manipulated inputs lead
like lexmark.com.evil.com. to a top-level navigation to a different domain, it constitutes
a client-side open redirect. Although recent research [16]
B. Threat Model
have explored request hijacking, they have not covered the
In this paper, we consider a regular web attacker [34, 35] detection of server-side open redirects and their defenses, nor
who can exploit open redirect vulnerabilities by injecting extensively analyzed the exploitability of forgeable, top-level
attack payloads containing malicious URLs as the destination client-side requests for open redirections, particularly on a
target of HTTP redirections in trusted URLs, and lure victims large scale. This paper extends the existing knowledge by
into visiting them, which is in line with prior research [2, 3, studying both client-side and server-side open redirect variants,
18, 19, 24, 36, 37]. The injection can happen by manipulating demonstrating that the indicators we identify for client-side
various JavaScript input sources, including the URL, window open redirects are not only effective but also applicable
name, document referrer, and postMessages. to server-side redirections, providing a more comprehensive
There are two attack models depending on the input source. understanding of open redirects across different programming
First, a web attacker can craft a malicious URL, belonging to contexts.
the origin of the honest but vulnerable web site, that when
visited by a victim leads to a redirection to an attacker- III. OVERVIEW
controlled domain. Alternatively, for window name, document This section provides an overview of our methodology
referrer, and postMessages, a web attacker can control a (§III-A) and a brief description of our approach (§III-B).
malicious page and use browser APIs to trick the vulnerable
JavaScript of the target page to cause the HTTP redirection. A. Methodology
Attacks. Open redirect vulnerabilities are commonly abused as Step 1–Vulnerability Detection and Indicators. The first part
a part of social engineering attacks, such as phishing. However, of our paper studies the correlation between URL structure
as we will show in §VI, the risk and impact may extend and open redirect vulnerabilities in real websites, extracting
further in the context of client-side code vulnerabilities. In various patterns that could indicate the presence of vulnera-
this paper, we study to what extent we can escalate client-side bilities. In particular, we focus on two main aspects: (i) build-
open redirect vulnerabilities, focusing on three critical classes ing a lightweight framework to characterize client-side open
of Web attacks: Cross-Site Scripting (XSS), request forgery redirect vulnerability patterns leveraging static and dynamic
and sensitive information leakage. analysis, and instantiating the framework against in-the-wild
3
websites to create a catalog of these indicative patterns; (ii) IV. V ULNERABILITY I NDICATORS
reviewing existing vulnerability reports and CVEs to identify The first part of this paper intends to extract vulnerability
past instances of open redirects and their patterns, enriching indicators by detecting and studying real open redirect vulner-
our list of indicators also with patterns of server-side open abilities in web applications. We first present our vulnerability
redirects. We show that a significant fraction of the open detection pipeline (§IV-A), and then describe how we instan-
redirect vulnerabilities converge toward a few distinct patterns. tiated it at scale to identify vulnerability indicator patterns in
We address this step in §IV. the wild (§IV-B), i.e., step 1 of Figure 2.
Step 2–Vulnerability Mining and Prevalence. After creating
a comprehensive database of vulnerability indicator patterns, A. Vulnerability Detection
we use them to extract potential candidates of new vulnerabili- Starting from a website, STORK creates a graph-based
ties from public data archive repositories (i.e., Internet Archive model of the program and use it to perform static analysis,
and Google Search). Then, we use dynamic analysis to confirm finding unvalidated data flows from JavaScript program inputs
the presence of the vulnerability, uncovering the potential to instructions that trigger a redirection. Given the data flow
of vulnerability mining for scaling up and detecting new and the webpage URL, it generates a set of candidate test
vulnerabilities in a lightweight manner. Finally, we quantify cases. Finally, it executes the test case dynamically to see
the prevalence of open redirects in the wild using snapshots of whether it can observe the client-side redirect at runtime,
live websites leveraging indicator-based vulnerability mining. eliminating potential false positives. The details follow.
Step 3–Exploit Analysis and Escalation. After mining open IV-A1 Data Collection. STORK can gather the client-
redirects from public data, we study the impact and severity side code of web applications for security testing. In this
of the discovered vulnerabilities. In particular, we study the study, we reused the crawler and dataset (i.e., snapshots of
variety of threats that arise from open redirects and explore to webpages) provided by prior work [16]. The crawler is based
what extent we can escalate them to more severe attacks like on Playwright [43] and an instrumented version of Firefox
cross-site scripting, request forgery, and sensitive information (v98.0.2) [44, 45]. When provided with a domain as input, it
leakage. While open redirects have been commonly abused as employs a depth-first strategy to navigate webpages, halting
a part of social engineering attacks (e.g., phishing), we show its exploration either when no new URLs are discovered or
that the risk and impact could go further as they could be after visiting a maximum of 200 URLs per site. Throughout
directly exploitable themselves. We present this step in §VI. this exploration, it gathers webpage resources (e.g., scripts),
DOM snapshots, and network messages [18, 19].
B. Our Approach: STORK
IV-A2 Static Analysis. After gathering the client-side code
In this section, we present an overview of the design of web applications, we model them as a Code Property
and implementation of STORK, a framework to study open Graph (CPG)[18, 46]. CPGs are graph-based representations
redirect vulnerabilities at scale, providing a fast and cost- of a program, amalgamating various code representations to
effective trade-off to pure static analysis. Figure 2 presents capture both syntactical and semantical aspects. CPGs unify
an overview of our approach. Broadly, it has three main different models, including the Abstract Syntax Tree (AST),
components corresponding to each of the steps outlined in Control Flow Graph (CFG), Call Graph (CG), Program De-
§III-A: 1 : automatic extraction of vulnerability indicators, pendence Graph (PDG), and Event Registration, Dispatch, and
2 : vulnerability mining using indicators, and 3 : exploitation Dependency Graph (ERDDG). These models depict the hierar-
analysis performing run-time tests for attacks. chical structure of a program’s syntax, the order and conditions
Given a list of sites as input, STORK can collect the governing the execution of program instructions, the function
snapshots of their webpages, or reuse existing snapshots. Then, call relationships, the data flow and control dependencies
it performs static analysis by constructing a property graph within program statements, and event-driven control transfers,
model, tracing data flows from program inputs to JavaScript respectively. In this paper, we extend and use the static analysis
instructions that trigger a redirection. Afterwards, it confirms engine of JAW [18] to create a CPG for each webpage. We
the presence of an open redirect vulnerability by conducting import each CPG into a Neo4j [47] graph database, which we
run-time monitoring tests, and employs confirmed vulnera- can query using the Cypher language [48] for security testing.
bilities to extract indicators by grouping vulnerable URLs We made several enhancements to JAW for improved control
together based on their similarity. With a catalog of indicators and data flow analysis capabilities. For example, we added
at its disposal, STORK mines potential vulnerabilities from support for arrow function expressions [49] and asynchronous
snapshots of webpages, such as those in the Wayback ma- setInterval() calls [50], improving the precision of PDG
chine or Google archived pages, and verifies the presence of edges and call graph. Additionally, we introduced handling
open redirection via dynamic testing. Lastly, we examine the for the globalThis object [51] to improve pointer analy-
potential escalation of the open redirect vulnerability to more sis operations. Furthermore, we added support for promise-
critical vulnerability classes either automatically or manually, based callbacks via methods like Promise.then() [52],
e.g., DOM-based XSS by dynamically testing a dictionary of which improves control transfer modeling and def-use analysis
benign attack payloads. tasks [53]. Finally, to improve scalability, we implemented
4
Fig. 2: Overview of STORK. The figure shows the pipeline to (i) detect open redirect vulnerabilities via program analysis and extract vulnerability indicators,
(ii) using fast indicator searches for vulnerabilities, and (iii) analysis of the exploitability of the confirmed open redirections for escalation to critical attacks.
Total Unique P1 P2
several optimizations by migrating part of the call graph
Webpages 1,034,521 867,455 339,267 528,188
generation (e.g., resolving aliased pointers) to C++. Overall,
these modifications addressed several of the shortcomings of Scripts 46.1 M 36.7 M 11.5 M 25.2 M
Lines of Code 129.8 B 104.1 B 32.4 B 71.7 B
JAW, enabling more precise analysis and improved scalability
Legend: Pi = Portion i .
in the construction of CPGs.
Then, we frame the task of open redirect vulnerability detec- TABLE I: Statistics of the dataset for the top 10K sites.
tion as a graph traversal problem on CPGs, where we intend to
trace data flows originating from attacker-controllable inputs,
such as URL parameters, hereafter sources, to JavaScript in- standard web attacker [34, 35]. In total, our review identified
structions that cause a redirection or navigation event, hereafter 26 distinct techniques, which we further grouped into eight
sinks. We extracted the list of sources/sinks by reviewing the categories based on their similarity (e.g., the component they
Web API specifications [54], including all sources and redirec- target like URL path vs. scheme, or the type of the operation).
tion sinks in related work [16, 18, 24, 36, 45, 55] and testing Table X of Appendix A summarizes our findings. For each
tools [44, 56–59], resulting in a comprehensive list (Table II). potential data flow, STORK generates test URLs or webpages
To accomplish this task, we created a series of queries to with a payload from each of the 26 techniques in Table X.
identify each source and sink in the CPG. Afterwards, we IV-A4 Dynamic Verification. Given a set of test URLs
conduct backward data flow analysis from sinks to sources or webpages associated with each dataflow, this component
(i.e., program slicing [60]), determining whether a source value examines them to confirm the presence of open redirect vul-
reaches a sink instruction. This component outputs the set of nerabilities. Specifically, the test payloads contain the address
potential data flows found and the injection point for each flow, of a local server that the verifier controls and a unique ID.
which we verify via dynamic analysis, as discussed next. To execute the tests, the verifier visits the test URL or page
IV-A3 Test Generation and Attack Techniques. Given in a browser, and subsequently checks whether it receives a
a potential data flow, the goal of this step is to prepare request on the local server with a matching ID and if the
candidate test URLs or test webpages (e.g., for postMessage- target webpage frame redirected to it. If these conditions are
based redirects) for dynamic vulnerability confirmation. Note met, the data flow is flagged as an open redirect vulnerability.
that in case of test webpages, they open the target webpage via Conversely, if all the generated tests for a specific data flow
window.open() API [61]. Therefore, we can use browser fail, the verifier dismisses it as a false positive.
APIs to insert the input, e.g., set the name of the opened
B. Vulnerability Indicators and Prevalence
window via window.name API [62] or send postMessages
to it [55, 63]. In this section, we conduct the largest-to-date study to detect
To do this, STORK inserts test payloads in the injection open redirect vulnerabilities in the wild, with the overarching
point. In particular, STORK uses a pre-defined list of payloads goal to identify and extract indicator patterns from real vul-
that we manually compiled, covering a comprehensive array nerabilities. The rest of this section details statistics about the
of attack techniques. We systematically reviewed academic dataset and the analysis steps.
literature [2, 64–67], HackerOne vulnerability reports [68], IV-B1 Data Collection and Processing. In this paper, we
the CVE database [4, 69], Stack Exchange [70] and Dev [71] reused the snapshots of webpages provided by prior work [16],
security communities, and other non-academic resources (see, which is based on the Tranco site list downloaded on Sept.
i.e., [7, 15, 28–31, 33, 72–77]), looking for open redirect 29, 2022 (ID: N7QWW) [78], and collected in Oct. 2022
attack payloads and general URL filter bypass techniques. We during a six week period. The dataset contains a total of
consider in scope those techniques that can be exploited by a 1,034,521∼1M webpages across top 10K sites. These 1M
5
pages contained around 46.1M scripts with over 129.8B LoC. This can augment our dataset with information about server-
Page de-duplication enabled us to focus on pages with unique side open redirects. In total, we identified 687 CVEs for open
sets of scripts and reduced the size of the dataset by about redirect vulnerabilities, of which in only 460 cases, we were
17%, that is, out of the total 1M webpages, 867,455 pages able to retrieve the affected endpoint, either directly from the
were unique. We divided this dataset in two portions, one report or by following the links provided.
for extracting patterns of vulnerabilities, and the other one To extract vulnerability indicators, we grouped the URLs
for searching the presence of the vulnerable patterns, which together based on their similarity by abstracting away the
we call P1 and P2 , respectively. The first portion P1 contains specific domain affected, and considering the syntax, injection
a maximum of 50 pages per site that have the highest fre- point and the position (e.g., path or query parameter), and the
quency of dynamic data flows [44], resulting in a dataset of values of the redirection parameters, decomposing URLs to
339,267 webpages with 32.4B LoC, which is similarly to prior their building block components.
work [16]. The second portion P2 contains 528,188 pages with Starting from the 20,471 confirmed URL-based open redi-
71.7B LoC. Table I summarizes the dataset statistics. rections we discovered, and the 460 past CVEs of open
IV-B2 Program Analysis. Given as input the P1 dataset, redirections, we extracted a total of 184 concrete vulnerability
STORK performs static analysis for vulnerability discovery. patterns, of which 95 are new (i.e., discovered exclusively
We processed an average of 34 scripts and 95K LoC per page, using our dataset). We grouped these 184 concrete patterns
generating 339K HPGs. Afterwards, STORK performed graph into nine distinct categories by abstracting away the specific
traversals to detect data flows from JavaScript program inputs redirection parameter in the URL (e.g., “next” vs. “redirect”).
to redirection instructions. In summary, STORK identified an Our results show that out of these nine indicator patterns, three
average of five redirection sinks and 65 sources per webpage, are new (as we found no existing CVEs revealing similar
totaling about 22.3M sources and 1.7M sinks. Among these, structural pattern), two include new variants (as the general
static analysis found a total of 25,990 potential data flows structure is the same, but the specific redirection parameter in
from sources to sinks, of which about 80% (i.e., 20,898) have the URL is different), and the remaining four are similarly to
been confirmed via dynamic testing. In summary, these vul- the known cases (i.e., both the general structure and redirection
nerabilities affected 11,155 webpages across 623 websites, of parameters match to known cases). We further grouped these
which 20,471 flows across 599 sites originate from URL-based nine patterns into three different classes based on the position
sources (e.g., query parameters), whereas 427 flows across 39 of the redirection parameter in the URL (i.e., query parameter,
sites are from non-URL sources (e.g., postMessages). Table II path or fragment). Table III summarizes the results.
summarizes the results. IV-B5 Analysis of Indicators. Unsurprisingly, we observed
IV-B3 Analysis of Vulnerabilities. We found that a small that a significant fraction of the vulnerabilities occur when
fraction of vulnerable redirections (i.e., 427 or about 2% using query parameters for redirections. Particularly, open
of cases) originate from sources other than webpages’ URL redirects via pattern A1 are the most widespread, being present
parameters, which cannot be detected by traditional detection on more than 14,201 vulnerabilities across 402 sites and 382
approaches based on URL parameter fuzzing (e.g., [2, 3]). existing CVEs. In comparison, vulnerabilities relying on the
In comparison, STORK’s SAST component can detect them, URL path segments for redirections demonstrated a moderate
and STORK’s DAST component can verify them. In con- level of presence, with the most popular being pattern B1
trast, about 98% of open redirections originate from URL representing 948 vulnerabilities across 147 sites and 35 CVEs.
sources. As we will show next in §IV-B4, these vulnerabilities We observed that a significant fraction of the open redirect
can be largely detected by pattern-based searching provided vulnerabilities affecting client-side code (i.e., 12.4%) rely on
that a comprehensive list of indicative patterns is available. hash fragments. The widespread usage of URL parameters for
For example, Table IX (appendix) presents the top 10 URL redirections, coupled with a wide variety of potential vulner-
query parameter keys featuring the highest number of distinct abilities, presents a tantalizing attack surface for hackers. The
domains utilizing the parameter for (open) redirections. We remainder of this paper is dedicated to using these indicators
observed that the most prevalent parameter in open redirects for mining vulnerabilities from snapshots of webpages.
is url which is used by 102 domains across 1,224 unique IV-B6 Coverage of Indicators. We found that the CDF
URLs, followed by domain and redir keys across 52 and tracking the growth of indicator patterns across randomly-
39 domains, respectively. Consequently, these indicators can ordered vulnerable webpages in P1 dataset reaches saturation
be leveraged to search for potential open redirects, reducing at about 66%, suggesting that our patterns are comprehensive
the overall effort for program analysis. (see Figure 3 of Appendix A). Furthermore, as we will show in
IV-B4 Pattern Extraction and Indicators. After identifying §V-C, our baseline experiments did not reveal false negatives
open redirects, we group them together to extract common due to missing patterns, further reassuring comprehensiveness.
patterns. In addition to the vulnerabilities we discovered in However, we do not claim nor guarantee that our patterns are
this section, we manually analyze existing vulnerability reports exhaustive, as they are influenced by crawling coverage (e.g.,
from the MITRE CVE database [4, 69], which we collected deep and authenticated states) and limitations of static analysis
in §IV-A3, and extract the affected URLs from each report. (e.g., handling dynamic JavaScript features).
6
Sink / Source loc.href loc.hash loc.search doc.uri Flows Verified win.name doc.ref pMsg Flows Verified Total Verified Pages Sites
win.open() 17,321 2,078 1,120 55 20,574 16,480 21 76 3 100 86 20,674 16,566 8,846 455
win.loc 862 53 42 10 967 743 12 16 1 29 10 996 753 543 168
frame.src 41 261 7 0 308 202 16 8 35 59 51 367 253 202 29
loc.href 2,654 178 186 1 3,019 2,597 34 89 0 123 78 3,142 2,675 1,627 302
loc.replace() 381 12 8 0 401 358 3 0 7 10 2 411 360 281 62
loc.assign() 70 5 72 0 147 91 251 3 0 254 200 401 291 184 13
Total 21,329 2,587 1,434 66 25,415 20,471 337 192 46 575 427 25,990 20,898 11,155 623
TABLE II: Summary of the vulnerable data flows found by STORK. Columns represent different client-side sources. The left part shows flows originating
from URL parameters, while the middle part shows flows originating from other sources like window name and postMessages (i.e., pMsg column).
V. V ULNERABILITY M INING about 5 USD per 1000 queries [79]. Accordingly, we opted to
submit only one request per Dork query and site, enabling us
In this section, we leverage the vulnerability indicators we
to utilize the free tier and minimize additional costs, totaling
discovered in §IV to mine potential vulnerabilities from public
no more than 50 USD for 10K sites.
data archive repositories in a cost-effective way, as shown in
step 2 of Figure 2. Our primary focus is on data platforms V-A2 Overview of Query Results. Table IV shows the
such as Google Search and Internet Archive. Additionally, we number of candidate URLs found for open redirects within the
demonstrate the versatility of our technique by applying it on top 10K sites across the three considered data sources. In total,
live websites (i.e., the second portion of the dataset), quantify- our queries identified about 4M candidate URLs, the majority
ing the prevalence of open redirect vulnerabilities in the wild. of which belonged to Internet Archive. URL de-duplication in
Finally, we study the cost-benefit trade-offs of indicator-based each data source enabled us to reduce the number of candidate
and static analysis-based vulnerability detection, showing that URLs substantially to as few as 215K cases (see Appendix D).
indicator-based scanning is up to 100x faster, and can detect However, we observed that a small fraction (i.e., 0.5%) of the
vulnerabilities static analysis misses, but may also introduce unique URLs from different data sources are also duplicates
more false negatives. Our results emphasize the effectiveness of one another, further reducing results to 214K unique cases.
of indicator-based vulnerability scanning as a lightweight Table XI (Appendix A) presents the distribution of these URLs
method for detecting open redirects at scale, including both across different vulnerability patterns.
client-side and server-side variants.
B. Vulnerability Verification
A. Indicator Mining After identifying candidate URLs for open redirects, we
Having compiled an extensive catalog of vulnerability in- perform run-time tests to eliminate false positives, as shown in
dicator patterns, we now employ these patterns to identify step 2 of Figure 2. We follow a similar approach presented
potential candidates of zero-day open redirect vulnerabilities. in §IV-A3. Specifically, for each URL, we test one payload for
We searched the Internet Archive and Google page snapshots each of the 26 attack techniques in Table X, i.e., we put the
for our indicator patterns for pages archived within the past payload in the injection point according to the vulnerability
two months (June 2023 - July 2023), and use the resulting patterns of Table III, and subsequently examine whether it
URLs as candidates for security testing. We used archives causes the page to redirect to our web server. As soon as a
to collect a large pool of URLs (not webpages), on which payload goes through in one of the tests, we mark the endpoint
we searched our indicators, and conducted our experiments as vulnerable. If all of the test cases fail, we exclude the
exclusively on live webpages of archive URLs. candidate URL from the output.
V-A1 Data Collection and Mining. For each vulnerability in- V-B1 Overview of Vulnerabilities. In total, our vulnerability
dicator pattern, we created a corresponding regular expression mining approach combined with dynamic testing uncovered
and a Google dork query [21, 22]. First, for each of the top 375 new open redirect vulnerabilities across 326 websites, of
10K websites, we applied the regular expressions to search which the majority (i.e., 70% or 265) were discovered using
for matching patterns on Internet Archive and (snapshots of) Internet Archive URLs. Upon examining vulnerabilities iden-
live websites (i.e., P2 in Table I). For Internet Archive, we tified through simultaneous analysis of multiple data sources,
relied on the CDX server API [23] for our search. Second, we found six instances where a vulnerable URL occurred in
for each website, we use the Google Custom Search JSON both the Internet Archive and our live website crawl. We refer
API [20] to look for the dorks that we created. The custom interested readers to Table XI of Appendix A.
search API, limited to returning a maximum of 10 results per V-B2 Analysis of Type of Redirects. Manual analysis of the
query request, guided our study with the understanding that 375 vulnerabilities indicated that 204 cases involved client-
an attacker would aim for cost-effectiveness when exploiting side redirects, of which the overwhelming majority (i.e., 202)
this method, aligning with our threat model of §II. At the were JavaScript-based, and the remaining two employed meta
time of writing this paper, Google’s Custom Search JSON tags for redirection. In contrast, we observed that 171 vulner-
API provides 100 search queries per day for free, and charges abilities occurred due to server-side redirections. This finding
7
Type ID Pattern Params Count New Example CVEs Vulns Sites
Query ¶ A1 ?P=CONST R1 109 59 ?next=example.com 382 14,201 402
A2 ?CONST=https%3A%2F%2F | www. | DOMAIN.PSL - 3 0 ?xyz=https%3A%2F%2Fexample.com 12 2,360 91
Path ¶ B1 /P/https%3A | DOMAIN.PSL R2 17 1 /callbackUri/www.example.com%2Findex 35 948 147
B2 [/CONST]/https%3A/P R3 13 0 /https%3A%2F%2Fexample.com/submitUrl 23 260 24
B3 /CONST/https%3A | DOMAIN.PSL - 2 0 /index.php/example.com%2Findex 2 122 7
B4 /https%3A/CONST/ - 1 0 /https%3A%2F%2Fexamle.com%2Findex/get 6 31 3
Hash ¶ C1 #P=CONST R4 35 35 #ajaxUI=example.com/profile/index 0 2,207 108
¶ C2 #CONST=https:// | DOMAIN.PSL - 2 2 #u=https://example.com 0 311 26
¶ C3 #https:// | DOMAIN.PSL - 2 2 #example.com/profile/index 0 31 2
Total 184 95 460 20,471 599
TABLE III: Open redirect indicator patterns for vulnerability mining, grouped by the URL segment responsible for the redirection. The table shows the
number of vulnerabilities matching each pattern. Rows marked with ¶ represent new patterns, whereas ¶ marks variants where a known pattern is observed
with a new parameter as in Table VIII. Legend: P= values in “params” column; Ri = row i in Table VIII; CONST= constant string 6= P; []= optional part;
|= OR operator.
Source URLs Unique whether the redirection happens and is open to arbitrary
S1: Internet Archive 4,001,896 188,403 destinations. The results confirmed that there are no false
S2: Google Cache 2,313 1,237
S3: Live Crawl 29,294 26,163
positives. This finding was expected, as contrary to static
analysis, dynamic analysis techniques (e.g., [2, 3, 57, 58])
Total 4,033,503 214,645
typically produce little-to-no false positives.
TABLE IV: Candidate URLs found for open redirects in top 10K sites.
C. Cost-Benefit Analysis
The main contribution of indicators is enabling larger-
is not surprising, because the study of open redirect CVEs scale analyses compared to costly static analyses. However,
in §IV-B4 showed that our automatically-generated catalog of indicator-based, dynamic vulnerability scanning may also
client-side indicators are a superset of the server-side variants. result in false negatives. In this section, we evaluate and
In line with this finding, experimental results demonstrate that compare the cost-benefit trade-offs between using indicator-
our indicators can capture both client-side and server-side open based vulnerability mining and static analysis methods for
redirect variants. identifying open redirects. Our methodology is as follows.
V-B3 Precison of Vulnerability Indicators. We observed that We chose 50 applications at random from the P2 dataset in
about ∼4% of the sites that matched our indicator mining Table I, encompassing a total of 42,288 webpages (hereafter
queries (Cf. Table III) were open redirect vulnerabilities. When P20 ), and compare the analysis and verification time, storage
looking at candidate URLs, almost 2 of every 1K candidate requirements, and performance of each approach.
URLs was an open redirect, which increased to a rate of up V-C1 Performance. After analyzing 42,288 URLs, static
to 18 per 1K URLs for the Google search API. Therefore, analysis identified 58 potentially vulnerable data flows, with 46
only a small fraction of cases matching indicators represent of these dynamically confirmed as open redirects, translating
actual vulnerabilities. However, indicators reduced the search to a false positive rate of about 20%. These vulnerabilities
space significantly. For example, for live sites (P2 dataset impacted 46 pages across eight applications. In comparison,
in Table I), indicators quickly narrowed the testing scope indicator-based vulnerability scanning immediately narrowed
from 528K webpages to about 26K candidates, resulting in the scope to 3,011 candidate URLs for testing, and found
a significant optimization factor of ∼20 for dynamic testing. sixteen cases as open redirects across six applications. Notably,
In general, precision of indicator patterns themselves is five out of these sixteen vulnerabilities were exclusively found
not a major concern, because our dynamic indicator-based by indicators, not detected by static analysis due to the
vulnerability scanning approach does not produce any false absence of call and PDG edges in CPGs, and because one
positives. Specifically, following the approach described in of the five vulnerabilities was a server-side open redirect.
Sections IV-A4 and V-B, STORK verifies potential open This shows an important advantage of indicators—they can
redirect vulnerabilities by conducting runtime tests using the uncover security flaws that client-side static analysis might
payloads enumerated in Table X. STORK uses a Playwright- miss. When looking at individual vulnerabilities, indicators
controlled browser [43] to visit a target URL containing a also showed high false negatives compared to static analysis
test payload, and flags it as an open redirect vulnerability (i.e., 76%). We found that these FNs arise because indicators
only when it detects that the target webpage redirected to an operate at URL level and their optional parameters (e.g., query
arbitrary, controlled page at runtime. To demonstrate that this and hash) are missing from the URLs collected by the crawler
approach is robust to false positives, we manually analyzed all or archives, which can trigger different code execution paths.
the 375 vulnerabilities identified in §V-B1. In particular, we However, static analysis can capture code paths that use these
manually loaded the URL containing the found attack payload parameters, finding the vulnerabilities. However, this should
via the automated approach in the browser, and checked not overshadow the broader perspective in terms of trade-
8
offs. First, when looking at vulnerable applications, half of SAST Mining Total
Threat Vuln. Sites Vuln. Sites Vuln. Sites
the applications found vulnerable via static analysis were also
DOM-based XSS 1,845 212 84 78 1,929 290
detected through indicators. Second, indicators excel in testing
a wider range of applications potentially at risk, which static Client-side CSRF 36 33 6 6 42 39
Information Leak 2 2 1 1 3 3
analysis alone might overlook. Consequently, indicators can
play a crucial role in complementing static analysis, helping Total 1,883 247 91 85 1,974 332
to cast a wider net and pinpointing applications that warrant TABLE V: Summary of exploitations created for open redirect vulnerabilities.
a more in-depth examination. SAST and mining refer to steps 1 and 2 of Figure 2, respectively.
V-C2 Analysis Time. The main benefit of vulnerability mining
over static analysis is highlighted by the significant differences
specifically those capable of leading to DOM-based XSS. For
in runtime costs. Specifically, running the JAW static analysis
each vulnerability, we loaded the webpage in Playwright [43],
pipeline to construct a CPG and execute analysis queries took
inserted the attack payload at the injection point, and verified
an average of 34m 52s for one webpage, and about 1,024 days
whether the payload executed as intended. We note that we
for the whole P20 (we used 100 parallel executions to do this
used a benign attack payload based on the ‘‘debugger;"
in 10 days). Accordingly, running static analysis for the entire
JavaScript instruction, which serves as a breakpoint pausing
P2 would require an estimated 12,789 days with sequential
the execution of client-side code.
execution (or ∼127 days by 100 parallel instances). In stark
contrast, mining all indicator patterns on entire P20 and P2 VI-A2 Request Forgery and Information Leakage. To ex-
were accomplished in about 29m and 58m, respectively 2 . amine potential escalations to request forgery and information
leakage attacks, we employed a manual approach. Due to the
V-C3 Verification Time. The verifier performs between one
large number of confirmed vulnerabilities—21K open redirects
and 26 tests per URL and needs 10 seconds per test. On
across 872 websites—it was infeasible to manually create
P20 , verifying static analysis results took about 1.5h, whereas
xploits for each one. Instead, we focused on demonstrating
indicators needed 217h (or ∼2h with 100 parallel executions).
the potential for escalation by examining a random subset,
V-C4 Storage Requirements. In terms of storage needs, static where we aimed to maximize the coverage across various sites.
analysis demonstrated a considerably higher demand as well. Therefore, we randomly selected up to two vulnerabilities from
The average size of a CPG and its corresponding query results each of the 872 affected websites, giving us a total of 1,744
was 29.5 MB, cumulatively amounting to 1.1 TB for the P20 vulnerabilities to analyze.
dataset. Extrapolating these figures, processing the P2 dataset For each attack scenario, we conducted specific tests. For
is estimated to require about 14.8 TB of disk space. On the example, we looked for server-side endpoints that could lead to
other hand, the vulnerability mining method required only 25 security-sensitive state changes (e.g., modifying user settings)
GB of space for the entire P2 . for client-side CSRF. For information leakage, we examined
These comparisons highlight the substantial advantages of the redirect request for the presence of sensitive data like
vulnerability mining in terms of both speed and resource authorization keys, and OAuth tokens. Due to ethical consider-
utilization, making it a suitable trade-off for larger-scale ations, we excluded testing requests and functionalities where
security assessments, which can provide a lowerbound on the we could not control the impact (e.g., publicly accessible
number of affected sites. content), and use our own test accounts exclusively.
VI. E XPLOIT A NALYSIS AND E SCALATION We note that identifying request forgery and information
leakage exploits automatically poses a non-trivial challenge,
Starting from the vulnerabilities we discovered in Sec- demanding a deep understanding of each specific application
tions IV and V, we now examine their susceptibility to to pinpoint target endpoints for request forgery considering
more critical exploitation scenarios including XSS, informa- the request semantics, or the presense of sensitive infor-
tion leakage, and request forgery attacks, as described in our mation. Moreover, it involves assessing whether the client-
threat model of §II-B. Particularly, we discovered a total of side requests induce server-side state changes. Finally, in
20,898 open redirections across 623 sites in §IV through static- an automated setting, guaranteeing ethical compliance and
dynamic program analysis, and 375 vulnerabilities within 326 preventing unintended server-side interactions or state changes
sites in §V through vulnerability mining, summing to 21,273 is challenging. For these reasons, we opted for a systematic
vulnerabilities across 872 unique websites. manual approach where we can strictly control our tests.
A. Methodology B. Results
VI-A1 Cross-Site Scripting. To assess the potential for DOM- We now provide an overview of the exploitation results for
based XSS exploitations, we employed an automatic approach, the vulnerabilities, following the methodology in §VI-A.
where we tested the susceptibility of each vulnerable endpoint VI-B1 Cross-Site Scripting. In total, we automatically tested
against a subset of the attack techniques outlined in Table X, DOM-based XSS escalations for 21,273 open redirects across
2 Runtimes are based on the following configuration: Ubuntu 18.04, AMD 872 as shown in Sections IV and V. Our analysis revealed that
EPYC 7H12 processor with 256 CPU cores and 2 TB RAM. about 9% of the vulnerabilities across 33.2% of the affected
9
Listing 2: Open redirect vulnerability in adobe.com escalated to DOM XSS. Listing 3: CSRF escalation of an open redirect vulnerability in webnovel.com.
1 class i { 1 /* extract a query parameter value from URL */
2 constructor(n, /* [...] */){ 2 function u(e) {
3 this._injector = n; 3 r = new RegExp("(ˆ|&)" + e + "=([ˆ&]*)(&|$)",
4 /* [...] */} "i"),
5 navigate(n){ 4 t = new RegExp("[A-Za-z]"),
6 const w = this._injector.get("w"), 5 n = window.location.search.substr(1).match(r);
7 x = n.queryParamMap.get("externalUrl"), 6 if (null != n) {
8 k = n.queryParamMap.get("windowTarget"), 7 var o = n[2];
// _self 8 return t.test(o) ? n[2] : parseInt(n[2]);}
9 d = n.queryParamMap.get("rel"); 9 return null; }
10 if(x.indexOf('adobe.com') != -1) 10 /* check destination URL */
11 w.open(x, k, d);}} 11 function isValidUrl(e) {
12 n = {}; 12 a = !!/ˆ\/[ˆ/]*/.test(e); //
13 s = location.search; protocol-relative URIs
14 n.queryParamMap = new URLSearchParams(s); 13 b = !!e.match(/ˆhttps?:\/\/[ˆ.]*?\.webnovel\.
15 n.w = window; com($|\/.*|\?|#)/);
16 x = new i(n); 14 return a || b;}
17 x.navigate(n); 15 /* redirection */
16 var c = {
17 code: u("code"),
18 ticket: u("ticket"),
sites could be escalated to DOM-based XSS attacks, which is 19 guid: u("userid"),
20 forceRedirect: u("forceRedirect"),
alarming. When comparing static analysis-based and indicator- 21 redir: decodeURIComponent(u("redirectUrl") ||
based approaches, static analysis identified approximately two "")}
orders of magnitude more vulnerabilities across nearly double 22 r = c.redir;
23 r && isValidUrl(r)? location.assign(r):
the number of sites. However, only around 8% of these 24 location.href = "/";
vulnerabilities could be exploited for XSS. In contrast, more
than 22% of the vulnerabilities identified through the indicator-
based approach could be exploited for XSS, indicating a higher
prevalence of XSS escalations among indicator-based findings. WebNovel. Listing 3 illustrates a simplified open redirect
VI-B2 Request Forgery and Information Leakage. In to- vulnerability in webnovel.com that we escalated to client-side
tal, we discovered 42 client-side CSRF and three cross-site CSRF. The open redirection takes place in line 23 using the
information leakage vulnerabilities, suggesting that over 2.4% location.assign() API whose parameter r is retrieved
and only about 0.2% of the open redirects can be escalated to from the redirectUrl query parameter in line 21 using the
request forgery and information leaks. Despite their relatively function u defined in line 2. The code validates the variable
lower incidence compared to XSS, these exploitations could r in line 23 using the isValidUrl function, checking if
still led to critical consequences like account takeover and the destination satisfies one of the two properties: (i) it starts
unauthorized changes to account settings, compromising the with //, or (ii) it belongs to the webnovel.com domain.
integrity of the applications’ databases. Table V provides a Condition (i) allows open redirection abusing protocol-relative
summary of our findings. URIs, e.g., //attack.com, whereas, XSS exploitation is not
possible as javascript URIs are not allowed. However,
further investigation revealed that WebNovel employs state-
C. Case Studies
changing GET requests to save modifications to user account
We present a few manually vetted case studies of the settings. This discovery enabled us to forge the redirection
confirmed attacks (disclosed and patched), with additional case request, establishing a client-side CSRF attack vector that
studies in Appendix B, empowers attackers to manipulate user account settings. We
Adobe. Listing 2 shows a DOM XSS exploitation of a note that the advantage of a client-side open redirect is that it
client-side open redirect vulnerability in adobe.com. The triggers a top-level, same-site request, resulting in client-side
vulnerability originates in line 11, where the code employs CSRF [18, 26], compared to cross-site requests in traditional
the window.open() API to redirect the current window CSRF attacks. State-changing GET requests triggered via
to a destination controlled by the attacker, which is read cross-site resources are prevented by SameSite cookies [39].
from the top-level URL query parameters, specifically the However, GET requests triggered via client-side open redirects
externalUrl key. The code attempts input validation in can bypass SameSite cookie protections.
line 10 by checking if the destination string contains the VK. We identified an open redirect vulnerability in vk.com,
string ‘adobe.com’ using the indexOf() function. However, which can be escalated to DOM-based XSS. The vul-
this check is insufficient: (i) an attacker can achieve open nerable URL includes a query key to, specifying the
redirection to a domain like adobe.com.attack.com, destination for the final redirect (e.g., attack.com).
bypassing the indexOf() check, and (ii), there is no check Upon receiving such a request, the application sets a
against the javascript: scheme, enabling attackers to cookie, remixsec_redir=attack.com, through the
escalate it to a DOM XSS. Set-Cookie HTTP response header. Subsequently, the
10
Tool Ref. Method Vuln. Conf. FP FN Ó Mitigation Domains Pct.
Joern: v1.1.1277 [80, 82] Static 11 2 9 1 #1: Redirect Notice 2,178 54.4%
JAW: v1 [18] Static 5 3 2 0 #2: Input Validation 1,051 26.2%
JAW: v2 (TheThing) [19] Hybrid 5 3 2 0 #3: Content Security Policy 416 10.4%
JAW: v3 (Sheriff) [16] Hybrid 4 3 1 0 #4: Security Tokens 112 2.8%
BlackWidow: v1.3 [81] Dynamic 1 1 0 2 #5: Captcha / reCaptcha 43 1.0%
Foxhound: v98.0.2 [44, 45] Dynamic 72 2 70 1 #6: Link Shimming 14 0.3%
STORK Hybrid 3 3 0 0 No Redirect 186 4.6%
TABLE VI: Comparison of indicator-based vulnerability scanning with TABLE VII: Mitigation techniques employed by websites.
XSS detectors. Legend: Vuln= potential vulnerabilities; Conf.= manually
confirmed; FP= false positive; FN= false negative.
the mitigation strategy, we randomly selected 4K of the 7.7K
client-side code reads the value of the remixsec_redir sites, and investigated one random candidate URL per site
cookie and additionally checks if the URL contains another semi-automatically.
query parameter, away, with a non-empty token value. If this The examination of the 4K sites revealed six different
condition is met, it redirects the current page to the value of mitigation techniques, outlined in Table VII. We found that
remixsec_redir (i.e., attack.com or a javascript 57% of the cases (i.e., 2,292 sites) used client-side redirects,
URI). This way, an attacker can also implant a persistent DOM whereas 38% of sites employed server-side redirection, and in
XSS attack vector, and exploit it only later on to attack a victim the remaining 5%, we did not observe any redirection. In the
(i.e., when the away parameter is present). following, we discuss each mitigation technique.
Redirect Notice. We observed that more than half of the non-
D. Comparison with XSS Detectors vulnerable sites display a redirection warning to the user. In
We compared DOM XSS detection between indicator-based the majority of these cases (i.e., 84.5%), intermediate human
vulnerability scanning described in §VI-A and XSS detection interaction is necessary before the redirection occurs, such as
methods on the P20 dataset in §V-C (42K webpages of 50 a button click or entering an input. However, in the remaining
random applications). We considered the following state-of- 15.5% of cases, the redirection happens automatically after
the-art detectors as baselines: dynamic taint-tracking [24, 36, a certain period (e.g., 120 seconds), and the user can only
45] using Foxhound [44, 45], JAW engine versions one to expedite the redirection by, for example, clicking on a button.
three [16, 18, 19], Joern [80], and BlackWidow [81]. While the risk is negligible, it’s worth noting that these cases
Table VI summarizes the results. Overall, the indicator- could lead to open redirection after a certain amount of
based approach and static analysis based on JAW found time automatically if the user leaves the webpage open. To
three DOM XSS vulnerabilities. In contrast, other approaches determine if a webpage had a redirect notice, we loaded the
discovered less true positive vulnerabilities. Specifically, Fox- page via Playwright using an automated script, and then vet
hound identified 72 potentially sensitive data flows, but only manually whether we can see a notice, after which our script
two were confirmed as XSS after manual analysis. The high opens up the next site.
FP rate stems from the fact that Foxhound only detects the Captcha. In addition to redirect notices, we observed another
presense of data flows that may lead to XSS but does not verify form of intermediate interaction utilized by websites before
whether these flows are actually attacker-controlled. Foxhound redirecting users to specified targets: captchas. We found that
missed one XSS data flow, as it could not trigger the vulnerable about 1% of the sites display a captcha page before redirection,
execution path (branches). BlackWidow identified only one including popular sites like Amazon. To identify these cases,
true positive vulnerability because its test payloads failed to we followed a similar methodology as that of redirect notices.
detect other vulnerable injection points. Finally, Joern did not Input Validation. These checks involve examining user-
find one XSS vulnerability due to a missing call graph edge provided data to ensure it adheres to expected formats or
for the Function.call() instruction. constraints before using it as a part of the redirect destina-
tion [45, 83]. To detect the presence of these checks, we tested
VII. D EFENSES IN THE W ILD
the redirection automatically by setting a URL belonging to
We identify and study the various mitigation techniques the domain of the site under test. If the redirection happens
deployed in the wild to address open redirect vulnerabilities. automatically, we confirm the presence of a input validation
We intend to have a look at the subset of candidate redirection routine, as it did not work for an external domain in our
URLs found via indicator pattern mining that were not vul- previous analysis. Also, we manually looked at the client-
nerabilities (e.g., closed redirections) and investigate potential side code for about 10% of these pages to identify the
mitigations employed by websites. variety of checks happening in client-side. Overall, our anal-
Starting from the results in Table XI, there are 7,719 ysis revealed that more than a quarter of the non-vulnerable
websites where we identified a candidate URL matching our websites (i.e., 1,051) implemented input validation, including
indicators, but we did not observe an open redirect during various validation checks in client-side JavaScript program
automatic run-time experiments (refer to §V-B). To identify inputs, such as hard-coded equality conditionals, whitelists,
11
length validations, checks for data types and formats, use of research efforts, our study reveals that unvalidated redirects
regular expressions for pattern matching, input sanitization persist as a prevalent security concern in the wild, even after
routines to filter out potentially malicious JavaScript content, nearly a decade. Our work goes beyond mere prevalence
URL substring searches, and other string manipulation and measurement by extracting vulnerable patterns and showcasing
comparison operations. how attackers can escalate these vulnerabilities. In addition,
Content Security Policy (CSP). CSP [27] can mitigate the we demonstrate how adversaries can actively search for these
impact of client-side open redirects when attackers can control vulnerabilities in public data repositories.
the value of JavaScript instructions that trigger page naviga- Indicator-based Vulnerability Discovery. Scanning programs
tion, such as location.assign() API [84]. For example, for indicators to identify potential vulnerabilities has been
CSP can be configured to restrict the domains to which a considered by several researchers in the past (e.g., [89–92]).
page can be redirected, particularly using the navigate-to Broadly, we can divide these techniques into two classes:
directive [85], thereby mitigating the risk of redirections to metric-based and pattern-based techniques. Metrics-based ap-
external domains. We collected the CSP policies automatically proaches use machine learning models to predict vulnerable
and confirmed that over 10% of the non-vulnerable sites adopt code locations in the source code, using features like static and
a CSP policy blocking the redirection. execution code complexity [93, 94], token frequency [95, 96],
Link shimming. Link shimming [86] refers to a technique dependency relationships [97], and developer activity met-
where an application transforms its URLs in a way that rics [98–100]. These approaches are typically heavy and apply-
allows it to intercept and analyze the traffic before redirect- ing them to the context of web applications requires training
ing the user to the intended destination. When a request is datasets. Instead, we focused on lightweight approaches next
intercepted, the service cross-checks the URL against internal to costly static analysis to enable larger-scale analyses. Con-
lists of malicious domains and external partners’ lists. Then, versely, pattern-based techniques rely on syntax and semantics
the service redirects the user to an intermediate page to of vulnerable programs to extract a pattern, which is used to
confirm the redirection, similarly to a redirect notice, and if identify potentially vulnerable code, typically through static
the request seems suspicious, warns the user about it. We analysis [19, 46, 101, 102]. However, existing pattern-based
identified 14 websites in our dataset (i.e., 0.3%) with this solutions for open redirects [2, 3] propose hand-crafted lists of
behaviour, the majority of which are social media platforms. indicators. In contrast, we automatically extract patterns using
For example, link shim traffic for Facebook is transferred to a novel, static-dynamic methodology.
l.facebook.com. Program Analysis for Security Testing. The field of pro-
Security Tokens. We discovered that a small portion of the gram analysis for security testing has witnessed significant
sites (2.8%) employed tokens to allow or block redirections to attention in the last decade. Researchers proposed various
external domains. These are cryptographic tokens, nonces that techniques to examine the security posture of software appli-
expire after a single use, or time-synchronized tokens that re- cations, including static analysis [46, 103, 104], dynamic anal-
main valid for a specific period, allowing multiple uses within ysis [24, 36, 37, 45, 55, 63, 105], and hybrid approaches [18,
that timeframe before expiration. While the risk is marginal, 19, 106, 107]. For example, Lekies et al. [24] modified the
the latter cases could still be abused for open redirections JavaScript engine in Chromium to enhance it with taint-
within their small validity window, affecting popular sites like tracking capabilities, focusing on the detection of DOM-based
AliExpress and Samsung. XSS. Melicher et. al. [25] adopted a similar methodology,
but employed a new strategy to verify if a data flow could
VIII. R ELATED W ORK indicate a DOM XSS vulnerability. Similarly, Steffens et al.
investigated the prevalence of persistent [37] and postMessage-
Open Redirect Vulnerabilities. Unvalidated redirects have
based XSS [55] through dynamic taint tracking and forceful
been the focus of several research efforts in the past. Shue
execution, respectively. Klein et al. [45] adopted a combined
et. al. [2] presented the first set of manually-curated heuristics
approach involving dynamic taint tracking and symbolic string
to identify potential open redirect vulnerabilities and used
analysis, focusing on the robustness of custom sanitization
dynamic analysis to test them. The authors demonstrated that
functions deployed on the Web. Khodayari and Pellegrino
open redirects were ubiquitous in the wild back in 2008.
proposed a hybrid system, JAW [18], to study client-side CSRF
Almost seven years later, Wang et. al. [3] quantified the
vulnerabilities in JavaScript programs. Saxena et al. introduced
prevalence of unvalidated redirects leveraging a custom black-
Kudzu [106], a tool that combines taint tracking and symbolic
box scanner and showed that many websites are still affected
execution to detect source-sink data flows in the client-side
by this security flaw. Since then, open redirect vulnerabilities
of web applications. Other works studied code-less injection
have been attracting the attention of the security community,
attacks using both static and dynamic approaches, such as
with researchers exploring the attack surface [72, 75, 87],
script gadgets [36], DOM Clobbering [19], and mutation-based
testing strategies [56, 59, 73], and mitigation techniques [28–
XSS [108]. Our work uses and extends these techniques by
31, 74]. More recently, multiple works [17, 88] studied secu-
applying them to the problem of open redirections on the Web.
rity flaws affecting OAuth 2.0 implementations concerning the
validation of the redirect URI parameter. In parallel with prior
12
IX. C ONCLUSION AND D ISCUSSION Our findings indicate that ∼25% of the websites with closed
redirects validate the destination of redirections, addressing,
In this section, we summarize our findings and discuss their
among others, the risk of DOM XSS. Furthermore, an addi-
wider implications.
tional 10% implement a CSP policy that can act as a defense-
in-depth and mitigate the impact of a potential DOM XSS
A. Re-evaluating the Risk and Lessons Learned
exploitation, which is promising. However, we also observed
This section re-evaluates the risk posed by open redirects that ∼13.2% of the sites that found to be vulnerable to open
by contextualizing our findings alongside previous research. redirect via static analysis and that can also be escalated
However, we note that a direct comparison with prior work to XSS (i.e., 28 out of 212), have indeed adopted a CSP
is challenging because of potentially different methodologies, policy in another webpage but not the vulnerable one, which
tools, and snapshots of the Web. could have mitigated XSS exploitation, further highlighting the
Prevalence. Our study reveals that open redirect vulnerabili- importance of consistent adoption of security policies across
ties are widespread, impacting approximately 8.7% of the top webpages [39, 109, 110]).
10K websites, totaling over 21.2K instances. In comparison, Finally, we observed that the efficacy of defenses is largely
recent research [16] discovered that client-side CSRF vulner- influenced by the use cases of redirections in web appli-
abilities affect about 9% of the websites, with over 72.3K cations. Validating destinations for redirection services such
instances, whereas code-less injection attacks, particularly, as link shorteners [111], advertisement services [112] or
DOM Clobbering [19] and script gadgets [36] are present on social networks, which serve diverse purposes, presents greater
9.8% (9.4K instances) and 19.8% (285.8K instances) of top challenges (see, e.g., [86]) compared to application-specific
5K sites, respectively. Accordingly, client-side open redirect functionalities with a restricted set of possible redirection
vulnerabilities have a high incidence rate similarly to other endpoints, such as post-login redirects or OAuth redirection
client-side web vulnerability classes. URIs [17]. For instance, while such services often need to omit
Impact and the Role of Modern Redirection APIs. Our HTTP referer headers to mitigate the risk of privacy issues
work shows that modern JS redirection APIs can lead to signif- or cross-domain information leakage [113, 114], application-
icant vulnerabilities, challenging the long-standing perception specific redirections may require the use and forwarding
of open redirects as low-impact. Specifically, we showed of the referer to implement defense-in-depth, e.g., for
that ∼38% of sites that have an open redirect vulnerability CSRF [115].
(i.e., 3.3% of the top 10K sites) can be leveraged for more C. Ethical Considerations
critical attacks. For example, JS redirection APIs trigger top- Our experiments on live websites are limited to user ac-
level requests, thereby bypassing SameSite cookie protections counts that we created exclusively for this purpose, such as
for CSRF, and support the javascript: request scheme, manual tests for state-changing operations. During our testing
thereby posing the risk of XSS. Also, our work shows that process, we followed the guidelines provided by the web-
attackers can abuse fast indicator searches to find such high- site’s vulnerability disclosure programs on Bugcrowd [116]
impact open redirects with comparatively less effort. and HackerOne [117] to maintain testing transparency and
Severity. We found that almost one out of ten open redirects uphold responsible research practices. To mitigate any poten-
can be escalated to DOM-based XSS, which corresponds to tial impact on resource servers during dynamic analysis, we
about 2.9% of the top 10K websites. In comparison, recent minimized the testing load by implementing a round-robin
research by Melicher et. al. [25] showed that ∼3.6% of the strategy, where we tested a single URL from each unique
top 10K domains are vulnerable to DOM-based XSS through domain before moving on to the next domain. Additionally,
dynamic taint tracking. We showed that the impact of open we rigorously imposed limits on our testing, conducting a
redirect extends even further, as we exploited 2.6% of the maximum of 250 requests per day and domain. We responsibly
open redirections for request forgery and information leakage disclosed all the vulnerabilities we detected to the affected
attacks, demonstrating an alarming landscape. parties following best practices [118]. We provide details about
our notification campaign in Appendix A.
B. Effective Defenses
D. Open Science
Our study reveals that a significant fraction of websites
We publicly release our catalog of vulnerability indicators
with closed redirections (∼54%) incorporate an intermediate
and the STORK framework3 .
human interaction step, such as a redirect notice, to warn
users of the redirection request. While redirect notices are E. Weighing the Testing Trade-Offs
beneficial, their efficacy is threatened by the risky and rather In this paper, we showed the trade-offs between static
common practice of time-budgeted notices, whose expiration analysis and indicator-based scanning to detect open redirects.
results in an automatic redirect (occurring in ∼15% of cases). We found that while static analysis can identify more vulnera-
Furthermore, they are not sufficient to prevent redirections to bilities and is more precise, it also requires significantly more
JavaScript-based URIs, leaving the potential for escalations to
DOM XSS attacks in the case of client-side redirects. 3 https://github.com/SoheilKhodayari/STORK
13
time and storage. In comparison, indicator-based approaches in Proceedings of the 39th Annual Computer Security Applications
are roughly 100 times faster and need 13 times less storage, Conference, 2023.
[18] S. Khodayari and G. Pellegrino, “JAW: Studying Client-side CSRF
demonstrating their benefit in scaling up. Indicators can detect with Hybrid Property Graphs and Declarative Traversals,” in USENIX
vulnerabilities missed by static analysis, and they can play a Security Symposium, 2021.
crucial complementary role. Notably, half of the applications [19] ——, “It’s (DOM) Clobbering Time: Attack Techniques, Prevalence,
and Defenses,” in IEEE S&P Symposium, 2023.
identified as vulnerable through static analysis were also [20] Google Custom Search JSON API. [Online]. Available: https:
detected by indicators, helping to pinpoint applications that //developers.google.com/custom-search/v1/overview
need more in-depth testing. Given that the cost of indicator- [21] F. Toffalini, M. Abbà, D. Carra, and D. Balzarotti, “Google dorks:
Analysis, creation, and new defenses,” in Detection of Intrusions and
based mining is significantly lower than fully-fledged static Malware, and Vulnerability Assessment (DIMVA), San Sebastián, 2016.
and dynamic analysis, and considering their concerning ex- [22] Google Dorking Cheatsheet. [Online]. Available: https://github.com/c
ploitation potential as shown in §VI, adversaries can actively hr3st5an/Google-Dorking
[23] Wayback Machine APIs. [Online]. Available: https://archive.org/help
search for these vulnerabilities in public data repositories. /wayback api.php
[24] S. Lekies, B. Stock, and M. Johns, “25 million flows later: large-scale
ACKNOWLEDGMENTS detection of DOM-based XSS,” in ACM CCS, 2013.
[25] W. Melicher, A. Das, M. Sharif, L. Bauer, and L. Jia, “Riding out
This work received funding from the European Union’s domsday: Towards detecting and preventing dom cross-site scripting,”
Horizon 2020 research and innovation programme under the in Network and Distributed System Security Symposium, 2018.
[26] (2018) Client-side CSRF. [Online]. Available: https://www.facebook.c
TESTABLE project (grant agreement 101019206). om/notes/facebook-bug-bounty/client-side-csrf/2056804174333798/
[27] M. West, “Content Security Policy Level 3,” W3C Working Draft,
R EFERENCES 2024. [Online]. Available: https://w3c.github.io/webappsec-csp/
[1] (2024) Redirection 3xx HTTP response code. [Online]. Available: [28] OWASP Unvalidated Redirects and Forwards Cheat Sheet. [Online].
https://datatracker.ietf.org/doc/html/rfc7231#section-6.4 Available: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated
[2] C. A. Shue, A. J. Kalafut, and M. Gupta, “Exploitable redirects on Redirects and Forwards Cheat Sheet.html
the web: Identification, prevalence, and defense,” in USENIX WOOT, [29] Portswigger, “Open redirections,” 2022. [Online]. Available: https:
2008. //portswigger.net/kb/issues/00500100 open-redirection-reflected
[3] J. Wang and H. Wu, “Urfds: Systematic discovery of unvalidated [30] J. Galloway. (2022) Microsoft: Preventing Open Redirection Attacks
redirects and forwards in web applications,” in IEEE CNS, 2015. (C#). [Online]. Available: https://docs.microsoft.com/en-us/aspnet/mv
[4] MITRE Open Redirect CVEs. [Online]. Available: https://cve.mitre.or c/overview/security/preventing-open-redirection-attacks
g/cgi-bin/cvekey.cgi?keyword=open+redirect [31] Google. (2009) Open redirect URLs: Is Your Site Being Abused?
[5] D. Canali, M. Cova, G. Vigna, and C. Kruegel, “Prophiler: a fast filter [Online]. Available: https://developers.google.com/search/blog/2009/0
for the large-scale detection of malicious web pages,” in Proceedings 1/open-redirect-urls-is-your-site-being
of the 20th international conference on World wide web, 2011. [32] (2022) The HTTP Location Response Header. [Online]. Available: ht
[6] T. Nelms, R. Perdisci, M. Antonakakis, and M. Ahamad, “Towards tps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location
measuring and mitigating social engineering software download at- [33] R. Auger. (2011) WASC Article on URL Redirector Abuse. [Online].
tacks,” in USENIX Security Symposium, 2016. Available: http://projects.webappsec.org/w/page/13246981/URL%20R
[7] GreatHorn. (2021) Google and Open Redirects: Preventing Your edirector%20Abuse
Users from Becoming a Victim of Attacks. [Online]. Available: [34] D. Akhawe, A. Barth, P. E. Lam, J. Mitchell, and D. Song, “Towards
https://www.greathorn.com/blog/google-and-open-redirects-preventi a formal foundation of web security,” in IEEE CSF, 2010.
ng-your-users-from-becoming-a-victim-of-attacks/ [35] A. Barth, C. Jackson, and J. C. Mitchell, “Robust defenses for cross-site
[8] A. Oest, P. Zhang, B. Wardman, E. Nunes, J. Burgis, A. Zand, request forgery,” in CCS, 2008, pp. 75–88.
K. Thomas, A. Doupé, and G.-J. Ahn, “Sunrise to sunset: Analyzing [36] S. Lekies, K. Kotowicz, S. Groß, E. A. Vela Nava, and M. Johns,
the end-to-end life cycle and effectiveness of phishing attacks at scale,” “Code-reuse attacks for the web: Breaking cross-site scripting mitiga-
in USENIX Security Symposium, 2020. tions via script gadgets,” in CCS, 2017.
[9] C. Whittaker, B. Ryner, and M. Nazif, “Large-scale automatic classi- [37] M. Steffens, C. Rossow, M. Johns, and B. Stock, “Don’t trust the locals:
fication of phishing pages,” 2010. Investigating the prevalence of persistent client-side cross-site scripting
[10] (2024) Google and Alphabet Vulnerability Reward Program (VRP) in the wild.” in NDSS, 2019.
Rules. [Online]. Available: https://bughunters.google.com/about/ru [38] Stealing OAuth Tokens With Open Redirects. [Online]. Available:
les/6625378258649088/google-and-alphabet-vulnerability-reward- https://sec.okta.com/articles/2021/02/stealing-oauth-tokens-open-
program-vrp-rules redirects
[11] (2024) Microsoft M365 Bounty Program. [Online]. Available: [39] S. Khodayari and G. Pellegrino, “The State of the SameSite: Studying
https://www.microsoft.com/en-us/msrc/bounty-online-services the Usage, Effectiveness, and Adequacy of SameSite Cookies,” in IEEE
[12] (2022) Redirect url vulnerable to XSS and open redirect. [Online]. S&P Symposium, 2022.
Available: https://www.bugbountyhunter.com/hackevents/report?id=14 [40] S. Calzavara, M. Conti, R. Focardi, A. Rabitti, and G. Tolomei,
98 “Mitch: A machine learning approach to the black-box detection of
[13] (2021) Chaining open redirect with XSS to account takeover. [Online]. csrf vulnerabilities,” in IEEE EuroS&P Symposium, 2019.
Available: https://rdnzx.medium.com/chaining-open-redirect-with-xss- [41] E. Wang, J. Chen, W. Xie, C. Wang, Y. Gao, Z. Wang, H. Duan, Y. Liu,
to-account-takeover-36acf218a6d5 and B. Wang, “Where urls become weapons: Automated discovery
[14] (2023) OWASP DOM Clobbering prevention cheat sheet. [Online]. of ssrf vulnerabilities in web applications,” in IEEE Symposium on
Available: https://cheatsheetseries.owasp.org/cheatsheets/DOM Clobb Security and Privacy, 2024.
ering Prevention Cheat Sheet.html [42] G. Pellegrino, O. Catakoglu, D. Balzarotti, and C. Rossow, “Uses and
[15] Detectify. (2019) The real impact of an Open Redirect vulnerability. abuses of server-side requests,” in 19th International Symposium on
[Online]. Available: https://blog.detectify.com/2019/05/16/the-real- Research in Attacks, Intrusions, and Defenses (RAID), 2016.
impact-of-an-open-redirect/ [43] Playwright browser automation framework. [Online]. Available:
[16] S. Khodayari, T. Barber, and G. Pellegrino, “The great request robbery: https://playwright.dev/
An empirical study of client-side request hijacking vulnerabilities on [44] Project Foxhound. [Online]. Available: https://github.com/SAP/project-
the web,” in Proceedings of 45th IEEE Symposium on Security and foxhound
Privacy, 2024. [45] D. Klein, T. Barber, S. Bensalim, B. Stock, and M. Johns, “Hand
[17] T. Innocenti, M. Golinelli, K. Onarlioglu, A. Mirheidari, B. Crispo, Sanitizers in the Wild: A Large-scale Study of Custom JavaScript
and E. Kirda, “Oauth 2.0 redirect uri validation falls short, literally,” Sanitizer Functions,” in IEEE EuroS&P, 2022.
14
[46] F. Yamaguchi, N. Golde, D. Arp, and K. Rieck, “Modeling and [78] V. Le Pochat, T. Van Goethem, S. Tajalizadehkhoob, M. Korczyński,
Discovering Vulnerabilities with Code Property Graphs,” in IEEE S&P and W. Joosen, “Tranco: A research-oriented top sites ranking hardened
Symposium, 2014. against manipulation,” in NDSS Symposium, 2019.
[47] Neo4j Graph Database. [Online]. Available: https://neo4j.com/ [79] Google Programmable Search Engine Pricing. [Online]. Available:
[48] Cypher Query Language. [Online]. Available: https://neo4j.com/deve https://developers.google.com/custom-search/docs/overview
loper/cypher/ [80] Joern jssrc2cpg library. [Online]. Available: https://github.com/joernio
[49] Arrow function expressions. https://developer.mozilla.org/en-US/docs/ /joern/tree/master/joern-cli/frontendjssrc2cpg
Web/JavaScript/Reference/Functions/Arrow functions. [81] B. Eriksson, G. Pellegrino, and A. Sabelfeld, “Black widow: Blackbox
[50] setInterval global function. https://developer.mozilla.org/en-US/docs/ data-driven web scanning,” in IEEE Symposium on Security and
Web/API/setInterval. Privacy (SP). IEEE, 2021.
[51] globalThis Object. https://developer.mozilla.org/en-US/docs/Web/Java [82] Joern engine. [Online]. Available: https://github.com/joernio/joern
Script/Reference/Global Objects/globalThis. [83] M. Alkhalaf, T. Bultan, and J. L. Gallegos, “Verifying client-side input
[52] Promise.prototype.then(). https://developer.mozilla.org/en-US/docs/We validation functions using string analysis,” in 2012 34th International
b/JavaScript/Reference/Global Objects/Promise/then. Conference on Software Engineering (ICSE), 2012.
[53] M. Madsen, O. Lhoták, and F. Tip, “A model for reasoning about [84] Location: assign() method. [Online]. Available: https://developer.mozi
javascript promises,” in ACM OOPSLA, 2017. lla.org/en-US/docs/Web/API/Location/assign
[54] Web API Specifications. [Online]. Available: https://developer.mozill [85] Content Security Policy: navigate-to directive. [Online]. Available:
a.org/en-US/docs/Web/API https://csplite.com/csp123/
[55] M. Steffens and B. Stock, “PMForce: Systematically Analyzing [86] F. Li, “Shim shimmeny: evaluating the security and privacy contri-
postMessage Handlers at Scale,” in CCS, 2020. butions of link shimming in the modern web,” in USENIX Security
[56] Using Burp to Test for Open Redirections. [Online]. Available: https: Symposium, 2020.
//portswigger.net/support/using-burp-to-test-for-open-redirections [87] Pentester Land Open Redirect Cheetsheet. [Online]. Available: https:
[57] BurpSuite. Last accessed June 2024. [Online]. Available: https: //pentester.land/cheatsheets/2018/11/02/open-redirect-cheatsheet.html
//portswigger.net/burp [88] R. Yang, G. Li, W. C. Lau, K. Zhang, and P. Hu, “Model-based
[58] (2010) Owasp zed attack proxy. https://www.zaproxy.org/. security testing: An empirical study on oauth 2.0 implementations,”
[59] ZAP: Open Redirect. [Online]. Available: https://www.zaproxy.org/do in Proceedings of the 11th ACM on Asia Conference on Computer and
cs/alerts/10028/ Communications Security, 2016.
[60] D. W. Binkley and K. B. Gallagher, “Program slicing,” Advances in [89] X. Du, B. Chen, Y. Li, J. Guo, Y. Zhou, Y. Liu, and Y. Jiang,
computers, 1996. “Leopard: Identifying vulnerable code for vulnerability assessment
[61] window.open() API. [Online]. Available: https://developer.mozilla.org/ through program metrics,” in IEEE/ACM 41st International Conference
en-US/docs/Web/API/Window/open on Software Engineering (ICSE). IEEE, 2019.
[62] window.name API. [Online]. Available: https://developer.mozilla.org/ [90] N. Medeiros, N. Ivaki, P. Costa, and M. Vieira, “Vulnerable code
en-US/docs/Web/API/Window/name detection using software metrics and machine learning,” IEEE Access,
[63] S. Son and V. Shmatikov, “The Postman Always Rings Twice: Attack- 2020.
ing and Defending postMessage in HTML5 Websites,” in Proceedings [91] F. Yamaguchi, K. Rieck et al., “Vulnerability extrapolation: Assisted
of the Network and Distributed Systems Security Symposium, 2013. discovery of vulnerabilities using machine learning,” in 5th USENIX
[64] S. A. Mirheidari, M. Golinelli, K. Onarlioglu, E. Kirda, and B. Crispo, Workshop on Offensive Technologies (WOOT 11), 2011.
“Web cache deception escalates,” in USENIX Security Symposium, [92] K. Z. Sultana, V. Anu, and T.-Y. Chong, “Using software metrics for
2022. predicting vulnerable classes and methods in java projects: A machine
[65] O. Tsai, “A New Era of SSRF - Exploiting URL Parser in Trending learning approach,” Journal of Software: Evolution and Process, 2021.
Programming Languages,” Blackhat USA, 2017. [Online]. Available: [93] S. Moshtari, A. Sami, and M. Azimi, “Using complexity metrics to
https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New- improve software security,” Computer Fraud & Security, vol. 2013,
Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming- 2013.
Languages.pdf [94] Y. Shin and L. Williams, “An initial study on the use of execution
[66] N. Gruegoire, “Server-Side Browsing Considered Harmful,” OWASP complexity metrics as indicators of software vulnerabilities,” in Pro-
AppSec EU, Amsterdam, 2015. [Online]. Available: https://www.agarri ceedings of the 7th International workshop on software engineering
.fr/docs/AppSecEU15-Server side browsing considered harmful.pdf for secure systems, 2011.
[67] N. Moshe, S. Brizinov, R. Onitza-Klugman, and K. Efimov, “Exploiting [95] R. Scandariato, J. Walden, A. Hovsepyan, and W. Joosen, “Predicting
url parsers: the good, the bad and the inconsistent,” 2021. vulnerable software components via text mining,” IEEE Transactions
[68] HackerOne Open Redirect Vulnerability Reports. [Online]. Available: on Software Engineering, 2014.
https://hackerone.com/hacktivity/overview?queryString=open+redirect [96] Y. Zhang, D. Lo, X. Xia, B. Xu, J. Sun, and S. Li, “Combining software
+AND+disclosed%3Atrue metrics and text features for vulnerable file prediction,” in 2015
[69] CWE-601: URL Redirection to Untrusted Site. [Online]. Available: 20th International Conference on Engineering of Complex Computer
https://cwe.mitre.org/data/definitions/601.html Systems (ICECCS), 2015.
[70] StackExchange Security Community. [Online]. Available: https: [97] V. H. Nguyen and L. M. S. Tran, “Predicting vulnerable software
//security.stackexchange.com/ components with dependency graphs,” in Proceedings of the 6th
[71] Dev Security Community. [Online]. Available: https://dev.to/t/security International Workshop on Security Measurements and Metrics, 2010.
[72] C. Polop. (2022) HackTricks Cheatsheet Series - Open Redirect. [98] M. Gegick, L. Williams, J. Osborne, and M. Vouk, “Prioritizing soft-
[Online]. Available: https://book.hacktricks.xyz/pentesting-web/open- ware security fortification throughcode-level metrics,” in Proceedings
redirect of the 4th ACM workshop on Quality of protection, 2008.
[73] OWASP Testing Guide for Client-side URL Redirects. [Online]. [99] Y. Shin, A. Meneely, L. Williams, and J. A. Osborne, “Evaluating
Available: https://owasp.org/www-project-web-security-testing-guide/ complexity, code churn, and developer activity metrics as indicators of
v42/4-Web Application Security Testing/11-Client-side Testing/04- software vulnerabilities,” IEEE transactions on software engineering,
Testing for Client-side URL Redirect 2010.
[74] P. Schulz. (2022) intigriti Open Redirect Article. [Online]. Available: [100] Y. Shin and L. Williams, “Can traditional fault prediction models be
https://blog.intigriti.com/hackademy/open-redirect/ used for vulnerability prediction?” Empirical Software Engineering,
[75] V. Security, “URL Redirection: Attack and Defense,” 2022. [Online]. 2013.
Available: https://www.virtuesecurity.com/kb/url-redirection-attack- [101] F. Yamaguchi, M. Lottmann, and K. Rieck, “Generalized vulnerability
and-defense/ extrapolation using abstract syntax trees,” in Proceedings of the 28th
[76] Open Redirect Filter Bypass Methods. [Online]. Available: https: annual computer security applications conference, 2012.
//github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%2 [102] J. Vanegue and S. K. Lahiri, “Towards practical reactive security audit
0Redirect using extended static checkers,” in 2013 IEEE Symposium on Security
[77] Payloads from Bug Bounty Reports for Open Redirect. [Online]. and Privacy, 2013.
Available: https://github.com/cujanovic/Open-Redirect-Payloads [103] M. Backes, K. Rieck, M. Skoruppa, B. Stock, and F. Yamaguchi,
15
“Efficient and Flexible Discovery of PHP Application Vulnerabilities,” # Pattern ID Params Count New
in Proceedings of the 2nd IEEE European Symposium on Security and 1 A1 ACTION, action url, affiliateRedirectURL, 109 59
Privacy, 2017. away, back url, backTo, backURL, base, burl,
[104] F. Al Kassar, G. Clerici, L. Compagna, D. Balzarotti, and F. Yamaguchi, call url, callback url, cburl, callbackLocation,
“Testability Tarpits: the Impact of Code Patterns on the Security Testing came from, clickurl, continue, ct0, current page,
data, dest, destino, domain, ext, externalRedirect,
of Web Applications.” in NDSS Symposium, 2022.
externalUrl, fail, forward, FORWARD URL,
[105] G. Pellegrino, M. Johns, S. Koch, M. Backes, and C. Rossow, gHomePage, go, goto, home, hostname, intentUrl,
“Deemon: Detecting CSRF with dynamic analysis and property jump, jump url, layer, link, linkAddress,
graphs,” in ACM CCS, 2017. linkback, lite url, location, login, login[redirect],
[106] P. Saxena, D. Akhawe, S. Hanna, F. Mao, S. McCamant, and D. Song, login redirect url, logout, mgnlReturnTo, net,
“A symbolic execution framework for javascript,” in IEEE Symposium oadest, old, origin, originUrl, page, pagina,
on Security and Privacy, 2010. path, post logout redirect uri, previousUrl,
[107] A. Alhuzali, R. Gjomemo, B. Eshete, and V. Venkatakrishnan, promerium redirect url, purl, qurl, rd, recurl,
redirect, redirect to, redirect to, redirect uri,
“NAVEX: Precise and scalable exploit generation for dynamic web
redirect url, redirectID, redirectOk, redirectto,
applications,” in USENIX Security Symposium, 2018. redirectUri, redirectUrl, ref, refer, referer,
[108] M. Heiderich, J. Schwenk, T. Frosch, J. Magazinius, and E. Z. Yang, referurl, request, request uri, RequestedPage,
“mXSS Attacks: Attacking Well-secured Web Applications by Using resizewidgeturl, ret url, RetourUrl, return,
innerHTML Mutations,” in CCS, 2013. return uri, return url, returnto, ReturnUrl, reurl,
[109] S. Calzavara, T. Urban, D. Tatang, M. Steffens, and B. Stock, “Rein- rurl, send, sendTo, service, sp url, src, st.link,
ing in the Web’s Inconsistencies with Site Policy,” in Network and submit-url, success, target, target link uri,
Distributed Systems Security Symposium, 2021. target url, TargetURL, to, uri, url, urlRedirect, v,
view url, next, next
[110] A. Mendoza, P. Chinprutthiwong, and G. Gu, “Uncovering HTTP
Header Inconsistencies and the Impact on Desktop/Mobile Websites,” 2 B1 action, callbackLocation, cont, forward, goto, link, 17 1
in World Wide Web Conference, 2018. loc, location, next, redir, redirect, referurl, return,
[111] F. Klien and M. Strohmaier, “Short links under attack: geographical targetUrl, targetAction, view, callbackUri
analysis of spam in a url shortener network,” in Proceedings of the 3 B2 advance, callback, callbackUri, ext, fetch, go, goto, 13 0
23rd ACM conference on Hypertext and social media, 2012. redir, ref, return, submitUrl, view, redirect
[112] P. Papadopoulos, N. Kourtellis, and E. P. Markatos, “The cost of digital
advertisement: Comparing user and advertiser views,” in World Wide 4 C1 ajaxUI, action, backTo, backurl, continue, 35 35
dest, destino, domain, ext, forward, forward url,
Web Conference, 2018. gHomePage, go, goto, home, location, next, origin,
[113] Cross-domain referer leakage. [Online]. Available: https://portswigger. page, recurl, redirect, redirect to, redirect uri,
net/kb/issues/00500400 cross-domain-referer-leakage redirect url, redirectTo, RedirectUrl, referer,
[114] B. Krishnamurthy, K. Naryshkin, and C. Wills, “Privacy leakage vs. return uri, return url, returnto, returnUrl, src, to,
protection measures: the growing disconnect,” in Proceedings of the uri, url
W2SP Conference, no. 2011, 2011.
[115] X. Likaj, S. Khodayari, and G. Pellegrino, “Where we stand (or fall): TABLE VIII: The complete list of parameters for vulnerability indicator
An analysis of csrf defenses in web frameworks,” in Proceedings of patterns in Table III. Parameters marked in cyan color are newly observed, as
the 24th International Symposium on Research in Attacks, Intrusions we did not find them during our review of existing vulnerability reports.
and Defenses, 2021.
[116] Bugcrowd. [Online]. Available: https://www.bugcrowd.com
[117] Hackerone. [Online]. Available: https://hackerone.com # Key Domains URLs
[118] B. Stock, G. Pellegrino, C. Rossow, M. Johns, and M. Backes, “Hey, 1 url 102 1224
you have a problem: On the feasibility of large-scale web vulnerability 2 domain 52 766
notification,” in USENIX Security Symposium, 2016. 3 redir 39 891
[119] Domain Spoofing in Redirect Page Using RTLO. [Online]. Available: 4 redirect 26 427
https://hackerone.com/reports/299403 5 next 17 245
[120] Google DoubleClick Open Redirect. [Online]. Available: https: 6 to 14 192
//packetstormsecurity.com/files/129113/ 7 r 12 204
[121] Open Redirect Vulnerability (OBB-2066676). [Online]. Available: 8 cburl 9 38
https://www.openbugbounty.org/reports/2066676/ 9 redirect uri 9 135
10 returnto 6 121
A PPENDIX TABLE IX: Top 10 URL query parameter keys with the highest number of
distinct domains that use the parameter for (open) redirections.
A. Additional Evaluation Details
Vulnerability Notification and Vendor Feedback. The open
we sought the support of our national CSIRT in January
redirect vulnerabilities identified in this paper impact 872
2024. We observed that site operators are generally reluctant
websites, of which for 332 sites we created an exploit. Our
to address open redirections unless they are shown to have
notification process began in June 2023, aligning with the dis-
broader impacts. At the time of writing this paper, only 18
covery of these vulnerabilities, adhering closely to established
sites decided patching among the 540 sites where we found
vulnerability notification best practices [118]. Prioritizing our
no escalations of open redirects.
reports based on known exploits, we sent an initial notification
containing the vulnerability description and proof-of-concept B. Additional Case Studies
exploits, with monthly subsequent reminders. As of the pa-
per’s writing, all 332 sites with created exploits have been We present additional case studies of the confirmed attacks.
notified at least once, with 71 confirming the issues and 49 OK. We found an open redirect vulnerability in ok.ru. through
successfully patching them, including popular platforms like a query parameter named st.link. We exploited this vul-
TP-Link, Adobe, Starz, and WebNovel. For the remaining nerability to leak OAuth tokens, resulting in user account
open redirects, we needed to contact 540 sites, for which takeover. OAuth [17] is a mechanism through which users
16
.
Category Attack Technique Example \ w References
URI schemes URL (Identity) evil.com 7 [2, 3, 28, 30, 31, 69, 74, 87]
(Basic) Data data:text/html;base64,XSS-payload 7 [76, 87]
JS javascript:alert(1)// 7 [72–74, 76, 87]
Scheme Use Backslash https:\\evil.com 7 7 [67, 76]
Escape Slash https:\/\/evil.com 7 7 [76]
No Slashes []evil.com 7 7 [87]
Relative URI []//evil.com 7 [29, 76, 87]
Encode Colon https%3A//evil.com 7 [64, 87]
Encode Slash https:%2F%2Fevil.com 7 [64, 67, 87]
Encode Specials https%3A%2F%2Fevil.com 7 [64, 87]
Netloc Unicode Dot Encoding https://evil%E3%80%82com 7 [87]
Unicode Normalization https://evil.com/s .trusted.com 7 [76]
Right-to-Left Override trusted.com@%E2%80%AE@moc.live 7 [77, 87, 119]
Prepend Whitelist trusted.com.evil.com 7 7 [76, 77, 87]
Prepend Authentication trusted.com@evil.com 7 [67, 76, 77, 87]
Path Directory Confusion evil.com/path/www.trusted.com 7 [76, 77]
Query Parameter Pollution redir=trusted.com&redir=evil.com 7 [76, 87]
IP Decimal 1.2.3.4 7 [2, 66, 87]
Dotless Decimal 16909060 7 [66, 87]
Hex 0x01.0x02.0x03.0x04 7 [66]
Dotless Hex 0x01020304 7 [66]
Octal 0001.0002.0003.0004 7 [66]
Dotless Octal 0x01020304 7 [66]
Injection Null Byte evil%00.com 7 [76, 77]
CRLF java%0d%0ascript%0d%0a:alert(1) 7 [65, 72, 76, 77]
Other Alternating Caps jAvAsCrIpT:alert(1) 7 [72]
TABLE X: Overview of open redirect attack techniques. The examples redirect trusted.com to evil.com with an IP of 1.2.3.4. The column \ marks
techniques that may bypass server-side filters whereas w shows techniques bypassing client-side input validation checks. The 7 symbol marks applicable
attack techniques.
Candidate Vuln.
Fig. 3: Growth of indicator patterns across vulnerable webpages in P1 dataset.
Source Pattern URLs Sites URLs Sites
Internet Archive A1 162,562 6,108 205 171
A2 15,675 1,270 44 37
B1 8,445 965 12 8
B2 1,502 417 3 1
B3 198 44 1 1
B4 21 5 0 0
Total 188,403 8,045 265 218
Google Search A1 661 371 12 11
A2 380 123 7 7
B1 121 56 2 2
B2 49 12 0 0
B3 17 5 0 0
B4 9 2 1 1
Total 1,237 569 22 21
Live Crawl A1 19,210 2,045 40 37
A2 2,866 706 15 15
B1 404 210 4 4
B2 18 10 0 0
B3 2 4 1 1
B4 1 1 0 0
C1 2,786 828 24 23
C2 655 399 8 6
C3 223 155 2 2
Total 26,163 3,089 94 88
Total 214,645 8,045 375 326 Once the user grants the requested permissions to the service
provider, the identity provider sends an authorization code to
TABLE XI: Overview of vulnerability mining results. the specified destination in the redirect_uri. However,
mail.ru checks that the redirect_uri value belong to the
ok.ru site before sending the authorizaiton code. To bypass
can provide service providers with access tokens for specific this check, we can exploit the open redirect vulnerability in
scopes via an identity provider. We found that ok.ru allows its ok.ru to chain the redirects and forward the request to an
users to authenticate via mail.ru identity provider which works attacker-controlled domain, stealing the authorization code left
with a redirect_uri parameter (see, e.g., [17, 74, 88]). in the request referrer HTTP header.
17
Listing 4: Excerpt of a client-side open redirect vulnerability in tp-link.com
escalated to DOM XSS. of client-side redirections to XSS attacks by disallowing
1 let $url = new URLSearchParams(location.search). javascript: URIs. We found that CSP blocked the major-
get('url'); ity of the XSS escalations (i.e., 83 out of 108 or 76%), whereas
2 let $params = location.hash.slice(1).toLowerCase the remaining webpages (24%) had proper input sanitization
();
3 let $product = params.match('&pview=true'); procedures that stopped the injection of inline JavaScript code.
4 if($product && screen.width<=1024){
5 // $url: javascript:alert(1); D. URL De-duplication
6 location.href=$url;} In §V-A, we performed URL de-duplication to limit our
results to unique endpoints only. To do that, we used a
Listing 5: Excerpt of a client-side open redirect vulnerability in udn.com
escalated to DOM XSS.
heuristic-based approach to detect dynamic URL components
1 var toUrl = document.URL;
(e.g., numbers in the path) by comparing the syntax and value
2 var whereIs = toUrl.indexOf("redir="); of discovered URL elements with one another. We classified
3 whereIs_end = toUrl.indexOf("&site="); a URL component as dynamic if the prefix and the suffix (if
4 if ( whereIs_end == -1 || whereIs_end < whereIs
){
present) of the component remained constant, while the value
5 whereIs_end=toUrl.length; } of the component changed in candidate URLs. We observed
6 url=toUrl.substring(whereIs+6,whereIs_end); that this heuristic is conservative, as its application, following
7 setTimeout("window.location=url",1000);
manual review of 1000 random URL groupings, revealed
little-to-no false positives in our dataset (rate of 1/1000). In
summary, we considered the following types: (i) NUMBER for
Google WebLight and DoubleClick. We found a vulner- all strings that represent a number; (ii) RESOURCE for all
abilitiy in weblight where a URL query parameter u was strings that contain a dot and the latter part is a valid MIME
not validated and allowed redirection to arbitrary domains. type (e.g., “image.png”); (iii) SIMPLE for all strings that only
Similarly, we found an open redirection in the DoubleClick contain alphanumeric characters; (iv) COMPOSITE for every
advertising service where the destination of a query parameter string that contains a dash or underscore (e.g., “blog-title”);
adurl was not validated before redirection. However, while and (v) COMPLEX for every string not meeting any of the
confirming the open redirection in DoubleClick, we realized criteria before (e.g., “%46%4F%4F”). If multiple predicates
that it is a known issue (see, e.g., [120, 121]) which Google match, we choose the type corresponding to the first match.
decided not to patch.
TP-Link and UDN. Listing 4 shows a simplified version of an
inline script vulnerable to client-side open redirect vulnerabil-
ity that we found in tp-link.com. The vulnerability affects the
product view functionality of the store. The program initially
extracts the value of the url query parameter in line 1,
examines the necessity of the product view functionality based
on a flag in the URL fragment (lines 3-4), and subsequently
employs it as the value for location.href in line 6.
However, a notable input validation vulnerability exists as the
code does not sanitize the url value against javascript:
URIs, making it possible to acheive DOM XSS attacks.
A similar vulnerability affects udn.com, as illustrated
in Listing 5. Here, the code reads the value of the query
parameter redir in line 2 and subsequently sets the value
of window location to the read value after one seconds using
the setTimeout instruction (line 7). Similarly to TP-Link,
it can be exploited for arbitrary client-side code execution.
C. Mitigating Escalations
In this section, we examine cases where we were unable to
escalate a confirmed client-side open redirect vulnerability to
XSS. Our goal is to identify potential mitigation strategies to
counteract escalations. To do that, we manually analyzed all
JavaScript-based open redirections we found via vulnerability
mining in §V-B. Out of the 375 open redirect URLs, 202 are
JavaScript-based, and among them, 108 cannot be exploited
for XSS attack. By examining these 108 URLs, we found
two mitigating reasons. First, CSP can mitigate the escalation
18