Page:SoK Exploring Current and Future Research Directions on XS-Leaks through an Extended Formal Model.pdf/3

Session 6B: System and Network Security #2

Listing 1: Example template of a search application.

Listing 2: XS-Leak attack against example application. need to reset the state of the cache, and thus use one of the known techniques [59] to remove the icon from the cache. Note that as a result of the recent network isolation defenses, this specific attack is prevented, but it still allows us to clarify important points about XS-Leaks during the different sections of the paper. The example application is also vulnerable to other XS-Leak at- tacks. instance, detecting the size of the response leaks whether there were any, and possibly how many, results [4, 53, 55]. Further- more, a new connection might need to be established to retrieve the icon image from the CDN, which also only happens if there is at least one result. This can be detected by leveraging the global limit on the connection pool [6]. In case the execution time of processing the request depends on how many results are generated, this may also create a timing side-channel that can be exploited [10, 54].

For the XS-Leaks discussed in this paper, we consider a threat model where the victim lands on a web page that is (partially) controlled by an adversary. This could either be a malicious web page containing arbitrary code, a compromised web page, or a web page containing a malicious advertisement. Unless stated otherwise, we consider that no restrictions, e.g. through the sandbox attribute of an iframe, are imposed on the attacker's web page. We define XS-Leaks attacks as follows: an attack where the ad- versary leverages various browser operations and observes their direct or indirect effects in order to infer information about cross- site resources that reflect the state that the user has with a targeted website. These cross-site resources are typically dynamically gen- erated based on the identity of the victim, which is inferred from the included cookie, the requested endpoint, and (attacker-provided) query parameters. Although attacks that aim to determine which websites were previously visited by a user are closely related to XS-Leaks attacks, these are out of the scope, and are known as "This definition is in line with that of prior work (XS-Leaks Wiki [46] and COSI attacks [49]), but makes it explicitly clear that the attacker aims to infer the state that the user has with the targeted website.

history sniffing attacks or history leaks. These attacks on user pri- vacy typically aim to infer the changes that are persisted in the browser by interactions that were made by the user. For example, the browser keeps track (locally) of which web pages a user visited, and applies a different style based on whether the URL was visited (which could be abused to leak previously visited pages [1, 19, 43]). In contrast, XS-Leak attacks require any change that is persisted in the browser to be the result by an operation of the attacker, e.g., an attacker-triggered request made to the targeted server.

In this section we first present the base model, as was introduced by Knittel et al. [18], and then extend this model to more extensively describe the underlying characteristics of XS-Leaks. Our model was constructed by thoroughly analyzing existing XS-Leak issues, and for each determining the actual cause and required operations. To obtain a list of existing XS-Leak attacks, we performed a system- atic literature review in which we considered all papers that were published in the past five years at a well-known security confer- ence (S&P, CCS, NDSS, USENIX Security, ACSAC, AsiaCCS), or an attack or web-focused workshop (WOOT, W2SP, SecWeb). We included every paper that presented an attack where the threat model matches the one required for XS-Leaks, and where the attack could be used to leak information from cross-site resources. We further extended this set of attacks with those reported in blog posts, online articles, or in disclosed bug reports to major browser vendors. In total we consider 38 distinct XS-Leak attacks (including two that were discovered as a result of our research).

Base model: Applying this to our running example, we get the following:
 * The URL resource of the web application that is being targeted by the attacker is defined as url
 * This web application can be in two different states, depending on the user's authentication: $$S = \{s_{0}, s_{1}\}$$.
 * Depending on the state S, the application will behave differently, e.g., by including an additional image; the differences in this behavior is defined as $$D = \{d_{0}, d_{1}\}$$.
 * A cross-site leak is then defined as the function $$xsl$$ that outputs a bit $$b^{'}$$; more precisely: $$b^{'} = xsl(sdr, i, t)$$, where $$ i \in I$$ I represents the inclusion method that is used to trigger the request to the state-dependent resource (e.g. including the resource in an iframe), and $$t \in T$$ is the leak technique that is used to observe the difference cross-site (e.g. counting the number of frames in the rendered web page).
 * Finally, the state-dependent resource that is being requested is defined as $$sdr \in SDR$$, where $$sdr_{0} = (url, (s_{0}, d_{0}))$$.
 * $$url = https://example.com/search?q=query$$
 * $$s \in \{no-search-results, at-least-one-result\}$$
 * $$d \in \{no-icon-on-page, icon-on-page\}$$
 * The inclusion method $$i$$ is embedding the URL as an iframe
 * The leak technique $$t$$ consists of performing a timing attack that aims to determine whether the inclusion of the web page lead to the icon being cached

Extended model: We extend the model of Knittel et al. by introducing the concept of components. These components are the abstract representation of all the different aspects that are interacted