could be logged-in or logged out, being connected with someone one a social network site, receiving at least one result for a search query,...). The attacker can then reveal whether the user is in state s 0 or s 1 by detecting whether or not the resource was cached by using a timing attack to extract this “detectable state-difference” from the HTTP cache. Based on this formal model, we introduce a classification structure that can be used to uniquely identify different issues based on their intrinsic characteristics, i.e. the affected component, inclusion method and leak technique. We discuss how our new insights in the underlying causes of XS-Leaks can be used to identify new vulnerabilities and propose a methodology to this effect. Furthermore, we explore and analyze the different defenses that can be used to thwart a variety of XS-Leaks and find that these can be divided in three main strategies: preventing state-changes in components, isolation, and ensuring that responses are stateless. By categorizing these, we aim to improve the general understanding of these defenses and spark discussion about potentially novel protections, as some defenses may be too coarse-grained to be adopted. Finally, we analyze the adoption rate of XS-Leak defenses, introduce Leakbuster[1], a dynamic web interface that facilitates defense deployment, and report on a case-study where defenses were deployed at large scale.
In this section we provide the description for our model on XSLeaks, which will be referred to throughout the remainder of the paper. This model was created by thoroughly analzying the underlying commonalities of the previously-known XS-Leak vulnerabilities, which were obtained by a systematic literature review. Our model extends that of Knittel et al. [18] and focuses on the intricacies that form the foundation of XS-Leak vulnerabilities. These novel constructs allow us to comprehensively classify current attacks, propose a methodology to detect new attacks, and formally evaluate different defense strategies.
In summary, we make the following contributions:
- We introduce a formal model for XS-Leaks, highlighting the underlying intricacies that cause the vulnerabilities, and capturing the different stages that occur during an attack.
- Based on this model, we propose a classification method that can be used to uniquely characterize XS-Leaks, and introduce a methodology that can be used to detect new vulnerabilities.
- As part of our analysis of the little-explored web server component, we identify two novel XS-Leak attacks.
- We analyze the general strategies that are employed by defenses and find that a combination of isolation and mechanisms that prevent illicit requests are necessary.
- We share the insights of a real-world case study where defenses were deployed at large scale, and use these to create Leakbuster, a dynamic web interface that can be used by web developers to facilitate the deployment of defenses.
When the web was originally envisioned, its main goal was to facilitate the sharing of public static information. It was not until later, after cookies were introduced to the web platform, and users could authenticate with websites, and share private information with them, that security became more important. However, as cookies were not designed with security in mind, and thus are attached to all requests of the domain they were set on, this gave rise to a new class of vulnerabilities. For example, in a CSRF attack, the attacker tricks their victim to send an authenticated request that performs an unconsented action on the target website, e.g. change the victim’s password. The automatic inclusion of cookies in requests did not only enable state-changing attacks, but is also at the base of attacks that aim to uncover information that a user shared with a particular website. As this clearly has significant security and privacy consequences, the same-origin policy was devised [31], This policy is a set of security principles that ensure that one origin cannot leak any information about resources from another origin, unless permission is explicitly granted via CORS headers. As a result, the concept of an origin (scheme, host, port) and site (scheme, eTLD+1) now is a security boundary, and information should be confined within this boundary. This includes the content of the response body, the header values as well as metadata, e.g. size of the response. Due to historical and practical reasons, some metadata is intended to be known, such as the dimensions of an image. However, it has been shown that other, potentially sensitive, information can be leaked across site boundaries through various side-channel attacks. These are referred to as XS-Leaks and are the main focus of this paper.
In this section we provide the description for our model on XS- Leaks, which will be referred to throughout the remainder of the paper. This model was created by thoroughly analzying the underly- ing commonalities of the previously-known XS-Leak vulnerabilities, which were obtained by a systematic literature review. Our model extends that of Knittel et al. [18] and focuses on the intricacies that form the foundation of XS-Leak vulnerabilities. These novel constructs allow us to comprehensively classify current attacks, propose a methodology to detect new attacks, and formally evaluate different defense strategies.
To better understand the practical aspects of XS-Leak attacks and to map these to our formal model, we first introduce a running example of a web application that is vulnerable to various XSLeak attacks. This application provides a fairly straightforward search functionality, and the web page showing the search results is implemented as a Jinja template, as shown in Listing 1. The underlying application authenticates the user based on the cookies that are attached to the request, and performs a textual search on the user’s private information based on a string provided in a GET parameter. For each result, the description is shown along with an icon that is loaded from a CDN. We assume that the application is secured against “typical” web security vulnerabilities, such as SQL injection and cross-site scripting. Interestingly, despite this fairly trivial functionality, there are multiple XS-Leak techniques that can be used to leak the user’s private information. In fact, this example is based on real-world vulnerabilities that were discovered in a series of Google products [51]. Listing 2 shows the JavaScript code that an adversary could run on their site to determine whether any results were shown for a specific (attacker-supplied) keyword. The attack code first loads the resource in an iframe (although it could also open it in a separate window using window.open() or window.opener). It then waits for the document to load, and subsequently uses a timing attack to determine whether the icon was loaded from cache. As the icon is added to the cache only when there is at least one result, the cache entry would be indicative that at least one result was returned for
the query. In order to check multiple queries, the attacker would
