an attack, when the resource is rendered in a new tab (victim window), the attack will not be able to determine whether this caused a resource to be added to the cache, because the attacker’s HTTP cache is isolated from the HTTP cache used by the victim site.
Defense: network isolation
XS-Leaks thwarted:
Another isolation defense is based on preventing attackers from retaining references to other windows. This defense can be enabled through the Cross-Origin Opener Policy (COOP), by setting the similarly named response header [29, 61]. At the time of this writing, the header is supported by all major browsers. In essence, when the policy’s header value is set to same-origin, it ensures cross-origin pages do not have a reference to the other window. For example, this prevents the attack that counts the number of frames in a page from accessing the win.frames.length property. Because an attacker page can also include the target resource in an iframe, it is important that this defense is complemented with framing protection.
Defense: COOP
XS-Leaks thwarted:
Finally, to counter attacks that leverage state-changes occurring at the microarchitectural level, or that are related to the process in which web pages are rendered and executed, a new isolation primitive, site isolation, was introduced [34]. In essence, site isolation ensures that documents of different sites are rendered in a separate process. This means that as long as no sensitive cross-site resources are loaded into the renderer, these are protected from attacks such as Spectre. As such, resources that are included directly may still cause -architectural state-changes.
Defense: site isolation
XS-Leaks thwarted:
The third defense strategy that can be used to mitigate XS-Leaks is
to ensure that all responses to illicit requests are exactly the same,
regardless of the web application state. To accomplish this in all
components, the generation of the response should not be based
on the web application state. When the two web application states
are identical, e.g. because the user’s authentication is not included
in the request, all components will remain in their original state.
In practice, there exist two defenses that are based on ensuring
the responses remain stateless, namely SameSite cookies and Fetch
Metadata request headers. When a cookie’s SameSite attribute
is set to Lax (the default in Chromium-based browsers [5]), the
cookie, and thus the user’s authentication, will not be included
in the request [28, 37]. As a result, the server will not be able
to authenticate the user and will thus always return a stateless
response. Because the SameSite cookie will still be included in navigational GET requests, attacks that rely on opening a new window are still possible.
![{\displaystyle u:(\exists {x}\in [i,j])(s_{0}\neq s_{1}\land d_{0}\neq d_{1}\land C_{x}^{'}\cdot \Sigma \neq \emptyset )}](https://wikimedia.org/api/rest_v1/media/math/render/svg/fa23c785cd9bbd9b595d644e1604bd29e10061ee)
![{\displaystyle D:(\forall {x}\in [0,n])(s_{0}\neq s_{1}\land d_{0}\neq d_{1}\land C_{x}^{'}\cdot \sigma _{s_{0}}=C_{x}^{'}\cdot \sigma _{s_{1}}=C_{x}\cdot \sigma _{s_{0}})}](https://wikimedia.org/api/rest_v1/media/math/render/svg/a1e1c2d4348fdb56a4eb31885f7d36cb4b10d07b)
Defense: SameSite cookie (Lax)
XS-Leaks thwarted:
To give web developers more insights on what caused the browser to send a request, the Fetch Metadata request headers provide information on the context in which a request was made. More specifically, the Sec-Fetch-Site header indicates whether the request was made in a cross-site, same-site or same-origin context, or whether the request was the result of a navigation request. Similarly, the Sec-Fetch-Mode indicates the "mode" in which the request was made: using CORS or not, as the result of a navigation, or for a WebSocket. By combining the different headers and evaluating their values before the request is processed, the server can determine the legitimacy of the request and return a static (stateless) error message when the request is considered illegitimate. A typical and recommended way of applying a policy based on these request headers is via the resource isolation policy (RIP) [67], which only allows same-site requests or GET requests that result from navigations or embedding.
Defense: Fetch Metadata (RIP)
XS-Leaks thwarted:
Although many different defenses exist, using one of the three different strategies, it remains to be seen whether these are sufficient. In this section we explore whether it is feasible to provide a complete protection against all possible XS-Leak attacks, including those that have not yet been discovered to date. Furthermore, we discuss directions for future work to explore whether the current set of defenses are sufficient to provide websites with the necessary protections.
As we have constructed an expression that captures the set of possible XS-Leaks each defense protects against, we can simply apply constraint solving to determine whether there exists any set of defenses for which no XS-Leak attack is still possible. Unfortunately, we find that there is no combination of defenses that provides a complete protection against all XS-Leaks, posing an interesting direction for future research. The main culprit for this are attacks where a different window is used as the inclusion method, as there is no defense that can completely protect against these. Although COOP prevents the attacker from reading out any state from the window in which the resource was rendered, any intermediary component group between the victim tab and web server may still exhibit state-changes as a result from rendering the resource (e.g. it is still possible to observe the response generation time). However, it is important to note that although COOP does not provide these complete protections in our model, it does significantly hinder attacks in practice. For each bit of information that the attacker would try to extract, a new window needs to be opened, requiring a user interaction.
