the state-changes that occur in the component need to be different between the two web application states (which result in two different responses). Concretely, this means that the differential component state of at least one component needs to be non-empty: or simplified: . The other prerequisites for a successful XS-Leaks attack is that it needs to be possible to extract this differential state from the component. This means that there needs to exist a leak technique, , for which the state-retrieval function returns a non-empty set of detectable state-differences. Formally, we can express this as follows: . These detectable state-differences can be either valuative differences or differences in the time domain: . Using this extended representation of the XS-Leaks model, we can better reason about the cause of the different attacks that are known to date (Section 4), determine various methods to detect new attacks (Section 5), analyze the different strategies used for defenses (Section 6), and whether these are sufficient to provide a complete protection (Section 7).
![{\displaystyle (\exists C_{i},i,t)[sr(t,Ci,C_{i}^{'}),\emptyset ]}](https://wikimedia.org/api/rest_v1/media/math/render/svg/c09aac6effe7cca24694a5e54e9a570675d342cd)
Although the term XS-Leaks is relatively new, the issues have been known for more than two decades, e.g. in 2000, Felten and Schneider described how the time to request a resource leaked information about its cache status. Prior work on categorizing XS-Leaks has mainly focused on enumerating the different known techniques and grouping them by the technique that is used [46], or based on the differences in the resource that can be detected [18, 49]. In this section we introduce a new classification method that is based on our model and aims to capture the intrinsic properties of XSLeaks; namely the component to which the web application state is transferred, the inclusion method that is used for this state-transfer, and the technique that is used to finally extract this state.
Based on our model of XS-Leaks we now propose a classification that can be used to uniquely distinguish different XS-Leak attacks. This classification allows us to capture which types of XS-Leaks have already been found, and can thus be used as a means to guide future research (which we explore in more detail in Section 5). We determine several attributes that can be appointed to an XS-Leak, most of which originate directly from the model.
Component group As described in our model (Section 3), this attribute captures the group of components in which the relevant state-change occurs that eventually leads to the XS-Leak. Inclusion method This property reflects the inclusion method that is used to trigger the state-transfer. For reasons of clarity, we divided these in groups: iframe (where the attacker embeds the state-dependent resource in an iframe), other window (where the resource is rendered in a different tab, using window.open() or window.opener), and direct (using a DOM API, e.g. <img> or fetch(), to include the resource – here we also indicate whether a specific API or any API is used).
State difference For this attribute we also summarized the possible values in three different groups: event fired (when an event is fired that can be observed by the attacker), change of a property (when the value of a certain property within the component changes, e.g. a new entry being added to the cache), and consumption of a limited resource (when there is a resource in the component that can only be consumed a limited amount of times, e.g. the Cache API has a global quota).
Leak technique The leak techniques extract the altered states from the components. These can be as straightforward as observing the time that an event occurs, or reading out the value of a certain property. Leak techniques may also be more complex, and may require probing. For instance, it is not possible to directly determine the cache status of a resource, but instead a timing attack needs to be used. Information in timing For certain XS-Leaks the state-change that occurs does not leak any sensitive information about the resource. Instead, the time that the state-change occurs is what leaks the information. With this attribute we indicate whether the XS-Leaks only has detectable differences in the time domain; formally: .
Idempotency When after inclusion the state of certain components changes permanently and irreversibly, the XS-Leak is considered to be non-idempotent. For example, once a resource has been cached, it will remain cached until it becomes invalid. Consequently, the attack can only be executed once (unless there exists a technique to revert the state-changes). In other words, an XS-Leak is idempotent if there exists a method that can revert the statechanges made to the affected component: .
![{\displaystyle (\exists p)[p(C_{i}^{'}\cdot \sigma )=C_{n}\cdot \sigma ]}](https://wikimedia.org/api/rest_v1/media/math/render/svg/b872eb2f05a972fba447a6267a207d7ecb72bee9)
Differentiating aspect Finally, we capture the various aspect(s) of the state-dependent resource that are detectable. For brevity, we categorize these in four groups: headers, content, metadata (such as size of the response), and generation process.
We now apply our classification to all the different XS-Leaks that we found in the systematic literature review. We group together attacks based on the core mechanism that is used to leak the information. For instance, Bortz and Boneh showed that the time to download a response relates to the size of that response [4]. Gelernter and Herzberg introduce an amplification attack where the difference in response size grows extensively [10, §3.1], making the attack significantly more accurate, but still uses the original mechanism to leak the information. Similarly, in another attack introduced by the researchers, the execution time on the server is amplified [10, §4], which is similar to what Van Goethem et al. measure in their timeless timing attacks [54].
The classification of known XS-Leak attacks is shown in Table 1, and a brief summary of each attack is provided in the Appendix, Section A. Based on these results, we can make several observations. We find that there is a lot of diversity in the attacks: each component group is responsible for at least one attack. Furthermore, the majority of the leaks are caused by state-changes in the attacker page. We believe the reason for this is twofold. First, most mechanisms that can be used to include remote cross-site resources originate from the attacker page, and any resource-dependent parsing or processing is likely to introduce a leak. Secondly, the state-changes that occur in the attacker page are mostly directly observable and
