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

This page has been proofread, but needs to be validated.
Session 6B: System and Network Security #2
ASIA CCS ’22, May 30–June 3, 2022, Nagasaki, Japan

with when a resource is requested, parsed or rendered. Examples of such components include the HTTP cache, the network connection pool (at the level of the browser), the different DOM properties of the attacker’s page and that of the rendered resource, or various aspects of the operating system on the client side such as CPU caches. We also consider components located on the server, which may depend on the infrastructure and environment of the targeted server, but will typically include the network layer at the OS-level and the various aspects related to the execution of the web application’s implementation. Based on the layer at which the components are located, we can group them together in seven component groups, five of which are located on the client side: attacker tab, victim frame, victim tab, browser, and client OS. The remaining two component groups are located on the server-side: environment (e.g. OS or serverless computing environment) and web server.


Each component consists of a 3-tuple, where the first element, , represents the specific characteristics of the component. The latter two elements of the tuple, and , represent the state that the component is in, one for each state of , i.e. the two different states that the application can be in based on the user’s authentication. Initially, these two states are equal, but they may differ after the state-dependent resources have been included. For example, the state of the HTTP cache is initially empty, but after rendering the resource in state , a resource will be added to the cache, whereas this would not happen in application state , thus resulting in different component states. We formally denote the set of components as follows: , where each individual component is defined as follows: . We reference the state of the component, Ci , for the first application state, , as .


Next, we introduce the state-transfer and state-retrieval functions. The state-transfer function, , will execute a specific inclusion technique i on the targeted state-dependent resource, and thus might bring the components in a different state. As such, the aim of this function is to transfer the web application state into the component state. We formalize this function as follows: , where represents the same set of components but after inclusion of the . This inclusion may cause the initial state of a component to be altered, i.e. when or . For each component that was involved in the state-transfer, the state may have changed differently depending on the web application state (and thus depending which version of the resource was included). We can describe the differential component state in our model as (where is the XOR operator). This differential component state reflects the difference in the final state of the component depending on whether the resource in application state or in was included. For simplicity, throughout the remainder of the text, we will refer to this differential component state as .

The state-retrieval function, , aims to subsequently extract the differentiating state-changes that were introduced by the statetransfer function. More precisely, given the set of components in their initial state and possibly-altered state, and , this function will return the set of state-changes that could be detected with the leak technique . Formally, we represent this function as follows: , where represents the set of detectable (using leak technique ) state-differences (between and ). In our running example, the state-difference is that in one application state the resource will be cached, but not in the other application state. We can detect this state-difference by using a timing attack based on the response time. The set of detectable state-differences, , consists of two parts, where the first one, , represents valuative differences, e.g. a difference in the number of frames. The latter part, , represents differences in the time domain, where the resulting value of the leak technique is exactly the same in both states, but where the timing differs. Another example of this case, is where the processing time of a certain request takes longer depending on the state of the user. While the resulting response may be exactly the same, the time it takes for the response to be received by the victim’s browser will differ. We formalize the set of differences in both domains as follows: .

In the case of our running example, we now get the following:

  • We first transfer the application state to one of the components by embedding the resource as an iframe: .
  • In application state s0 , the state of one component, the HTTP cache, will be altered, while this does not occur in the case of . As a result, the differential component state is non-empty: .
  • Using a timing attack as leak technique, we can now retrieve the state from the component: .
  • This results in a single detectable state-difference in the time domain: , where represents the timing difference when requesting a cached vs. non-cached resource.

A simplified visual representation of our model can be found in Figure 1, showing the seven component groups that each have their own state. Furthermore, when a state-dependent resource is included (black arrow), it can trigger state-changes in all the components that it passes through (as indicated by the red circles). Extracting the detectable state-differences is then performed by launching a leak technique in the state-retrieval function (indicated by the purple dotted line).

3.4 Conditions for XS-Leaks

Using the extended formal model, we can now express the conditions that need to be met for an XS-Leak issue to exist. A first prerequisite is that the state of a component needs to be changed as the result of an inclusion method, i, in at least one of the two application states, s0 and s1 , expressed formally: , where . Furthermore,

787