XSinator.

com: From a Formal Model to the Automatic

Evaluation of Cross-Site Leaks in Web Browsers
Lukas Knittel Christian Mainka Marcus Niemietz
Ruhr University Bochum Ruhr University Bochum Niederrhein University
[email protected] [email protected] of Applied Sciences
[email protected]

Dominik Trevor Noß Jörg Schwenk

Ruhr University Bochum Ruhr University Bochum
[email protected] [email protected]

ABSTRACT 1 attacker.com target.com

Cross-Site Leaks (XS-Leaks) describe a client-side bug that allows Victim visits
an attacker to collect side-channel information from a cross-origin attacker.com
2
HTTP resource. They are a significant threat to Internet privacy Use
since simply visiting a web page may reveal if the victim is a drug Inclusion Cookie State-
Method Dependent
addict or leak a sexual orientation. Numerous different attack vec- Resource
tors, as well as mitigation strategies, have been proposed, but a 3
clear and systematic understanding of XS-Leak’ root causes is still Use Leak
Technique
missing.
Recently, Sudhodanan et al. gave a first overview of XS-Leak at
4
NDSS 2020. We build on their work by presenting the first formal Determine
model for XS-Leaks. Our comprehensive analysis of known XS- User State
Leaks reveals that all of them fit into this new model. With the help
of this formal approach, we (1) systematically searched for new
XS-Leak attack classes, (2) implemented XSinator.com, a tool to
Figure 1: XS-Leak attack flow example. The victim (1) visits
automatically evaluate if a given web browser is vulnerable to XS-
the attacker-controlled website, which (2) uses an inclusion
Leaks, and (3) systematically evaluated mitigations for XS-Leaks.
method to request a state-dependent resource from a target
We found 14 new attack classes, evaluated the resilience of 56
website. The attacker then uses (3) a leak technique to (4)
different browser/OS combinations against a total of 34 XS-Leaks,
determine the victim’s user state.
and propose a completely novel methodology to mitigate XS-Leaks.

CCS CONCEPTS 1 INTRODUCTION

• Information systems → Browsers; Web applications; • Secu- Web Applications and User States. In a web application, a web
rity and privacy → Formal security models. browser interacts with several web servers through HTTP or Web-
Socket connections. The client-side logic of the web application
KEYWORDS is written in HTML, CSS, and JavaScript code, and is executed
XS-Leaks; Browser; Web Security inside a tab of the browser, or inside an inline frame in another
application. The execution context of a web application is defined
ACM Reference Format: through the concept of web origins [5]. Web applications may call
Lukas Knittel, Christian Mainka, Marcus Niemietz, Dominik Trevor Noß, and embed other web applications to enhance functionality. For
and Jörg Schwenk. 2021. XSinator.com: From a Formal Model to the Auto- example, a hotel reservation site may embed Google Maps and
matic Evaluation of Cross-Site Leaks in Web Browsers. In Proceedings of the
public transportation sites as an easy method to allow its customers
2021 ACM SIGSAC Conference on Computer and Communications Security
to determine how to reach the hotel. In such situations, cross-origin
(CCS ’21), November 15–19, 2021, Virtual Event, Republic of Korea. ACM, New
York, NY, USA, 18 pages. https://doi.org/10.1145/3460120.3484739 HTTP requests between different web origins are necessary to
retrieve data to embed and display in the web application.
When interacting with a website, a user has a well-defined state
Permission to make digital or hard copies of part or all of this work for personal or – this state typically contains the information whether the user is
classroom use is granted without fee provided that copies are not made or distributed logged in or not. Besides the login status, the user state may contain
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for third-party components of this work must be honored. account permissions, such as admin privileges, premium member-
For all other uses, contact the owner/author(s). ship, or restricted accounts. The number of different user states
CCS ’21, November 15–19, 2021, Virtual Event, Republic of Korea is potentially unlimited. For example, in a webmail application, a
© 2021 Copyright held by the owner/author(s).
ACM ISBN 978-1-4503-8454-4/21/11. user may or may not have received an email with the subject “top
https://doi.org/10.1145/3460120.3484739 secret”.
 Privacy Risks of Cross-Origin Requests. Consider the fol- work, both academic and non-academic, added further attack classes,
lowing situation: the attacker has lured a victim on a malicious web and showed that XS-Leaks are a novel paradigm in attacks on pri-
application that executes hidden cross-origin HTTP requests to vacy. We build on their work to propose the first formal model for
different drug counseling sites. If the attacker could learn whether XS-Leak attacks (Section 2). This formalization allows us to extend
the victim is logged in at one of these drug counseling sites, the their work in three aspects:
attacker would gain highly privacy-critical information about the (1) By distinguishing between inclusion methods 𝑖 and leak
victim. techniques 𝑡, we provide a clear methodology on how to
Cross-Site Leaks on the User States. To distinguish between search for novel, yet undiscovered, XS-Leaks. While we did
two user states, the attacker’s JavaScript code must be able to iden- not extend the set of inclusion methods 𝐼 , we later show that
tify differences in its own execution environment resulting from mitigations may work for certain inclusion methods only.
different responses to cross-origin HTTP requests. These different On the other hand, we could substantially extend the set 𝑇
responses must correspond to different user states at the target web of leak techniques, by grouping known elements of 𝑇 and
application. If this differentiation is possible, we call this vulnera- systematically searching for new vectors which may fit in
bility an XS-Leak. The attacker can then craft a malicious website, these groups.
which triggers the XS-Leak once the victim opens it (Figure 1). In (2) To systematically evaluate the three-dimensional matrix con-
the following two real-world examples, we try to exemplify the sisting of pairs (𝑖, 𝑡, 𝑤), where 𝑤 ∈ 𝑊 is a web browser from
scope of the problem. the set of tested web browsers, we build a tool called XSinator.
XS-Leak on Gitlab. Gitlab is a popular web application for This tool uses hand-crafted state-dependent resources to de-
collaborative software development hosted by many companies. termine if there exists at least one pair 𝑖, 𝑡 for which the state
Gitlab provides a profile URL https://git.company.com/profile: if of this resource can be leaked in 𝑤. If at least one such pair
the user is not logged in, this URL redirects the user to https: exists, we label 𝑤 as vulnerable against this attack vector.
//git.company.com/users/sign_in; if the user is logged in, the cur- With this tool, we were able to detect major differences be-
rent user’s profile information is shown. However, since the attacker tween browser implementations (Table 2). These findings
embeds Gitlab cross-origin into the attacker’s own web page, the are used as guides to propose new mitigation methods.
attacker cannot directly read the URL. In Listing 1, we use the (3) By separating inclusion methods 𝑖 and leak techniques 𝑡,
window.length property, which is readable cross-origin, to deter- we could evaluate existing and propose novel mitigations.
mine the user state; the profile page does not contain any iframes, Current mitigations mainly focus on the inclusion methods.
but the login page includes three frames. If this property has the 4 out of 7 mitigations discussed in [51] are related to HTTP
value 3, the user is not logged in. If it has the value the 0, the user is headers, which only may be effective against certain inclu-
logged in. By scanning different company websites hosting Gitlab, sion methods. For example, SameSite=Lax cookies are only
the attacker may collect information on a programmer’s affiliation. effective if the target resource is included as an iframe, but
not if it is called with window.open. We introduce a novel
Listing 1: XS-Leak on Gitlab. class of mitigations, which in Sudhodanan et al. [51] is only
let url = 'https://git.company.com/profile' present as a short analysis of the Tor browser. This class of
let ref = window.open(url, '_blank') mitigations targets the leak techniques𝑇 and can be sketched
// wait until pop-up is loaded as follows: if our evaluation (Table 2) shows that some web
let counted_frames = ref.window.length; browsers are immune to certain XS-Leaks, this indicates that
if (counted_frames === 0) { the corresponding leak techniques can be fixed by changing
// User is logged in the browser implementation. So in our discussion of mitiga-
} else if (counted_frames === 3) { tions, we clearly distinguish between mitigations targeting
// User is NOT logged in certain inclusion methods only, and mitigations targeting
} leak techniques.
Empirical Study with Reproducible Results. XSinator is an
XS-Leak on Google Mail. Google Mail is one of the most popu- easy to deploy web application. With a single click, all XS-Leaks
lar webmail applications. In 2019, Terjanq [53] reported an XS-Leak test cases can be automatically executed for the active browser. We
which could determine whether an email with a certain subject used XSinator to evaluate 37 different web browsers on desktop
(e.g., “drug counseling”) or content was present in the user’s inbox operating systems, 9 on Android, and 10 on iOS. Surprisingly, we
cross-origin. The XS-Leak abused the common cache that web ap- identified very different XS-Leaks in all major browser families such
plications share. By using the advanced search option, which can be as Chromium, Firefox (FF), and Safari (SA). Browsers based on the
called cross-origin, Google Mail marks search results (if any exist) Chromium engine (i.e., Google Chrome (GC), Microsoft Edge (MSE),
with a dedicated image. To perform an XS-Leak attack, the attacker Opera (OP)) behave identically. For example, XS-Leaks identified
first empties the web cache, then calls Google Mail advanced search, in GC are also applicable to all other browsers based on the same
and finally checks if the dedicated image is available in the cache. engine. Moreover, we could detect differences in FF compared to
If true, the search was successful, and the attacker learned that an the Tor browser.
email containing the used search term exists in the victim’s inbox.
Formal Modelling and Testing. Sudhodanan et al. [51] gave
the first classification of existing XS-Leaks. They surveyed related
 Contributions. We make the following key contributions: 2 FORMAL XS-LEAK DESCRIPTION
• We are the first to present a formal model for XS-Leaks. This section gives a formal description of XS-Leak attacks as a basis
We show that this model can be used to gain a systematic for further analysis. This formal description helps us to (1) classify
in-depth understanding of XS-Leaks’ root causes (Section 2). existing XS-Leaks thoroughly, (2) systematically identify new candi-
• We implemented XSinator, an easy-to-use, open-source web- dates for XS-Leaks, and (3) classify and evaluate countermeasures.
site that is publicly available at XSinator.com. With a single
click, XSinator can automatically scan for XS-Leaks vulner- 2.1 Formal Description
abilities in every browser, including mobile and desktop
Same Origin. We first formalize the well-known fact that requests
(Section 3).
to the same URL may yield different results, depending on which
• We analyze known vulnerabilities and show that they fit
state 𝑠 the web application is currently in.
into our formal model (Section 4).
• We significantly extend the set of known XS-Leak attack Definition 2.1 (State-dependent resource). A state-dependent re-
vectors by contributing 14 new XS-Leaks with the help of source 𝑠𝑑𝑟 is a 2-tuple (𝑢𝑟𝑙, (𝑠, 𝑑)), where (𝑠, 𝑑) ∈ {(𝑠 0, 𝑑 0 ), (𝑠 1, 𝑑 1 )},
our formal model (Section 5). and
• We evaluated 56 browser/OS combinations against a total set • 𝑢𝑟𝑙 is a URL resource on the target web application.
of 34 XS-Leaks XSinator fully automatically. We identified • 𝑆 = {𝑠 0, 𝑠 1 } is a set of two different states of the target web
XS-Leaks in 37 desktop, 9 Android and 10 iOS web browsers. application.
(Section 6). • 𝐷 = {𝑑 0, 𝑑 1 } is a set that represents the difference of the web
• We use XSinator and the formal distinction between leak application’s behavior that depends on 𝑠 0 and 𝑠 1 .
techniques and inclusion methods to propose a novel class of
mitigation that disables leak techniques within web browser Differences. Please note that the definition of 𝐷 is, by intention,
implementations (Section 7). somewhat vague. Two different states 𝑠 0, 𝑠 1 on the same 𝑢𝑟𝑙 ∈ URL
Artifact Availability. In the interest of open science, our tool can result in different behavior by the web application. The differ-
and its source code, including all 34 XS-Leaks implementations, are ence 𝑑 ∈ 𝐷 manifests itself either directly in the initial response
available at XSinator.com. (e.g., HTTP status code, or different HTML elements) or indirectly
Responsible Disclosure. We reported new leak techniques to when the web application behaves differently (e.g., a navigation
Google and Mozilla and the disclosure process is still ongoing. We triggered by JavaScript code). Our notion of 𝑑 does not only cover
incorporated their feedback into our countermeasure discussion in differences in HTTP requests and responses, but also side-effects
Section 7. on the APIs caused by these responses.
States. A web application may have (potentially infinitely many)
different states 𝑠 ∈ 𝑆 for a user 𝑣. To successively detect the de-
sired state, the attacker may use a divide-and-conquer approach,
for example, by detecting the subject on an email in a webmail
application letter by letter. For this reason, in our model, we con-
centrate on distinguishing between two different states 𝑠 0, 𝑠 1 . States
are typically stored in the web browser, which sends them along
with the HTTP Request (e.g., HTTP cookies, cache content).
Cross-Origin. In the web attacker model, an adversary can
only access a state-dependent resource 𝑠𝑑𝑟 from a different web
origin. He thus must use an inclusion method to include 𝑠𝑑𝑟 into
his web page, and he may use different leak techniques to observe
the victim’s web browser from his malicious JavaScript code.
Definition 2.2 (Cross-Site Leak). A Cross-Site Leak is a function
𝑥𝑠𝑙 () that outputs a bit 𝑏 ′ , that is 𝑏 ′ = 𝑥𝑠𝑙 (𝑠𝑑𝑟, 𝑖, 𝑡) where
• 𝑠𝑑𝑟 ∈ 𝑆𝐷𝑅 is a state-dependent resource.
• 𝑖 ∈ 𝐼 is an inclusion method to request a cross-origin resource.
• 𝑡 ∈ 𝑇 is a leak technique which can be used to observe state-
dependent resources cross-origin.
The difference 𝑑 in a state-dependent resource 𝑠𝑑𝑟 is called de-
tectable if there exists an inclusion method 𝑖 and a leak technique 𝑡
such that 𝑥𝑠𝑙 ((𝑢𝑟𝑙, (𝑠𝑏 , 𝑑𝑏 )), 𝑖, 𝑡) = 𝑏 for all requests.
Inclusion methods 𝑖 ∈ 𝐼 trigger cross-origin requests to the tar-
get web application’s state-dependent resource 𝑠𝑑𝑟 in the victim’s
browser 𝑤 𝑣 . For example, the attacker can include the 𝑢𝑟𝑙 of the 𝑠𝑑𝑟
(i.e., 𝑠𝑑𝑟 .𝑢𝑟𝑙) in the src attribute of a specific HTML element, and
may use the target when opening new browser tabs or windows, or
can use the Fetch API. Note that since 𝑖 issues a cross-origin request, attack surface in any weaker, more realistic attacker model. Our
𝑡 cannot directly access the server response due to the Same-Origin security experiment can be described as follows:
Policy (SOP) that forbids cross-origin access.
Definition 2.3 (XS-Leak Security Experiment). The XS-Leak Secu-
Leak techniques 𝑡 ∈ 𝑇 provide information that malicious Java-
rity Experiment operates as follows:
Script can observe cross-origin when it runs in the victim’s web
browser 𝑤 𝑣 . This information may be rooted in the JavaScript exe- • Setup. In our security experiment, the attacker sets up a web
cution context (e.g., event handlers, readable DOM attributes), in application’s state-dependent resources 𝑠𝑑𝑟 0 = (𝑢𝑟𝑙, (𝑠 0, 𝑑 0 )),
the global state of the web browser (e.g., global resource limits), or 𝑠𝑑𝑟 1 = (𝑢𝑟𝑙, (𝑠 1, 𝑑 1 )), where the web application at 𝑢𝑟𝑙 differs
on Web APIs (e.g., the Performance API). It can vary in different exactly in 𝑑 based on 𝑠. The attacker then creates an XS-Leak
browsers. For example, a piece of information may be accessible 𝑥𝑠𝑙 with the inclusion method 𝑖 and the leak technique 𝑡,
cross-origin in Firefox but inaccessible in Chrome. and deploys the resulting code in the web browser 𝑤 𝑣 under
Example: Cross-Site Leak on Gitlab. Let us illustrate these investigation.
definitions with the XS-Leak on Gitlab as depicted in Listing 1. In • Execution. An unbiased random bit 𝑏 ∈ {0, 1} is chosen by
that case, we have a state-dependent resource 𝑠𝑑𝑟 with the environment, and the resource 𝑠𝑑𝑟𝑏 , which uses state
𝑠𝑏 , is selected. The attacker does not learn 𝑏. The attacker
• 𝑢𝑟𝑙 = https://git.company.com/profile may now issue a request to 𝑠𝑑𝑟𝑏 , using inclusion method 𝑖.
• 𝑠 ∈ {logged-in, logged-out} Once the response has been returned, the attacker may try
• 𝑑 is the number of frames included in the page: 𝑑 0 = 0 for to determine the state 𝑠 by learning the detectable difference
state logged-in, and 𝑑 1 = 3 for state logged-out. 𝑑 through the use of leak technique 𝑡 in 𝑤 𝑣 . From 𝑑, the
Note that the reconnaissance phase, in which such state-dependent attacker derives state 𝑠 and, therefore, bit 𝑏 ′ .
resources are found, is conducted on the web application itself • Winning condition. The attacker wins the security exper-
(same origin) and thus is not limited by the cross-origin restrictions. iment if 𝑏 ′ = 𝑏.
Whether a state-dependent resource is exploitable in an XS-Leak
depends on the attacker finding a suitable 𝑖 and 𝑡 that works in 2.3 Detectable Differences
a victims browser. In this example, the attacker implements the A detectable difference is a difference 𝐷 that can be observed cross-
XS-Leak 𝑏 ′ = 𝑥𝑠𝑙 (𝑠𝑑𝑟, 𝑖, 𝑡) as follows: origin through at least one pair (𝑖, 𝑡) to infer the actual state – we
• window.open(sdr, '_blank') is the inclusion method 𝑖. do not observe the difference directly, but rather through a side
• The DOM property window.length is the leak technique 𝑡, effect that this difference causes. We categorized them into five
which reads the number of frames 𝑑 by using the pop-up groups:
window reference from 𝑖. Status Code. An attacker can distinguish different HTTP re-
• The function 𝑥𝑠𝑙 () is given in Listing 1. sponse status codes cross-origin (e.g., server errors, client errors,
or authentication errors).
2.2 Attacker Model API Usage. This detectable difference allows an attacker to
Different attacker models can be derived from this formal descrip- detect Web APIs’ usage across pages, allowing an attacker to infer
tion by giving the attacker control over the different components whether a cross-origin page is using a specific JavaScript Web API.
of an XS-Leak 𝑑 = 𝑥𝑠𝑙 (𝑠𝑑𝑟, 𝑖, 𝑡). Redirects. It is possible to detect if a web application has navi-
Real-World Attacks. In real-world attacks, the attacker only gated the user to a different page. This is not limited to HTTP redi-
controls the inclusion method 𝑖 and the leak technique 𝑡 through rects but also includes redirects triggered by JavaScript or HTML.
the malicious HTML page that they created. The attacker has no Page Content. These detectable differences appear in the HTTP
control of 𝑠𝑑𝑟 .𝑠, which is stored in the victim’s browser, or 𝑠𝑑𝑟 .𝑑, response body itself or in sub-resources included by the page. For
which depends on the target web application. To determine a state- example, this could be the number of included frames (cf. XS-Leak
dependent resource 𝑠𝑑𝑟 , a reconnaissance phase is needed in which on Gitlab) or size differences of images.
the attacker collects information on different states 𝑠 that the web HTTP Header. An attacker can detect the presence of a specific
application may have, and on the resulting differences 𝑑 in the HTTP response header and may be able to gather its value. This in-
HTTP responses. cludes headers such as X-Frame-Options, Content-Disposition,
Evaluation. Our evaluation uses a stronger attacker model, and Cross-Origin-Resource-Policy.
which also gives the adversary full control over the state-dependent It is questionable that these groups are complete since new
resource 𝑠𝑑𝑟 . That is, the attacker can choose the 𝑢𝑟𝑙, choose a state browser features or yet unknown XS-Leaks might unveil new de-
𝑠 and a difference 𝑑. The only element the attacker does not control tectable difference. However, they serve as a guideline for finding
is the web browser and its cross-origin isolation techniques. In an new XS-Leaks (see Table 1).
ideal world, the browser should reduce the set of detectable dif-
ference to the empty set. Thus, we consider the strongest possible 2.4 Real-world Inclusion Methods
attacker, and we want to determine which XS-Leak may potentially In all XS-Leak attacks, the attacker’s web page uses cross-origin
exist in any web application. We describe this approach’s goal as inclusion methods to force the victim’s browser in requesting the
follows: if we can reduce the set of detectable difference in this state-dependent resource. In theory, the SOP should prevent cross-
strong attacker model by strengthening cross-origin isolation tech- origin information leakage, but this separation of web origins is not
niques within the web browser, then we automatically reduce the perfect and exceptions must be made; cf. Schwenk et al. [46] for a
partial analysis. In the following, we discuss four different groups This creates a global state because the number of entries allows an
of inclusion methods: attacker to draw conclusions about cross-origin pages.
HTML Elements. HTML offers a variety of elements that en- Performance API. The Performance API is used to access the
able cross-origin resource inclusion. Elements like stylesheets, im- performance information of the current page. Their entries include
ages, or scripts, force the victim’s browser to request a specified detailed network timing data for the document and every resource
non-HTML resource. A list that enumerates possible HTML ele- loaded by the page. This allows an attacker to draw conclusions
ments for this purpose is available online [21]. about requested resources. For example, we identified cases where
Frames. Elements such as iframe, object, and embed may embed browsers will not create performance entries for some requests.
further HTML resources directly into the attacker page. If the page Readable Attributes. HTML has several attributes that are
does not use framing protection, JavaScript code can access the readable cross-origin. This read access can be used as a leak tech-
framed resource’s window object via the contentWindow property. nique. For example, JavaScript code can read the number of frames
Pop-ups. The window.open method loads a resource in a new included in a webpage cross-origin with the window.frame.length
browser tab or window. The method returns a window handle that property.
JavaScript code can use to access methods and properties, which
comply with the SOP. These so-called pop-ups are often used in 3 XSINATOR: AUTOMATIC BROWSER
single sign-on. Modern browsers only allow pop-ups if they are EVALUATION
triggered by certain user interactions [43]. For XS-Leak attacks,
One of this paper’s main contributions is to evaluate the impact
this method is especially helpful because it bypasses framing and
of XS-Leak attacks on different web browsers 𝑤 ∈ 𝑊 . We system-
cookie restrictions for a target resource. Newer browser versions
atically extend the work of Sudhodanan et al. [51] by including
recently added means to isolate window handles, as described in
a broad set of relevant browsers, both desktop and mobile, and
Section 7.
extending the set of XS-Leak attacks significantly.
JavaScript Requests. JavaScript allows sending requests to tar-
get resources directly. There are two different ways for this purpose:
3.1 Implementation
XMLHttpRequests and its successor Fetch API [40]. In contrast to
previous inclusion methods, an attacker has fine-grained control Based on our formal description in Section 2, we evaluate all inclu-
over the issued request, for example, whether an HTTP redirect sion methods and leak techniques for a large set 𝑊 of web browsers.
must be automatically followed. For that, we built a web application named XSinator that consists
of three main components:
(1) A testing site that acts as an XS-Leak attacker page. It im-
plements known and novel XS-Leaks and evaluates them by
2.5 Real-world Leak Techniques running all of them with a single click.
An attacker can observe various types of information from cross- (2) A vulnerable web application, which simulates the behavior
origin resources. As it is not possible to directly access the response of a state-dependent resource (𝑠𝑑𝑟 ) for each XS-Leak. This
of a cross-origin request, an XS-Leak attacker relies on side effects web application has two states 𝑠 0 and 𝑠 1 , which are triggered
that are caused by the included resource. We found that the tech- via a parameter in the HTTP requests. The states trigger
niques used to detect these side effects can ultimately be ascribed to different behavior in the 𝑠𝑑𝑟 , for instance, in state 𝑠 0 , the 𝑠𝑑𝑟
a set of core problems. By analyzing the existing and new XS-Leaks has difference 𝑑 0 and 𝑑 1 in 𝑠 1 .
we identified six groups: (3) A database containing all previous test results. Security re-
Event Handler. Event handler can be seen as the classical leak searchers can use this database to compare these results with
technique for XS-Leaks. They are a well-known source of various the actual results of a new browser and track the XS-Leaks’
pieces of information. For example, the trigger of onload indicates exploitability over time.
a successful resource loading in contrast to the onerror event. The JavaScript code aims to distinguish states 𝑠 0 and 𝑠 1 based on
Error Messages. Beyond event handlers, error messages can the retrieved side-channel information. In our formal description,
occur as JavaScript exceptions and special error pages. Error mes- we consider an XS-Leak exploitable (denoted by ○ in Table 2, Ta-
sages can be thrown in different steps, for example, directly by ble 3, and Table 4), if there exists an inclusion method 𝑖 and a leak
the leak technique. The leak technique can either use additional technique 𝑡 in web browser 𝑤 such that 𝑥𝑠𝑙 ((𝑢𝑟𝑙, 𝑠𝑏 , 𝑑𝑏 ), 𝑖, 𝑡) = 𝑏.
information directly contained in the error message, or distinguish Otherwise, the XS-Leak is not exploitable (denoted by ○␣).
between the appearance and absence of an error message. The test results from XSinator allow us to draw the following
Global Limits. Every computer has its physical limits, so does conclusion: If a certain XS-Leak is only exploitable in some of the
a browser. For example, the amount of available memory limits a tested web browsers, then the underlying leak technique could be
browser’s running tabs. The same holds for other browser limits fixed and will most probably not break existing web applications.
that are enforced for the entire browser. If an attacker can determine This allows us to propose realistic countermeasures to known and
when the limit is reached this can be used as a leak technique. novel XS-Leaks in Section 7.
Global State. Browsers have global states that all pages can
interact with. If this interaction is detectable from an attacker’s 3.2 Evaluation Challenges
website, it can be used as a leak technique. For example, the History The implementation of XSinator was far from being straightforward
interface allows manipulation of the pages visited in a tab or frame. and revealed surprising insights.
 Privileged Events. Some XS-Leaks require specific conditions 4 OVERVIEW OF XS-LEAK ATTACKS
or user interaction. For example, the Frame Count Leak, Web Pay- We conducted a comprehensive analysis of known XS-Leaks. In
ment API Leak, and the WebSocket Leak require a reference to an Table 1, we present our results and show that all of them fit in
opened cross-origin window handle. JavaScript code can only create our formal model. Each known XS-Leak can be described using
this handle with privileged events. For instance, a browser is only 𝑥𝑠𝑙 (𝑠𝑑𝑟, 𝑖, 𝑡) with 𝑖 ∈ 𝐼 and 𝑡 ∈ 𝑇 . In total, there are 5 detectable
allowed to open a pop-up window if the window.open() function differences and 34 XS-Leaks, including a contribution of 14 novel
is triggered by human user interaction. XSinator uses the initial XS-Leaks (+) discussed in Section 5. We use 5 classes of detectable
click on the “Run All Tests” button to initialize the environment as difference to structure this section, since they provide the basic in-
necessary. formation we want to observe through different inclusion methods
Compatibility between Browsers. Since known XS-Leaks are and leak techniques based sidechannels.
often specific to one particular browser, we adapted them to be Full details for the new attacks are provided in Section 5. Details
compatible with as many browsers as possible. If it was not possible for other attacks are given in Appendix A.
to cover all browsers, XSinator implements variants of the same
leak technique. 5 NEW XS-LEAK ATTACKS
Mobile Browsers. The user interfaces of all mobile browsers
restrict the number of visible windows/tabs to one. In all tested Our formal model reveals that every XS-Leak consists of three
browsers except FF Focus, multiple windows/tabs can be opened main ingredients. To systematically identify novel XS-Leaks, we
in the background and are executed in parallel. Therefore, the test henceforth investigated them. First, there are inclusion methods.
suite can be flawlessly executed. In FF Focus XSinator will not The sets of inclusion methods are well-known and mostly static.
execute the test cases requiring a secondary window correctly due Novel XS-Leaks can be especially identified once browser vendors
to the missing functionality. This has a low impact since an attacker implement new features that are leak techniques. Second, there are
would succumb to the same conditions. leak techniques. Novel XS-Leaks are typically found by developing
Different Error Types. Many XS-Leaks distinguish between new leak techniques. In this section, we identified new XS-Leaks
a successful leak technique’s code execution and code execution based on this ingredient. Third, there are detectable differences. We
triggering an error. For this reason, XSinator must distinguish if systematically created tests to extend the set of detectable differences
a triggered error can be interpreted as a XS-Leak test result or a when combined with known leak techniques, which led us to new
runtime error. For example, when comparing SA to Chromium- XS-Leaks.
based browsers, the Web Payment API is implemented differently.
It, therefore, needs custom code adaptation. In contrast, FF does 5.1 Leak Technique: Global Limits
not implement the Web Payment API at all. Therefore it throws WebSocket API. With this new technique, it is possible to identify
different errors, which XSinator must correctly interpret to give if, and how many, WebSocket connections a target page uses. It
accurate results. allows an attacker to detect application states and leak information
tied to the number of WebSocket connections.
Details: The WebSocket API allows the use of streaming connec-
tions between clients and servers using proprietary (e.g., binary)
3.3 Limitations protocols. The client initiates the WebSocket Handshake using
XSinator comes with a few limitations and constraints. HTTPS. Upon success, the established TLS connection is used for
No Automatic Detection of New Variants. XSinator is not tunneling the desired protocol. The specification recommends a lim-
designed to find new attack variants and automatically building new itation of WebSocket connections per client [15]. If one origin uses
XS-Leaks remains an open problem. Although, as we implemented the maximum amount of WebSocket connection objects, regardless
leaks that were thought of to be specific to one browser, we often of their connections state, the creation of new objects will result in
found that they apply to others browser families as well by changing JavaScript exceptions. To execute this attack, the attacker website
the leak technique or inclusion method. opens the target website in a pop-up or iframe and then attempts to
From Browser to Website Evaluation. XSinator is not meant create the maximum number of WebSockets connections possible.
to be an automatic penetration testing tool. We use XSinator to The number of thrown exceptions is the number of WebSocket
systematically evaluate browser implementations against all known connections used by the target website window.
XS-Leaks. Although it cannot automatically detect weaknesses in Example Attack: Slack is a proprietary business communication
real-world websites, developers can run the implemented XS-Leaks platform that offers teams to work together in one workspace. Users
against a specified endpoint. can join one or more workspaces and communicate with other
Excluded XS-Leaks. We had to exclude XS-Leaks that rely on members in real-time. For this purpose, Slack uses WebSockets. We
service workers as they would interfere with other leaks in XSinator. found that by detecting this WebSocket connection, it is possible
Furthermore, we chose to exclude XS-Leaks that rely on misconfig- to leak if a user is a member of a specific workspace.
uration and bugs in a specific web application. For example, Cross- Payment API. This XS-Leak enables an attacker to detect when
Origin Resource Sharing (CORS) misconfigurations, postMessage a cross-origin page initiates a payment request.
leakage [19] or Cross-Site Scripting. Additionally, we excluded time- Details: The Payment Request API enables a website to use the
based XS-Leaks since they often suffer from being slow, noisy and web browser to conduct payments. The user enters their payment
inaccurate. credentials (e.g., credit card information) into the web browser.
 XS-Leak Related Work Leak Technique 𝑡 ∈ 𝑇 Inclusion Method 𝑖 ∈ 𝐼
Detectable Difference: Status Code
+ Perf. API Error (Section 5.2) A request that results in errors will not create a resource timing entry. HTML Elements, Frames
+ Style Reload Error (Section 5.2) Due to a browser bug, requests that result in errors are loaded twice. HTML Elements
+ Request Merging Error (Section 5.2) Requests that result in an error can not be merged. HTML Elements
Event Handler Error Staicu and Pradel [50], Event handlers attached to HTML tags trigger on specific status codes. HTML Elements, Frames
Sudhodanan et al. [51]
MediaError Acar and Danny In FF, it is possible to accurately leak a cross-origin request’s status code. HTML Elements (Video, Audio)
Y. Huang [1]
Detectable Difference: Redirects
+ CORS Error (Section 5.3) In SA CORS error messages leak the full URL of redirects. Fetch API
+ Redirect Start (Section 5.2) Resource timing entry leaks the start time of a redirect. Frames
+ Duration Redirect (Section 5.2) The duration of timing entries is negative when a redirect occurs. Fetch API
Fetch Redirect Janc et al. [30] GC and SA allow to check the response’s type (opaque-redirect) after the redirect Fetch API
is finished.
URL Max Length Masas [38, 39] Gather the length of a URL that triggers an error on a specific server. Fetch API, HTML Elements
Max Redirect Herrera [23] Abuse the redirect limit to detect redirects. Fetch API, Frames
History Length Olejnik et al. [44], Smith JavaScript code manipulates the browser history and can be accessed by the Pop-ups
et al. [47], terjanq [54], length property.
Wondracek et al. [75]
CSP Violation Homakov [27], West [63] The attacker sets up a CSP on attacker.com that only allows requests to Fetch API, Frames
target.com. If attacker.com issues a request to target.com that redirects
to another cross-origin domain, the CSP blocks access and creates a violation
report. Target location of the redirect may leak.
CSP Detection Homakov [27], West [63] Similar to the above leak technique, but the location does not leak. Fetch API, Frames
Detectable Difference: API Usage
+ WebSocket (Section 5.1) Exhausting the WebSocket connection limit leaks the number of WebSocket Frames, Pop-ups
connections of a cross-origin page.
+ Payment API (Section 5.1) Detect Payment Request because only one can be active at a time. Frames, Pop-ups
Service Worker Karami et al. [32] Detect if a service worker is registered for a specific origin. Frames
Detectable Difference: Page Content
+ Perf. API Empty Page (Section 5.2) Empty responses do not create resource timing entries. Frames
+ Perf. API XSS-Auditor (Section 5.2) Detect presence of specific elements in a webpage with the XSS-Auditor in SA. Frames
Cache Vela [59] Clear the file from the cache. Opens target page checks if the file is present in Frames, Pop-ups
the cache.
Frame Count Grossman [18], Masas Read number of frames (window.length). Frames, Pop-ups
[38]
Media Dimensions Masas [38] Read size of embedded media. HTML Elements (Video, Audio)
Media Duration Masas [38] Read duration of embedded media. HTML Elements (Video, Audio)
Id Attribute Heyes [25] Leak sensitive data from the id or name attribute. Frames
CSS Property Evans [13] Detect website styling depending on the status of the user. HTML Elements
Detectable Difference: Header
+ SRI Error (Section 5.3) Subresource Integrity error messages leak the size of a response in SA. Fetch API
+ Perf. API Download (Section 5.2) Downloads do not create resource timing entries in the Performance API. Frames
+ Perf. API CORP (Section 5.2) Resource protected with CORP do not create resource timing entries. Frames
+ COOP (Section 5.4) COOP protected pages can not be accessed. Pop-ups
Perf. API XFO terjanq [55] Resource with X-Frame-Options header does not create resource timing entry. Frames
CSP Directive Yoneuchi [76] CSP header directives can be probed with the CSP iframe attribute. Frames
CORP Wiki [72] Resource protected with CORP throws error when fetched. Fetch API
CORB Wiki [71] Detect presets of Content-Type and Content-Type-Options headers, because HTML Elements
CORB is only enforced for specific content types together with the nosniff
option.
ContentDocument XFO Sudhodanan et al. [51] In GC, when a page is not allowed to be embedded on a cross-origin page Frames
because of X-Frame-Options, an error page is shown.
Download Detection Masas [38] Attacker can detect downloads by using iframes. If the iframe is still accessible, Frames
the file was downloaded.
Table 1: Overview of XS-Leaks attacks sorted by their detectable difference integrated into our formal model. We contribute
novel attack techniques indicated by +.

Afterwards, the website can query the API to request payment. currently using it. The attacker can hide these periodical attempts
The browser then shows a UI pop-up to the user, and the user can by immediately closing the UI after creation. Instead of opening
confirm the purchase with one single click on a button. Similar the UI and then closing it, the browser never shows the UI, and the
to the WebSocket API, the standard specification recommends a user takes no notice of the attack.
global limit of one singular UI element [28]. If the target website is Example Attack: A specific product provided by the website
using the Payment Request API, any further attempts to show this shop.org is advertised on a website, for example, blog.com, using an
UI will be blocked, and cause a JavaScript exception. The attacker affiliate link. The operator of shop.org can use our attack to identify
can exploit this by periodically attempting to show the Payment if a customer bought the product after clicking on provided affiliate
API UI. If one attempt causes an exception, the target website is link.
5.2 Leak Technique: Performance API the target page, by querying the Performance API and checking
We developed new XS-Leak attacks based on the Performance API, for the redirectStart timing data.
which allows an attacker to leak various characteristics of the target • Duration Redirect Leak: In GC, the duration for requests that
page. result in a redirect is negative and can thus be distinguished from
Details: The Performance API is used to access the performance requests that do not result in a redirect.
information of the current page. This includes detailed network • CORP Leak: In some cases, the nextHopProtocol entry can be
timing data for the document and every resource the page loads. used as a leak technique. In GC, when the CORP header is set, the
Terjanq [55] showed how to detect the X-Frame-Options header in nextHopProtocol will be empty. Note that SA will not create a
GC. We used his work as a base to create novel attacks that allow to performance entry at all for CORP-enabled resources.
differentiate between status codes, to detect empty pages, to detect
if the XSS-Auditor is executed, and we improved terjanq’s work to 5.3 Leak Technique: Error Messages
detect X-Frame-Options in non-Chromium-based browsers. The
CORS Error. This technique allows an attacker to leak the target
Performance API specifies that all fetched resources must create a
of a redirect that is initiated by a cross-origin site.
performance entry [29]. We identified cases where browsers will
Details: CORS is used to explicitly allow access between cross-
not create an entry for a specific request. That means an attacker
origin sites that would otherwise be forbidden by the SOP. Access
can differentiate requests by checking if a performance entry is
-Control headers let servers describe which origins are permitted
created. The following 8 new XS-Leak attacks are based on this
to access the response and whether credentials should be included
observation:
with the request. CORS allows publicly accessible web resources to
be read and used from any website. In Webkit-based browsers, it is
• Error Leak: It is possible to differentiate between HTTP re- possible to access CORS error messages when a CORS request fails.
sponse status codes because requests that lead to an error do An attacker can send a CORS-enabled request to a target website
not create a performance entry. This has a similar impact to which redirects based on the user state. When the browser denies
XS-Leak described in Section A.1. We also identified two cases the request, the full URL of the redirect target is leaked in the error
where browser bugs in GC lead to resources being loaded twice message. With this attack, it is possible to detect redirects, leak
when they fail to load. This will result in multiple entries in the redirect locations, and sensitive query parameters.
Performance API and can thus be detected. SRI Error. An attacker can leak the size of cross-origin responses
• Empty Page Leak: An attacker can detect if a request resulted due to verbose error messages.
in an empty HTTP response body because empty pages do not Details: The integrity attribute defines a cryptographic hash
create a performance entry in some browsers. by which the browser can verify that a fetched resource has not
• XSS-Auditor Leak: In SA, it is possible to detect if the XSS- been manipulated. This security mechanism is called Subresource
Auditor was triggered and thus leak sensitive information. The Integrity (SRI) [3]. It is used for integrity verification of resources
XSS-Auditor is a built-in feature of SA and GC (now removed [10]) served from content delivery networks (CDNs). To prevent data
designed to mitigate Cross-Site Scripting (XSS) attacks. It aims leaks, cross-origin resources must be CORS-enabled. Otherwise, the
to protect against reflected XSS by checking query parameters. response is not eligible for integrity validation. Similar to the CORS
In 2013, Braun and Heiderich [7] showed that the XSS-Auditor error XS-Leak, it is possible to catch the error message after a fetch
can be used to block benign scripts with false positives. Based request with an integrity attribute fails. An attacker can forcefully
on their technique, researchers exfiltrate information and detect trigger this error on any request by specifying a bogus hash value.
specific content on a cross-origin page. These XS-Leaks were In SA, this error message leaks the content length of the requested
first described in a bug report by Terada [52] and later in a blog resource. An attacker can use this leak to detect differences in
post by Heyes [24]. However, the discovered techniques applied response size, which enables powerful XS-Leak attacks.
only to the XSS-Auditor in GC and do not work in SA. We found
that blocked pages will not create Performance API entries. That 5.4 Leak Technique Readable Attributes
means an attacker can still leak sensitive information with the COOP. An attacker can leak if the Cross-Origin Opener Policy
XSS-Auditor in SA. (COOP) header is available within an cross-origin HTTP response.
• X-Frame Leak: If a page is not allowed to be rendered in an Details: Web applications can deploy COOP response header to
iframe it does not create a performance entry. As a result, an prevent other websites from gaining arbitrary window references
attacker can detect the response header X-Frame-Options. to the application. However, this header can easily be detected by
• Download Detection: Similar, to the XS-Leak described in Sec- trying to read the contentWindow reference. If a site only deploys
tion A.5, a resource that is downloaded because of the Content- COOP in one state, this property is undefined, otherwise it is defined.
Disposition header, also does not create a performance entry.
This technique works in all major browsers.
• Redirect Start Leak: We found one XS-Leak instance that abuses
the behavior of some browsers which log too much information 6 EVALUATION RESULTS
for cross-origin requests. The standard defines a subset of at- Table 2 shows evaluation results which are automatically generated
tributes that should be set to zero for cross-origin resources. by using XSinator. We used browsers that are available on Browser-
However, in SA it is possible to detect if the user is redirected by Stack in our evaluation. This ensures two aspects. First, the results
 Chrome Edge Firefox Opera Safari Tor Browser

10.0.16 (safer)
10.0.15

10.0.16
46.3.4

46.3.7

81.1.4

75.0.3

3.0.2
89.0

89.0

86.0

90.0

87.0

33.0

60.1

14.0

14.0
XS-Leak
OS ð B  ð B  ð B  ð B  B  ð B B
Detectable Difference: Status Code
Performance API Error ○␣ ○␣ ○ ○ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○ ○ ○␣ ○␣ ○␣
Style Reload Error ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣
Request Merging Error ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣
Event Handler Error ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
MediaError ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Detectable Difference: Redirects
CORS Error Leak ○␣ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○ ○ ○␣ ○␣ ○␣
Redirect Start ○␣ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○ ○ ○␣ ○␣ ○␣
Duration Redirect ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Fetch Redirect ○ ○ ○␣ ○␣ ○ ○␣ ○␣ ○␣ ○␣ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
URL Max Length ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Max Redirect ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
History Length ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣
CSP Violation ○␣ ○␣ ○ ○ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○ ○ ○␣ ○␣ ○␣
CSP Redirect ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣
Detectable Difference: API Usage
WebSocket ○ ○ ○␣ ○ ○ ○␣ ○ ○ ○␣ ○ ○ ○␣ ○␣ ○␣ ○ ○ ○
Payment API ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Detectable Difference: Page Content
Performance API Empty Page ○␣ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○ ○ ○␣ ○␣ ○␣
Performance XSS Auditor ○␣ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○ ○ ○␣ ○␣ ○␣
Cache ○␣ ○␣ ○ ○ ○␣ ○ ○ ○␣ ○ ○ ○␣ ○ ○ ○ ○␣ ○␣ ○␣
Frame Count ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Media Dimensions ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Media Duration ○ ○ ○␣ ○ ○ ○␣ ○ ○ ○␣ ○ ○ ○␣ ○␣ ○␣ ○ ○ ○␣
Id Attribute ○ ○ ○␣ ○ ○ ○␣ ○␣ ○␣ ○␣ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
CSS Property ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Detectable Difference: Header
SRI Error ○␣ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○␣ ○␣ ○ ○ ○ ○␣ ○␣ ○␣
Performance API Download ○ ○ ○␣ ○ ○ ○␣ ○ ○ ○␣ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣
Performance API CORP ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣
COOP Leak ○ ○ ○␣ ○␣ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Performance API XFO ○␣ ○␣ ○ ○ ○␣ ○ ○␣ ○␣ ○ ○ ○␣ ○ ○ ○ ○␣ ○␣ ○␣
CSP Directive ○ ○ ○␣ ○ ○ ○␣ ○␣ ○␣ ○␣ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
CORP ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
CORB ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
ContentDocument XFO ○ ○ ○␣ ○ ○ ○␣ ○␣ ○␣ ○␣ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Download Detection ○ ○ ○␣ ○ ○ ○␣ ○ ○ ○␣ ○ ○ ○ ○ ○ ○ ○ ○
Í
Attackable (max. 34) 22 23 22 24 23 22 14 13 22 24 23 24 24 24 11 11 10

Table 2: Evaluation results overview categorized by its detectable differences. Successful attacks are depicted with full circuits
(○), safe browser are indicated with empty circuits (○␣). The results for Android ð in comparison with Desktop B Browsers are
almost identical, while iOS  browsers behave differently. Only a few XS-Leaks are susceptible to all browsers. More detailed
evaluation tables found in the Appendix, Tables 3 and 4. The used inclusion methods and leak techniques are listed in Table 1.
are generated in a fully automatic fashion; including different op- the Performance API Error XS-Leak does not appear in Chrome
erating systems combined with Selenium for browser automation. engines since version 84. Additionally, some new functionalities
Second, the results can be reproduced by other researchers. We like the Payment API or COOP are only available and exploitable
additionally evaluated Tor using XSinator because of its privacy in the newest browser engines.
goals that are directly targeted with XS-Leaks. More browser re- Our evaluation results in Table 4 show that browsers installed in
sults, including a real-time browser evaluation, are available on iOS behave similarly due to the same underlying browser engine.
XSinator’s website and in the Appendix (Tables 3 and 4). Note that the browser versions do not necessarily match cross
First, we identified clear differences between each browser fam- operating systems. For example, GC 86 was the latest version on iOS
ily, although GC and SA still have certain similarities. On mobile while GC 89 was the latest version on Desktop and Android. Some
devices, it is evident how restricted the iOS browser ecosystem is, iOS browsers do not support downloads and are thus not vulnerable
while browsers on Android often behave just like their desktop to download detection XS-Leaks. The mobile and desktop versions
counterparts. Second, we analyze how vulnerabilities propagate be- of SA behave identically are thus vulnerable to the same XS-Leaks.
tween different browser versions over time. For this, we compared
the results from XSinator for all popular desktop browsers over the 6.2 Patch History
last year, which gave interesting insights into the adoption of new
Table 3 shows the results of popular desktop browsers over time.
features and the effectiveness of security patches.
This timeline provides interesting insights into patch behavior and
how vulnerabilities propagate between different versions. SA only
6.1 Browser Comparison patched the fetch redirect XS-Leak, while support for new features
led to more XS-Leaks. FF fixed the media Error XS-Leak in version
Blink vs. Webkit. On the Desktop, GC 90, MSE 90, and OP 75,
80, and cache partitioning in version 85 mitigated the HTTP cache
which are based on Chromium’s Blink engine, behave equal in our
XS-Leak. Cache portioning was also introduced in Chromium-based
test suite. Moreover, we detected that Blink-based browsers are
browser in version 88. The Chromium developers are actively trying
vulnerable to the fetch redirect XS-Leak. This vulnerability was
to combat XS-Leaks. For example, they addressed the CSP violation
surprising since it was a known bug in SA that was fixed in February
XS-Leak, and two XS-Leaks based on the Performance API. How-
2020 [73]. Blink- and Webkit-based browsers are vulnerable to
ever, we believe that patching the Performance API Error XS-Leak
multiple Performance API XS-Leaks. Although Google developers
in version 84 introduced the Duration Redirect, as it appeared in
have been addressing theses XS-Leaks (cf. Table 3), it is still possible
the same version. This assumption was later confirmed when the
to detect new security headers like the CORP header. In contrast,
bug was closed in version 88 [56].
Webkit-based browsers are still vulnerable to a variety of XS-Leaks
based on the Performance API. XSinator shows the possibility to
detect empty pages and therefore pages that the XSS-Auditor blocks 7 XS-LEAK DEFENSES
in Webkit. In our formal model, an XS-Leak is a function with three inputs:
Desktop Tor vs. Firefox. Two of the main targets of Tor are to (1) a state-dependent resource 𝑠𝑑𝑟 , (2) an inclusion method 𝑖, and
defend surveillance and resist fingerprinting. To verify its resilience (3) a leak technique 𝑡. In this section, we discuss how to mitigate
to XS-Leaks, we used XSinator to evaluate the behavior of Tor in the the XS-Leak threat based on this definition.
default and safer mode. We compared Tor browser (based on FF78) The existence of state-dependent resources cannot be prevented
with FF due to the same underlying browser engine called Gecko. since most web applications (except simple static sites) use them
Tor has more restrictive browser settings; some APIs are not acti- by nature. Mitigations based on a single reported state-dependent
vated because they are explicitly deactivated using Tor browser’s resource, for example, the status code fix of HotCRP reported in
configuration flags. Despite this hardening, our evaluation shows [51], may not fix the problem since typically many state-dependent
that a subset of FF XS-Leaks still works. Regarding XS-Leak attacks, resources exist in a single web application.
Tor’s secure mode is more restrictive than the default mode; for Several new extensions to the HTTP ecosystem have been pro-
example, attackers cannot automatically fingerprint sound and im- posed and implemented recently. For example, Same-Site Cookies
age files due to an activated click-to-play functionality. However, set to the mode lax will prevent protected cookies from being sent,
eleven XS-Leaks like the WebSocket XS-Leak still work in Tor’s if the target web application is embedded in an iframe in a cross-
secure mode. While FF is already quite resistant against XS-Leaks site context. If a pop-up window is used as inclusion method, the
based on the Performance API leak technique, our tests show that Same-Site mode lax is not enough to protect cookies. Such miti-
the Performance API is completely disabled in Tor. This restric- gation approaches have the benefit of being standardized and will
tion drastically limits the attack surface, even for undiscovered most probably work in all modern browsers. However, they may
XS-Leaks. be limited to a subset of the inclusion methods.
Desktop vs. Mobile. We evaluated desktop as well as mobile The basic paradigm behind these mitigations is that only a single
browsers (cf. Table 2). Most android browsers behave almost iden- state 𝑠 0 of the web application can be reached when using a specific
tical regarding XS-Leaks on both platforms when comparing the inclusion method 𝑖. We describe these mitigations in Section 7.1.
same browser engine versions. Given that most Android browsers Our evaluation of XS-Leaks in Section 6 showed that for some
are built on outdated Chromium-based browser engines, XS-Leaks XS-Leaks, only some browsers are vulnerable, and others are not (cf.
are of prime importance. Our results show that an older browser Table 2). This observation gives rise to a new class of countermea-
engine is usually an indicator for older browser bugs. For example, sures – to investigate the differences in browser implementations
and to identify the root cause for non-vulnerability. Browser im- For example, Sec-Fetch-Dest: image was triggered from an im-
plementations which are not vulnerable to the described XS-Leaks age element. Web applications can then choose to block requests
attacks have somehow managed to block the leak technique 𝑡 used based on that information.
in the attack; regardless of the inclusion method used. We describe Same-Site Cookies. The Same-Site cookie flag allows websites
these mitigations in Section 7.2. to declare whether a cookie should be restricted to same-site or first-
party context. All major browsers support Same-Site cookies. In GC,
cookies without the attribute are now Lax by default. For XS-Leaks,
7.1 Inclusion Method Mitigations Same-Site cookies drastically limit the leak attack possibilities. On
Inclusion methods enable an attacker to trigger cross-origin re- the other hand, leak techniques that rely on window.open still
quests on a specified state-dependent resource. To mitigate XS- work with SameSite=Lax. Websites that use other authentication
Leaks on the inclusion method level, there are two possibilities. methods, such as client-side certificates and HTTP authentication,
First, cross-origin requests can be allowed but they do not result in remain vulnerable.
a detectable difference. Second, cross-origin requests can be denied Cross-Origin Identifier Unlinkability (COIU). COIU, also
under specific circumstances. known as First-Party Isolation (FPI), is an optional security feature
HTML elements. In the case of XS-Leaks requesting resources, that users can enable in FF’s expert settings (about:config) and
a web application can apply different mitigations. It can use the was initially introduced in Tor Browser. In an abstract view, it is an
CORP header to control if pages can embed a resource [66]. CORP extended same-site context. It binds multiple resources (e.g., Cook-
can either be set to same-origin or same-site and blocks any ies, Cache, Client-side storages) to the first-party instead of sharing
cross-origin respectively cross-site requests to that resource. them among all visited websites. If enabled, COIU drastically de-
On the client site, Chromium-based browsers use the CORB creases the applicability of XS-Leaks, since only methods using
algorithm to decide whether cross-origin resource requests should pop-ups are still possible to fit the policy’s first-party requirement.
be allowed or denied. CORB was primarily implemented to protect Tracking Protections. Apple implemented a privacy mecha-
against side-channel attacks such as Spectre [35], but it mitigates nism called Intelligent Tracking Prevention (ITP) in SA that aims
XS-Leak inclusion methods in addition. For example, it protects to combat cross-site tracking by limiting the capabilities of cookies
HTML, XML, and JSON files by blocking requests such as <img and other web APIs [4]. In newer versions of SA, ITP blocks all
src="http://target.com/">. third-party cookies by default without any exceptions [74]. This
Frames. The main defense to prevent iframe elements from load- blocking prevents all leaks that are not based on pop-ups. FF took
ing HTML resources is the usage of X-Frame-Options. This HTTP a similar approach with Enhanced Tracking Prevention (ETP), but
response header indicates whether a browser is allowed to embed they only block specific third-party cookies belonging to track-
a document. For example, X-Frame-Options: DENY mitigates any ing providers. In the context of XS-Leaks, ETP only mitigates leak
XS-Leak which relies on iframe, objects, or embed elements. Alter- techniques that target these tracking domains.
natively, the CSP directive frame-ancestors can achieve a similar Browser Extensions. Security aware users can use browser
result [61]. If the embedding is denied, the inclusion method cannot extensions to prevent certain inclusion methods. Since numerous
detect a difference in the responses. extensions allow controlling a browser’s HTTP requests, we discuss
Pop-ups. Inclusion methods that use pop-ups are more difficult this prevention by the example of uBlock Origin (UBO), one of the
to handle because a specific HTML element do not trigger them most prominent wide spectrum blockers.
and HTTP response headers such as X-Frame-Options do not apply. UBO provides three [26] blocking modes, which we evaluated
For restricting the access to window.opener, the COOP HTTP re- using XSinator in GC. UBO uses the easy mode in its default in-
sponse header defines three different values: unsafe-none (default), stallation and only blocks advertisements based on URL patterns.
same-origin-allow-popups, and same-origin. These values can When running UBO on XSinator, it does not block a single request
be used to isolate browsing tabs and pop-ups and thus, mitigates and henceforth does not prevent any XS-Leak. In the medium mode,
leak techniques based on pop-ups. UBO blocks third-party frames and third-party scripts globally.
JavaScript Requests. Cross-origin JavaScript requests are of- This block prevents all XS-Leaks relying on inclusion methods that
ten used in XS-Leak attacks, because an attacker has fine-grained use HTML elements. In UBO’s hard mode, it blocks all third-party
control over the issued request. However, since these request are resources. Every HTTP resource that does not belong to the first-
not CORS enabled they fall under the same restrictions as requests party must be manually enabled. This blocking prevents XS-Leaks
send by HTML elements, like scripts or images. Thus the impact of that rely on inclusion methods using JavaScript requests or other
this leak technique can also be mitigated by CORP and CORB. HTML tags (e.g., link), leaving only pop-up based XS-Leaks as still
working. To prevent them, users can configure UBO to globally
disable pop-ups.
Generic Request Policies. In the following discussion, we shed light
on browser features that help on a generic level to mitigate XS-
Leaks on multiple inclusion methods. 7.2 Leak Technique Mitigations
Fetch Metadata. These request headers allow server owners to XS-Leaks use various leak techniques for exploitation. We identified
understand better how the user’s browser caused a specific request. various XS-Leaks that only work in some browsers, while others
In Chrome, Sec-Fetch-* headers are automatically added to each are immune. In the following, we discuss mitigations that are based
request and provide metadata about the request’s provenance [65]. on the leak technique level.
 Event Handler. The most prominent leak technique for XS-Leak 8 RELATED WORK
is probably the event handler because event messages contained Our work relates to research of four different categories that we
in the trigger are a rich source of information (cf. Sudhodanan elaborate in the following. An overview of known XS-Leaks is
et al. [51]). The most effective mitigation on this leak technique depicted in Table 1 in Section 4.
would be to deny them all, but this would break the majority of web XS-Leak Attacks. Recently, Sudhodanan et al. [51] systemati-
applications on the Internet. We therefore propose to reduce the cally summarized prior work on XS-Leaks and presented how they
number of the necessary information that can be gathered within can be used to infer state information from a cross-origin web ap-
events. For example, the CSP violation event should not contain the plication. The authors implemented a crawler-based attack vector
redirection target URL in the blockedURI field. This behavior is generation tool for websites called BASTA-COSI. We considered
implemented in FF and in newer versions of GC – only SA remains their XS-Leaks in our work. While the authors showcased success-
vulnerable. ful attacks on various websites, we contribute a comprehensive test
Error Messages. To mitigate XS-Leaks based on the leak tech- suite for browsers and an extensive evaluation thereof. They did
nique error messages, there are two major requirements. First, error not consider a formal model of XS-Leaks.
messages must not contain detailed information, similarly to event Lee et al. [36] created XS-Leaks which use crafted AppCache
handler messages. For example, the MediaError and CORS error manifest to leak redirections in state-dependent resources. Simi-
XS-Leak abuses details provided in the error message, such as the larly, Eriksson and Sabelfeld [12] explore XS-Leak to detect redi-
HTTP response status code. Second, browsers must minimize error rects with the new navigate-to CSP directive. In 2015 Lekies et al.
message occurrences. XS-Leaks such as SRI Error, ContentDocu- [37] showed how the cross-origin inclusion of dynamically gener-
ment XFO, or Fetch Redirect detect whether an error message is ated JavaScript poses the risk of leaking sensitive information like
thrown or not. For example, GC could mimic the behavior of FF usernames and passwords. They focused on websites and did not
and SA, that is, they do not throw an error at all in these particular evaluate the behavior of different browsers. In 2018 Acar et al. [2]
cases. presented how attacker sites can attack IoT devices on the victim’s
Global Limits. Fixing leak techniques that abuse global limits LAN via a Media Error XS-Leak. Gulyas et al. [20] showed how
are relatively complex because they rely on physical restrictions. XS-Leaks on login pages can be used for browser fingerprint web
For example, the maximum number of available TCP connections browsers. In 2019 Staicu and Pradel [50] showed how accounts
cannot be changed. The general recommendation thereby is to re- on file sharing platforms can be uniquely identified by granting
strict global limits on a small per-site basis. The WebSocket API sole access rights to an image to a sole user and including it in the
XS-Leak leverages the shared limit of concurrent WebSocket con- attacker website.
nections; FF has a global limit of 200 connections. Upon exhausting In Bortz and Boneh [6] analyzed cross-site timing attacks, in
this limit, new connections result in JavaScript exceptions. A partial which the time a site takes to respond to a cross-site request could
mitigation is to change this limit from a global to a per-site limit, be used as leak technique. In 2009 Chris Evans [9] was the first
possibly with a small randomized value. The global limit for the described the concept of cross-site search attacks based on timing
Payment API is one, that is, the attacker can silently attempt to attacks. Gelernter and Herzberg [16] improved their work with
activate the WebPayment UI at any time, which only succeeds if the attacks based on statistical tests, algorithms, and some application-
UI is not being used concurrently by any other tab. We recommend specific behaviors in 2015. Van Goethem et al. [57, 58] reiterated the
to only access to the Payment API when a trustworthy event [43] feasibility of fast and precise timing side-channel attacks utilizing
was used. By this means, the global limit is set to zero unless the HTML5 features to leak size, type, and transmission speed of cross-
user provides consent like a left mouse click on a dialog window, origin web resources.
which sets the global limit to one. Browser Security. In 2017 two white papers by Heiderich et al.
Global State. Any properties of a browser’s global state should [22] and Vervier et al. [60] summarized the recent threats to browser
not be accessible. For example, FF is the only browser that updates users. In 2019 Mirheidari et al. [41] showed how Web Cache Decep-
the global state history when a redirect occurs, which results in tion (WCD) can lead to caches exposing sensitive data. In 2020 Janc
reading history.length. Browsers should create a new history and West [31] discuss their plans to remove unsafe features and be-
property when a redirection occurs instead of storing it globally. haviors from the web platform. Calzavara et al. [8] highlighted how
Other examples are shared resources, such as caches. Cache leaks inconsistent framing policies of websites in the wild can impede
abuse the shared cache used for all open websites in a browser. browser security. Narayan et al. [42] proposed changes to the Fire-
To completely mitigate cache leak techniques, the HTTP cache fox source code to mitigate binary exploitation through web-served
must be partitioned on a per-site base, as implemented by SA, GC passive media, an orthogonal threat besides XS-Leak. Karami et al.
and FF [34]. Note that in SA iframes are not effected by cache [33] researched how browser extensions can be fingerprinted by
partitioning. enumeration of its Web Accessible Resources (WARs) and behavior.
Performance API. We proved the Performance API to be an Roth et al. [45] revealed the challenges posed to website maintain-
excellent leak technique. In many XS-Leaks, we could detect the ers by the complex and ever-developing Content Security Policy
difference whether a cross-origin request’s response has or has not (CSP).
a performance entry. As a unification, we recommend ensuring that Online Evaluation Test Suites Schwenk et al. [46] provided
all request must create such an entry and only the correct subset of a test suite for stress-testing the SOP. The tabular presentation
timing information is recorded for cross-origin requests. of historical data collected across different browsers allows to
quickly identify outliers. We used their concept as a basis for REFERENCES
XSinator. As a collection of test suites for testing browsers based [1] Gunes Acar and Frank Li of UC Berkeley Danny Y. Huang, Princeton University.
on W3C/WHATWG specifications, Web Platform Tests [49] can be 2018. MediaError message property leaks cross-origin response status. https:
//bugs.chromium.org/p/chromium/issues/detail?id=828265. (April 2018).
used. [2] Gunes Acar, Danny Yuxing Huang, Frank Li, Arvind Narayanan, and Nick
Formal Models. In 2005 Gross et al. [17] formally model a web Feamster. 2018. Web-Based Attacks to Discover and Control Local IoT De-
vices. In Proceedings of the 2018 Workshop on IoT Security and Privacy (IoT
browser for the purpose of analyzing browser-based protocols. In S&P ’18). Association for Computing Machinery, New York, NY, USA, 29–35.
2014 Fett et al. [14] formalized an expressive model of the Web https://doi.org/10.1145/3229565.3229568
Infrastructure based a model for public key cryptography by Dolev [3] Devdatta Akhawe, Frederik Braun, Francois Marier, and Joel Wein-
berger. 2016. Subresource Integrity. W3C Recommendation. W3C.
and Yao [11]. In 2017 Schwenk et al. [46] published a formal model https://www.w3.org/TR/2016/REC-SRI-20160623/.
for the SOP and systematically analyzed and highlighted problem- [4] Apple. 2019. Safari Privacy Overview. https://www.apple.com/safari/docs/
atic differences between implementations across browser families. Safari_White_Paper_Nov_2019.pdf. (November 2019).
[5] A. Barth. 2011. The Web Origin Concept. RFC 6454. IETF. http://tools.ietf .org/
Our proposed model takes the SOP into consideration as an impor- rfc/rfc6454.txt
tant factor in the context of XS-Leaks, as it is more concise and [6] Andrew Bortz and Dan Boneh. 2007. Exposing Private Information by Timing
Web Applications. In Proceedings of the 16th International Conference on World
applicable than the general formalization of a whole web browser. Wide Web (WWW ’07). Association for Computing Machinery, New York, NY,
USA, 621–628. https://doi.org/10.1145/1242572.1242656
[7] Frederik Braun and Mario Heiderich. 2013. X-frame-options: All about clickjack-
9 CONCLUDING REMARKS ing. (2013). https://cure53.de/xfo-clickjacking.pdf
In this paper, we proposed a formal model for XS-Leaks. This model [8] Stefano Calzavara, Sebastian Roth, Alvise Rabitti, Michael Backes, and Ben
Stock. 2020. A Tale of Two Headers: A Formal Analysis of Inconsistent Click-
fits all previously published results. By identifying the three ingre- Jacking Protection on the Web. In 29th USENIX Security Symposium (USENIX
dients of an XS-Leak, which are the detectable difference 𝐷, inclusion Security 20). USENIX Association, 683–697. https://www.usenix.org/conference/
usenixsecurity20/presentation/calzavara
method 𝑖 and leak technique 𝑡, we were able to gain novel in-depth [9] Chris Evans. 2009. Cross-domain search timing. (2009). https://
insights and systematically produce new attacks. (1) To detect a scarybeastsecurity.blogspot.com/2009/12/cross-domain-search-timing.html
difference 𝐷, different inclusion methods 𝑖 and leak techniques 𝑡 [10] Chrome Platform Status. 2020. XSS Auditor (removed). https://
www.chromestatus.com/feature/5021976655560704. (June 2020).
can be used. This yields a systematic way for detecting 14 new [11] D. Dolev and A. Yao. 1983. On the security of public key protocols. IEEE
XS-Leaks. (2) Our evaluation of existing browser/OS combinations Transactions on Information Theory 29, 2 (1983), 198–208. https://doi.org/10.1109/
with XSinator showed that non-vulnerable browser implementa- TIT.1983.1056650
[12] Benjamin Eriksson and Andrei Sabelfeld. 2020. Autonav: Evaluation and automa-
tions for each class of XS-Leak exist (except in 5 cases). (3) This tization of web navigation policies. In Proceedings of The Web Conference 2020.
finding allowed us to investigate a new class of XS-Leak mitiga- 1320–1331.
[13] Chris Evans. 2008. Cross-domain leaks of site logins. https:
tions that target the used leak techniques. Our results show that a //scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-
small, dedicated formal model may help to develop a more thorough logins.html. (August 2008).
understanding of web attacks. [14] Daniel Fett, Ralf Kuesters, and Guido Schmitz. 2014. An Expressive Model for the
Web Infrastructure: Definition and Application to the BrowserID SSO System.
Future Work. While the set 𝐼 of inclusion methods is relatively (2014). arXiv:cs.CR/1403.1866
static, new web technologies may introduce novel detectable dif- [15] I. Fette and A. Melnikov. 2011. The WebSocket Protocol. RFC 6455. IETF. http:
ferences, and novel leak techniques. Our contributed formal model //tools.ietf .org/rfc/rfc6455.txt
[16] Nethanel Gelernter and Amir Herzberg. 2015. Cross-site search attacks. In
provides a clear methodology to check such novel technologies Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications
for possible XS-Leaks. A similar observation holds for the miti- Security. ACM, 1394–1405.
[17] Thomas Gross, Birgit Pfitzmann, and Ahmad-Reza Sadeghi. 2005. Browser Model
gations. The inclusion method-based countermeasures should be for Security Analysis of Browser-Based Protocols. IACR Cryptology ePrint Archive
re-evaluated once new inclusion methods are defined, and browser 2005, 127. https://doi.org/10.1007/11555827_28
implementations need to be constantly re-evaluated once their [18] Jeremiah Grossman. 2012. I Know What Websites You Are Logged-In To
(Login-Detection via CSRF). http://blog.whitehatsec.com/i-know-what
functionality is enhanced. Moreover, we think that the community -websites-you-are-logged-in-to-login-detection-via-csrf/. (October
could benefit from an evaluation whether fixes against XS-Leaks 2012).
can be done without interfering with Web functionality. However, [19] Chong Guan, Kun Sun, Zhan Wang, and WenTao Zhu. 2016. Privacy breach by ex-
ploiting postmessage in html5: Identification, evaluation, and countermeasure. In
crawling sites would probably yield only incomplete data, since Proceedings of the 11th ACM on Asia Conference on Computer and Communications
many sites hide their functionalities behind logins or on sub-sites. Security. 629–640.
Therefore, it would be a difficult but commendable future work to [20] Gabor Gyorgy Gulyas, Doliere Francis Some, Nataliia Bielova, and Claude Castel-
luccia. 2018. To extend or not to extend: on the uniqueness of browser extensions
look on web applications, identify their states, and solve session and web logins. In Proceedings of the 2018 Workshop on Privacy in the Electronic
management problems. Society. 14–27.
[21] Mario Heiderich. 2020. HTTPLeaks. https://github.com/cure53/HTTPLeaks.
(June 2020).
ACKNOWLEDGEMENTS [22] Mario Heiderich, Alex Inführ, Fabian Fäßler, Nikolei Krein, Masato Kinugawa,
Tsang-Chi Hong, Dario Weißler, and Paula Pustulka. 2017. Cure53’s Browser Se-
Funded by the Deutsche Forschungsgemeinschaft (DFG, German curity White Paper. (2017). https://raw.githubusercontent.com/cure53/browser-
Research Foundation) under Germany’s Excellence Strategy - EXC sec-whitepaper/master/browser-security-whitepaper.pdf
[23] Luan Herrera. 2020. XS-Leaks in redirect flows. https://docs.google.com/
2092 CASA - 390781972. Lukas Knittel was supported by the Ger- presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og.
man Federal Ministry of Economics and Technology (BMWi) project (January 2020).
[24] Gareth Heyes. 2015. Abusing Chrome’s XSS auditor to steal tokens. https:
“Industrie 4.0 Recht-Testbed” (13I40V002C). Dominik Noss was sup- //portswigger.net/research/abusing-chromes-xss-auditor-to-steal-tokens. (Au-
ported by the research project “MITSicherheit.NRW” funded by gust 2015).
the European Regional Development Fund North Rhine-Westphalia [25] Gareth Heyes. 2019. XS-Leak: Leaking IDs using focus. https://portswigger.net/
research/xs-leak-leaking-ids-using-focus. (October 2019).
(EFRE.NRW).
[26] Raymond Hill. 2020. Blocking mode uBlock Wiki. https://github.com/gorhill/ [51] Avinash Sudhodanan, Soheil Khodayari, and Juan Caballero. 2020. Cross-Origin
uBlock/wiki/Blocking-mode. (October 2020). State Inference (COSI) Attacks: Leaking Web Site States through XS-Leaks. In
[27] Egor Homakov. 2013. Disclose domain of redirect destination taking adven- 27nd Network and Distributed System Security Symposium (NDSS 20).
tadge of CSP. https://bugs.chromium.org/p/chromium/issues/detail?id=313737. [52] Takeshi Terada. 2014. Security: XSS filter information leak. https://
(October 2013). bugs.chromium.org/p/chromium/issues/detail?id=396544. (July 2014).
[28] Ian Jacobs, Zach Koch, Domenic Denicola, Roy McElmurry, Rouslan Solomakhin, [53] Terjanq. 2019. Mass XS-Search using Cache Attack. https://medium.com/
and Marcos Caceres. 2019. Payment Request API. Candidate Recommenda- @terjanq/massive-xs-search-over-multiple-google-products-416e50dd2ec6. (No-
tion. W3C. https://www.w3.org/TR/2019/CR-payment-request-20191212/#show- vember 2019).
method. [54] terjanq. 2019. Protected tweets exposure through the URL. https://
[29] Arvind Jain, Zhiheng Wang, Anderson Quach, Jatinder Mann, and Todd hackerone.com/reports/491473. (April 2019).
Reifsteck. 2017. Resource Timing Level 1. Candidate Recommendation. [55] terjanq. 2019. Twitter: Detect X-Frame-Options header in Chrome. https://
W3C. https://www.w3.org/TR/2017/CR-resource-timing-1-20170330/#resources- twitter.com/terjanq/status/1111600071014080517. (March 2019).
included. [56] terjanq. 2020. Issue 1157818: performance API reveals information about redirects
[30] Artur Janc, Krzysztof Kotowicz, Lukas Weichselbaum, and Roberto Clapis. 2020. (XS-Leak). https://crbug.com/1157818. (December 2020).
Information Leaks via Safari’s Intelligent Tracking Prevention. https://arxiv.org/ [57] Tom Van Goethem, Wouter Joosen, and Nick Nikiforakis. 2015. The clock is
abs/2001.07421. (January 2020). still ticking: Timing attacks in the modern web. In Proceedings of the 22nd ACM
[31] Artur Janc and Mike West. 2020. Oh, the Places You’ll Go! Finding Our Way Back SIGSAC Conference on Computer and Communications Security. ACM, 1382–1393.
from the Web Platform’s Ill-conceived Jaunts. In 2020 IEEE European Symposium [58] Tom Van Goethem, Christina Pöpper, Wouter Joosen, and Mathy Vanhoef. 2020.
on Security and Privacy Workshops (EuroS&PW). IEEE, 673–680. Timeless timing attacks: Exploiting concurrency to leak secrets over remote
[32] Soroush Karami, Panagiotis Ilia, and Jason Polakis. 2021. Awakening the Web’s connections. In 29th {USENIX } Security Symposium ( {USENIX } Security 20).
Sleeper Agents: Misusing Service Workers for Privacy Leakage. In Network and 1985–2002.
Distributed System Security Symposium (NDSS). [59] Eduardo Vela. 2019. HTTP Cache Cross-Site Leaks. http:
[33] Soroush Karami, Panagiotis Ilia, Konstantinos Solomos, and Jason Polakis. 2020. //sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html. (March
Carnus: Exploring the Privacy Threats of Browser Extension Fingerprinting. In 2019).
27th Annual Network and Distributed System Security Symposium, NDSS 2020, San [60] Markus Vervier, Michele Orrù, Berend-Jan Wever, and Eric Sesterhenn. 2017.
Diego, California, USA, February 23-26, 2020. The Internet Society. Cure53’s Browser Security White Paper. (2017). https://browser-security.x41-
[34] Eiji Kitamura. 2020. Gaining security and privacy by partitioning the cache. https: dsec.de/X41-Browser-Security-White-Paper.pdf
//developers.google.com/web/updates/2020/10/http-cache-partitioning. (Octo- [61] MDN web docs. 2019. CSP: frame-ancestors. https://developer.mozilla.org/en-US/
ber 2020). docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors. (November
[35] Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner 2019).
Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, et al. 2019. [62] MDN web docs. 2020. Web APIs: History. https://developer.mozilla.org/en-
Spectre attacks: Exploiting speculative execution. In 2019 IEEE Symposium on US/docs/Web/API/History. (February 2020).
Security and Privacy (SP). IEEE, 1–19. [63] Mike West. 2013. Cross-origin leakage with securitypolicyviolation events
[36] Sangho Lee, Hyungsub Kim, and Jong Kim. 2015. Identifying Cross-origin Re- and paths in source expressions. https://lists.w3.org/Archives/Public/public-
source Status Using Application Cache. In 22nd Network and Distributed System webappsec/2013May/0022.html. (May 2013).
Security Symposium (NDSS 2015). https://www.microsoft.com/en-us/research/ [64] Mike West. 2018. Content Security Policy Level 3. W3C Working Draft. W3C.
publication/identifying-cross-origin-resource-status-using-application-cache/ https://www.w3.org/TR/2018/WD-CSP3-20181015/.
[37] Sebastian Lekies, Ben Stock, Martin Wentzel, and Martin Johns. 2015. The [65] Mike West. 2020. Fetch Metadata Request Headers. https://w3c.github.io/
Unexpected Dangers of Dynamic JavaScript. In 24th USENIX Security Symposium webappsec-fetch-metadata/. (April 2020).
(USENIX Security 15). 723–735. https://publications.cispa.saarland/987/ pub_id: [66] Web Hypertext Application Technology Working Group (WHATWG). 2020.
1055 Bibtex: lekies2015unexpected URL date: None. Fetch - Living Standard: Cross-Origin-Resource-Policy header. https://
[38] Ron Masas. 2019. Browser Side Channels. https://github.com/xsleaks/xsleaks/ fetch.spec.whatwg.org/#cross-origin-resource-policy-header. (August 2020).
wiki/Browser-Side-Channels. (September 2019). [67] Web Hypertext Application Technology Working Group (WHATWG). 2020. Fetch
[39] Ron Masas. 2019. Server Side Redirect Detection. https://xsleaks.github.io/ - Living Standard: HTTP-redirect fetch. https://fetch.spec.whatwg.org/#http-
xsleaks/examples/redirect/. (September 2019). redirect-fetch. (August 2020).
[40] MDN web docs. 2020. Fetch API. https://developer.mozilla.org/en-US/docs/Web/ [68] Web Hypertext Application Technology Working Group (WHATWG). 2020. Fetch
API/Fetch_API. (June 2020). - Living Standard: Requests. https://fetch.spec.whatwg.org/#requests. (August
[41] Seyed Mirheidari, Sajjad Arshad, Kaan Onarlioglu, Bruno Crispo, Engin Kirda, 2020).
and William Robertson. 2019. Cached and Confused: Web Cache Deception in [69] Web Hypertext Application Technology Working Group (WHATWG). 2020.
the Wild. (12 2019). HTML - Living Standard: contentDocument. https://html.spec.whatwg.org/
[42] Shravan Narayan, Craig Disselkoen, Tal Garfinkel, Nathan Froyd, Eric Rahm, multipage/iframe-embed-object.html#dom-iframe-contentdocument. (August
Sorin Lerner, Hovav Shacham, and Deian Stefan. 2020. Retrofitting Fine Grain 2020).
Isolation in the Firefox Renderer. In 29th USENIX Security Symposium (USENIX [70] Web Hypertext Application Technology Working Group (WHATWG).
Security 20). USENIX Association, 699–716. https://www.usenix.org/conference/ 2020. HTML - Living Standard: Navigating to a fragment. https:
usenixsecurity20/presentation/narayan //html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-fragid.
[43] Marcus Niemietz and Jörg Schwenk. 2018. Out of the Dark: UI Redressing and (August 2020).
Trustworthy Events. In Cryptology and Network Security, Srdjan Capkun and [71] XS-Leaks Wiki. 2020. CORB Leaks. https://xsleaks.com/docs/attacks/browser-
Sherman S. M. Chow (Eds.). Springer International Publishing, Cham, 229–249. features/corb/. (October 2020).
[44] Lukasz Olejnik, Claude Castelluccia, and Artur Janc. 2012. Why johnny can’t [72] XS-Leaks Wiki. 2020. CORP Leaks. https://xsleaks.com/docs/attacks/browser-
browse in peace: On the uniqueness of web browsing history patterns. In 5th features/corp/. (October 2020).
Workshop on Hot Topics in Privacy Enhancing Technologies (HotPETs 2012). [73] John Wilander. 2019. Preventing Tracking Prevention Tracking. https:
[45] S. Roth, Timothy Barron, S. Calzavara, Nick Nikiforakis, and Ben Stock. 2020. //webkit.org/blog/9661/preventing-tracking-prevention-tracking/. (December
Complex Security Policy? A Longitudinal Analysis of Deployed Content Security 2019).
Policies. In NDSS. [74] John Wilander. 2020. Full Third-Party Cookie Blocking and More. https:
[46] Jörg Schwenk, Marcus Niemietz, and Christian Mainka. 2017. Same-origin policy: //webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/. (March
Evaluation in modern browsers. In 26th USENIX Security Symposium (USENIX 2020).
Security 17). 713–727. [75] Gilbert Wondracek, Thorsten Holz, Engin Kirda, and Christopher Kruegel. 2010.
[47] Michael Smith, Craig Disselkoen, Shravan Narayan, Fraser Brown, and Deian A practical attack to de-anonymize social network users. In 2010 IEEE Symposium
Stefan. 2018. Browser history re: visited. In 12th USENIX Workshop on Offensive on Security and Privacy. IEEE, 223–238.
Technologies (WOOT 18). [76] Takashi Yoneuchi. 2019. XS-Leak with Resource Timing API and CSP Embedded
[48] Jungkee Song, Alex Russell, Marijn Kruisselbrink, and Jake Archibald. Enforcement. https://crbug.com/1105875. (July 2019).
2019. Service Workers 1. Candidate Recommendation. W3C.
https://www.w3.org/TR/2019/CR-service-workers-1-20191119/.
[49] Web Platform Tests / Open Source. 2021. Web Platform Tests Github Page. (2021).
https://github.com/web-platform-tests/wpt
[50] Cristian-Alexandru Staicu and Michael Pradel. 2019. Leaky images: targeted
privacy attacks in the web. In 28th USENIX Security Symposium (USENIX Security
19). 923–939.
A OVERVIEW OF XS-LEAK ATTACKS can be abused to detect the number of redirects of a cross-origin
resource. For example, an attacker can redirect nineteen times
A.1 Detectable Difference: Status Code
before redirecting to the target site that may potentially redirect. If
An attacker is able to distinguish different HTTP response status it redirects, an error is triggered that can then be detected by the
codes to detect server errors, client errors, authentication errors, or attacker page.
server redirects cross-origin. History Length. The History API allows JavaScript code to
Leak Technique: Event Handler. Event handlers can be at- manipulate the browser history, which saves the pages visited by a
tached to an HTML tag which includes a cross-origin resource. user [62]. An attacker can use the length property as an inclusion
Depending on the status code, content-type, and other response method: to detect JavaScript and HTML navigation. Multiple works
headers, different events handlers are triggered (e.g., onload or have studied the browser history and show how to abuse it to
onerror) [50, 51]. By using event handler as a leak technique, an determine whether a user has accessed a certain website [44, 47,
attacker is allowed to detect the presence of headers, HTTP errors, 54, 75].
and media types. CSP Violation. An XS-Leak can use the CSP [64] to detect if a
Leak Technique: MediaError. In FF, it is possible to accurately cross-origin site was redirected to a different origin. This leak can
leak a cross-origin request’s status code by using an error message detect the redirect, but additionally, the domain of the redirect target
leak technique generated by a video or audio element as inclusion leaks. These techniques were discussed by West [63] and Homakov
methods. [27]. The basic idea of this attack is to allow the target domain on
the attacker site. Once a request is issued to the target domain, it
A.2 Detectable Difference: API Usage redirects to a cross-origin domain. CSP blocks the access to it and
An attacker is able to detect the usage of Web APIs cross-origin. creates a violation report used as a leak technique. Depending on
Service Worker. Service workers are event-driven script con- the browser, this report may leak the target location of the redirect.
texts that run at an origin [48]. They run in the background of a CSP Detection. Newer browsers do not leak the target location
web page and can intercept, modify, and cache resources to create of the redirect in the violation report. However it is still possible
offline web application. Karami et al. [32] introduced leak tech- to detect if a cross-origin redirect occurred, because the request is
niques to detect if a service worker is registered for a specific origin. still blocked by the CSP, i.e., the violation report can be used as a
They used iframes as an inclusion method on resources that have leak technique.
previously been cached by a service worker.
A.4 Detectable Difference: Page Content
A.3 Detectable Difference: Redirects An attacker can detect content in HTML documents or resources.
It is possible to detect if a web application has navigated the user to The detection includes HTML attributes, embedded resources, and
a different page. This is not limited to HTTP redirects but redirects CSS rules.
triggered by JavaScript or HTML code can also be detected. Cache. For avoiding unnecessary data transfers and server re-
Fetch Redirect. The Fetch API provides an interface for fetching quests, browsers implement HTTP caching to increase performance
resources by using JavaScript code. The API allows various config- when loading web pages. Vela [59] discovered that most browsers
uration options. One of these options is the redirect mode [68]. If use one shared cache for all websites. Regardless of their origin, it
it is set to manual, redirects are not automatically followed. Based is possible to deduct whether a target page has requested a specific
on the discussion of Janc et al. [30], browsers like GC and SA allow file. To detect this request, the attacker page executes the following
the attacker to check the response’s type as a leak technique after leak technique it clears the file from the cache, it opens the target
the redirect is finished. page in a pop-up or iframe, and finally, it checks if the file is present
URL Max Length. Web applications may not adequately handle in the cache again.
long URLs. Usually, web servers reject a request when the URL Frame Count. HTML iframe elements can be used to embed
exceeds a specific limit and return an error with status code 414 other documents within the current one. Developers use them to
URI Too Long or 413 Payload Too Large. Modern browsers can isolate third-party content or to include widgets and advertisements.
typically handle longer URLs, although 2 megabytes are a common Although JavaScript APIs only allow limited access to cross-origin
limit. If a web application redirects, it may try to preserve any window objects, the number of frames on a page can still be read. As
query parameters that are attached to the original request (e.g., as shown by Grossman [18] and Masas [38], an attacker can use this
implemented by twitter.com). Additionally, the URL length may length to detect state differences if the number of frames changes
increase in size when a redirect occurs. By considering a global limit between them. A target web page may include a different number
as a leak technique, an attacker can consequently craft a request of frames depending on the user state. With readable attributes as
that exceeds the server’s URL character limit to trigger an error a leak technique, properties like length help an attacker to leak
once redirected. As an example, Masas [38, 39] showed how an the frame number if it is possible to obtain a window handle to the
attacker could gather the length of a URL that triggers an error on target. A window handle can be obtained by the following inclusion
a specific server to be used within an XS-Leak. methods: embedding the target page in an iframe or by opening a
Max Redirect Browsers try to prevent infinite redirect loops. pop-up using window.open.
The Fetch standard specifies that after twenty redirects a network Media Dimensions. Media elements, such as video and image,
error should be returned [67]. Herrera [23] showed that this limit can sometimes differ in size. Web applications may dynamically
generate media files depending on user information or add water- This allows an attacker to detect specific CSP directive of a cross-
marks that change media size. An attacker can use standard DOM origin page, if it is possible to detect the error page. This leak was
APIs to detect these differences [38]. For example, media resources reported to GC by Takashi Yoneuchi [76]. Although, this bug is now
can be embedded cross-origin with <video> or <img> HTML tags marked as fixed, we found a new leak technique that can detect the
and properties such as the dimensions for image elements can be error page, because the underlying problem was never fixed.
read. CORP. The CORP header is a relatively new web platform secu-
Media Duration. Similarly, the duration of audio and video rity feature that when set blocks no-cors cross-origin requests to
elements can be read cross-origin. the given resource (cf. Section 7). The presence of the header can
Id Attribute. Hyperlinks are often used to link to specific parts be detected, because a resource protected with CORP will throw
of a document, and browsers will automatically scroll to them when an error when fetched.
the identifier is specified in the fragment part of a URL [70]. This CORB. CORB is an algorithm in the browser that blocks dubious
behavior can be used to detect if a specific identifier is present on cross-origin resource requests before they reach the webserver
a page. For certain HTML elements as inclusion methods, GC and (cf. Section 7). This feature can be used to detect the presence
SA will not only scroll to them but also focus them. For example, of Content-Type and Content-Type-Options headers, because
<input id="leakme"> will gain focus when the fragment of the CORB is only enforced for specific content-types together with the
URL is set to leakme. In GC, this even works in cross-origin iframes. nosniff option. An attacker can use a combination of event handlers
However, an attacker can not directly detect that the element got as a leak technique to detect CORB.
focused because of the SOP. To get around this, an onblur handler ContentDocument XFO. In Chrome, when a page is not al-
can be registered on the attacker page. Once the iframe receives lowed to be embedded on a cross-origin page, because the X-Frame-
focus, the attacker page will lose focus and a blur event triggers. Options (XFO) header is set to deny or same-origin, an error page
Heyes [25] discovered this leak technique and it can be used to is shown instead. For objects, this error page can be detected by
detect login pages or to leak sensitive data from the id or name checking the contentDocument property [69]. Typically, this prop-
attribute. erty returns null because access to a cross-origin embedded docu-
CSS Property. Web applications may change website styling de- ment is not allowed. However, due to Chrome’s rendering of the
pending on the status of the user. As described by Evans [13], these error page, an empty document object is returned instead. This
changes can be used to detect differences in Cascading Style Sheets does not work for iframes or in other browsers. Developers may
(CSS) rules. Cross-origin CSS files can be embedded on the attacker forget to set X-Frame-Options for all pages and especially error
page with the HTML link element, and the rules will be applied pages often miss this header. As a leak technique, an attacker may
to the attacker page. If a page dynamically changes these rules, an be able to differentiate between different user states by checking
attacker can detect these differences depending on the user state. for it.
For example, websites will often serve different CSS depending on Download Detection. The Content-Disposition header in-
whether the user is logged in. As a leak technique, the attacker can dicates if the browser is either supposed to downloaded content
include the targeted CSS file to use the window.getComputedStyle or displayed it inline. Masas [38] has demonstrated with a leak
method to read CSS properties of a specific HTML element. As a technique that an attacker can detect downloads by using the in-
result, an attacker can read arbitrary CSS properties if the affected clusion method: iframe. If the iframe is still accessible, the file was
element and property name is known. downloaded; this is the case because in most browsers a down-
load does not trigger a navigation and the iframe is still considered
same-origin. This attack also works with pop-ups created with
window.open.
A.5 Detectable Difference: Header
In some cases, the presence of HTTP headers can be detected. This
includes headers such as X-Frame-Options, Content-Type, and
Content-Disposition.
Performance API XFO The Performance API is used to access
performance information of the current page [29]. This includes
detailed network timing data for the document and every resource
the page loads. Terjanq [55] showed that when a resource has
X-Frame-Options header set and is included with an object tag, it
will not create an resource timing entry in the Performance API (cf.
Section 5.2).
CSP Directive. A new feature in GC allows web pages to pro-
poses a CSP by setting an attribute on an iframe element. The policy
directives are transmitted along with the HTTP request. Normally,
the embedded content must explicitly allow this with an HTTP
header, otherwise an error page is displayed. However, if the iframe
already ships a CSP and the new policy is not stricter, the page will
display normally.
 Browser Chrome and Edge Firefox Safari

85.0 - 87.0

89.0 - 90.0

80.0 - 84.0

85.0 - 88.0
80.0

81.0

83.0

84.0

88.0

79.0

11.1

12.1

13.1

14.0
XS-Leak
Detectable Difference: Status Code
Performance API Error ○ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○ ○ ○
Style Reload Error ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○ ○ ○ ○
Request Merging Error ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○ ○ ○ ○
Event Handler Error ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
MediaError ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Detectable Difference: Redirects
CORS Error Leak ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○ ○ ○
Redirect Start ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○ ○ ○
Duration Redirect ○␣ ○␣ ○␣ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Fetch Redirect ○␣ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○ ○␣ ○␣ ○␣
URL Max Length ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Max Redirect ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○
History Length ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○ ○ ○ ○
CSP Violation ○ ○ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○ ○ ○
CSP Redirect ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Detectable Difference: API Usage
WebSocket ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○␣
Payment API ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Detectable Difference: Page Content
Performance API Empty Page ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○ ○ ○
Performance XSS Auditor ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○ ○ ○
Cache ○ ○ ○ ○ ○ ○␣ ○␣ ○ ○ ○␣ ○ ○ ○ ○
Frame Count ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Media Dimensions ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Media Duration ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○␣
Id Attribute ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
CSS Property ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Detectable Difference: Header
SRI Error ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○
Performance API Download ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Performance API CORP ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○␣ ○ ○ ○
COOP Leak ○␣ ○␣ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Performance API XFO ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○␣ ○ ○ ○ ○
CSP Directive ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
CORP ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○␣ ○ ○ ○
CORB ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
ContentDocument XFO ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Download Detection ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○␣ ○ ○ ○
Í
Attackable (max. 34) 25 26 27 27 26 24 23 15 14 13 20 22 23 24
Table 3: Evaluation results for popular desktop browsers show how vulnerabilities propagate between different versions.
Browser versions that did not show any differences have been merged. Chrome and Edge behave identically.
 iOS Version iOS 14 iOS 13 iOS 12 iOS 11

Firefox Focus 8.1.7

Chrome 87.0

Chrome 86.0

Firefox 33.0
Opera 3.0.2

Edge 46.3.7
Safari 14.0

Safari 13.0

Safari 12.1

Safari 11.0
XS-Leak
Detectable Difference: Status Code
Performance API Error ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Style Reload Error ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Request Merging Error ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Event Handler Error ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
MediaError ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Detectable Difference: Redirects
CORS Error Leak ○ ○ ○ ○ ○ ○ ○ ○ ○ ○␣
Redirect Start ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Duration Redirect ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Fetch Redirect ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○
URL Max Length ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Max Redirect ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣
History Length ○ ○ ○ ○ ○ ○ ○␣ ○ ○ ○
CSP Violation ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
CSP Redirect ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Detectable Difference: API Usage
WebSocket ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Payment API ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Detectable Difference: Page Content
Performance API Empty Page ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Performance XSS Auditor ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Cache ○ ○ ○ ○ ○ ○ ○␣ ○ ○ ○
Frame Count ○ ○ ○ ○ ○ ○ ○␣ ○ ○ ○
Media Dimensions ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Media Duration ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Id Attribute ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
CSS Property ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Detectable Difference: Header
SRI Error ○ ○ ○ ○ ○ ○ ○ ○␣ ○␣ ○␣
Performance API Download ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○␣ ○␣
Performance API CORP ○ ○ ○ ○ ○ ○ ○ ○ ○ ○␣
COOP Leak ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Performance API XFO ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
CSP Directive ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
CORP ○ ○ ○ ○ ○ ○ ○ ○ ○ ○␣
CORB ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
ContentDocument XFO ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣ ○␣
Download Detection ○ ○ ○␣ ○␣ ○␣ ○␣ ○␣ ○ ○␣ ○␣
Í
Attackable (max. 34) 24 24 22 22 22 22 19 22 20 18
Table 4: Evaluation results of 10 iOS browsers. All browsers based on new versions of WebKit mostly behave identically except
for Firefox Focus. Older version closely match the desktop Safari behavior (cf. Tables 3).