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

thus easier to detect, and in several cases even described in the specification. On the other hand, it is not directly clear that creating a new connection will consume a limited resource (the connection pool), which only has an observable side-effect after actively probing for the state-change. Another interesting observation is that the mechanisms aimed at defending against XS-Leaks can also be the source of a leak themselves. For instance, if the CORP header is only enabled based on the state of the user, an attacker could leverage this to leak information. Hence, it is important for web developers to consistently apply the defenses, and ensure features are not enabled conditionally.

5 XS-Leak Attacks: Future Research

To date, most XS-Leaks that have been discovered and reported are isolated issues that result from evaluating a particular API. Consequently, this does not provide any information about the possible number of XS-Leaks that currently remain undetected. We believe that systematic analyses are paramount for future research to discover previously unknown XS-Leaks, or to prove the absence of XS-Leaks in certain components. To guide this systematic analysis, the concept of components, whose state can change as the result of an inclusion, is instrumental. We believe that two aspects are needed to further map out the attack landscape on XS-Leaks, namely carefully listing all the possible components involved in the inclusion process, and for each component detecting whether the application state is transferred into the component state. Next, we explore these two aspects in more detail.

5.1 Enumerating components

In our classification we considered seven different component groups, both on the side of the client as well as on side of the server. However, each of these component groups can have numerous sub-components, which each may have their own state. As such, by mapping out all the different components in the smallest fragment possible, researchers can determine which aspects could possibly lead to XS-Leaks. More concretely, any interaction that is made with a state-dependent resource, regardless of whether this is persistent (e.g. adding it to the cache) or ephemeral (e.g. verifying the content type), could possibly trigger a change in the state of the component. Any such state-change could then result in an XS-Leak, provided there exists at least one leak technique that can infer this state-change. It is important to note however that not every state-change will lead to an XS-Leak, as it might not be feasible to retrieve the state from certain components. Systematically enumerating all components is an arduous task as it involves operations that occur at various levels, each of which can be extremely complex or not well documented. As such, we believe that an iterative process guided by information that is already available (e.g. web specifications) would be most practical. More precisely, researchers could for each component group determine all the different operations that occur on the resource, and then for each operation determine which components are involved, in an increasingly fine-grained manner. As the list of components can be considered cumulative, any research that further refines the components would contribute to mapping out the threat surface.

5.1.1 Novel attacks on determining triggered requests. As part of our research, we partially analyzed the various sub-components of the little-explored server environment component group, resulting in two novel attacks that can leak the number of requests that were initiated by the user, e.g. as the result of rendering a statedependent resource. Both attacks leverage a limit that is imposed on requests $(\Delta ={consumption_{o}f_{l}imited_{r}esource})$, which can be extracted by a probing leak technique. The first attack abuses the fact that web servers limit the number of requests that can be made over a single connection. For some of the most popular web servers, this limit is set by default to 100 (Apache, via the MaxKeepAliveRequests directive, and older nginx versions) or 1,000 (newer nginx versions, via the keepalive_requests directive). Once this limit is reached, the web server will close the connection. In an attack, the adversary could first trigger the rendering of the statedependent resource (e.g. by loading it in an iframe), which would initiate either $n$ or $n-1$ requests, depending on the state of the user. Subsequently, the attacker sends $100-n$ requests and then determines whether the next request would require opening a new connection (e.g. based on a timing side-channel). From this, the attacker can infer whether $n$ or $n-1$ requests were made and thus reveal the user’s state. The second attack follows the same principle, but instead leverages the limit imposed by rate-limiting systems that aim to protect the website. Once the predefined maximum number of requests within the allotted time window has been reached, the web server will most likely generate a different response. This could include closing the connection, or returning an error message. This could in turn be probed by the attacker. The main difference between the two attacks is that the second one is URL-specific, whereas the first one only reveals information about the total number of requests sent to a specific origin. Furthermore, browsers with a keyed connection pool can defend against the first attack (under the condition that the embedding frame is part of the key), whereas the rate-limit is most likely to be IP-based. Consequently, a keyed connection pool would not deter this attack.

5.2 Detecting component state-changes

An important prerequisite for the existence of an XS-Leak, is that

after inclusion of the state-dependent resource, the state is transferred to the component. As such, only components that experience a state-change can be the source of XS-Leaks. In order to detect this, we propose the following three-pronged approach, which is agnostic of the component, or component group, that is being evaluated. First, a web server should be set up that serves resources that each have a different differentiating aspect $(d\in D)$, compared to a baseline resource. This is needed because a component may only trigger a state-change when the differentiating aspect is present. Secondly, a state-monitoring system can be set up that tracks the state of the investigated components. How this can be achieved largely depends on the component group that is analyzed. For instance, for components that relate to the DOM, all the different property values, and APIs could be enumerated, capturing a snapshot of the state of the DOM. On the other hand, the state of other component groups such as the browser or client OS might be less accessible, and would thus require additional effort to evaluate.