The minimal set of currently available defenses that provides the best possible protection against XS-Leaks is the combination of SameSite cookies, COOP and site isolation. The SameSite attribute on cookies ensures that all cross-site requests, either included directly or via an iframe, are stateless. Additionally, COOP provides the best available protection for when resources are included in a different window. Finally, site isolation ensures that any microarchitectural state-changes that were caused by rendering the resource cannot be observed. In case SameSite cannot be used, e.g. because the website relies on specific cross-site interactions, this defense could be exchanged for the combination of RIP (based on Fetch Metadata) and framing protection. However, the framing protection provides a strictly less extensive defense compared to SameSite cookies as the stateful response body will still traverse several components, possibly causing state-changes. Although no side-effects caused by rendering the resource can be observed, it might still be possible to leak information about the metadata, headers or generation process of the resource. Instead of using the framing protection set in response headers, websites could also use Fetch Metadata to block all requests that originate from iframes (using a Framing Isolation Policy, based on provide the same flexibility as the framing protections because it does not allow specific frame ancestors, blocking the request early on does prevent state-changes in all components. This example shows that cross-site interactions may complicate the implementation of XS-Leaks defenses. In the remainder of this section, we explore future research directions that could improve this situation.
Many of the current defense mechanisms allow websites to either
opt-in or opt-out of cross-site interactions. For example, the CORP
header can only be set to same-origin, same-site or cross-site.
This limits the granularity in which the defense can be applied,
and it may be prohibitive to use this in conjunction with website
functionality that relies on cross-site interactions. Examples of such
cross-site interactions include social plugins, authentication flows,
third-party video content, .... In many cases, these require the user’s
authentication to provide the intended user experience. It is for
this reason that the SameSite-Lax-by-default policy in Chromium
makes an explicit exception for cookies that were set within the last
two minutes, as this would cause various authentication flows to
break [35]. As the adoption of XS-Leaks defenses is slowly ramping
up, we believe that it is an interesting direction for future work
to evaluate whether the current set of defenses is sufficient to
provide the maximum protection for websites that rely on crosssite interactions.
To further protect websites from XS-Leaks, web browser could
enable certain policies by default (as the ones indicated above) or
try to eradicate legacy features from the web platform (e.g. the
frames.length property stems from the time when iframes were
widely used to build websites). Based on the most recent data (October 2021) from the HTTP Archive[1] crawl over the home page
of 5.5M sites, we find that there are only 3.07% of these sites to
which at least one request was initiated in a cross-site context. This clearly indicates that most sites do not intend to be included by
other sites at all, and thus would greatly benefit from policies that
are enabled by default. As such, we believe that research in the
direction of determining how XS-Leaks defenses can be enabled by
default without negatively impacting intended functionality could
significantly advance the state of security on the web.
An image should appear at this position in the text. To use the entire page scan as a placeholder, edit this page and replace "{{missing image}}" with "{{raw image|SoK Exploring Current and Future Research Directions on XS-Leaks through an Extended Formal Model.pdf/10}}". Otherwise, if you are able to provide the image then please do so. For guidance, see Wikisource:Image guidelines and Help:Adding images. |  |
Figure 2: Adoption of XS-Leak defenses over time (log y-axis).
While several defense mechanisms exist that can adequately protect against virtually all practical attacks, an obvious prerequisite for these defenses to be effective, is that websites need to deploy them. In this section we explore to what extent websites already make use of them, introduce LEAKBUSTER, a web application to facilitate deployment, and discuss the difficulties that web developers are still facing based on a case-study where XS-Leaks defenses were deployed at large scale.
To analyze the evolution of the adoption of XS-Leaks defenses, we rely on the public datasets provided by HTTP Archive, containing detailed information on the visits of home pages of approximately 5.5M sites. In all same-origin responses, we look for the presence of the three main headers that control the XS-Leaks defenses in the browser. In Figure 2 we show the number of sites that adopt one of the policies, or a report-only (RO) version of it, over the past two years. This evolution shows that the adoption of security features is gradually increasing. Furthermore, we expect this growth to continue: e.g. in October 2021 we find more sites that enable the report-only mode of COOP (16,223), compared to those that implement the enforcing version (8,997). This is indicative that a growing number of websites intends to use this mechanism, but these are still in the early stages of deployment.
The most common XS-Leaks defense mechanism in use is CORP, with 46,805 sites setting the header in October 2021. It should be noted that the vast majority of these set the CORP header to crosssite, which does not provide any additional protection. However, if sites want to use COEP (and thus be able to make use of certain sensitive browser features), all resources that it includes need to set a CORP header. As websites include many third-party resources, many of which they do not have under their control, this will likely complicate the adoption of COEP. To facilitate the deployment of COEP, browser vendors are now experimenting with a credentialless version of COEP, allowing resources that were requested without credentials to be included without a CORP header [16].
