of all endpoints (spread across 14% of services) were deemed to need an exempted policy of unsafe-none, as these relied on crosssite interactions. For another 14% of services, the COOP header on all endpoints needed to be relaxed to same-origin-allow-popups in order to allow these single-page applications to interact with windows opened as popups, e.g. for authentication. For RIP, ~3% of all endpoints (representing 8% of services) needed an exemption. Given that only a minority of services required an exemption of the policy, this is encouraging for future work that aims to enable policies by default. Nevertheless, the fraction of exempted endpoints remains non-negligible, and additional research is needed to determine how these endpoints can be further protected, possibly with a more fine-grained policy.
Leakbuster
Although the adoption of XS-Leak defenses is steadily growing, sites that deploy them only represent a minute fraction of the web: 0.84% for CORP, 0.16% for COOP, and 0.02% for COEP. A possible reason for this low adoption rate is that XS-Leaks are still not widely known or understood. Furthermore, given the extensive number of defenses, and various intricacies that need to be considered to deploy a complete solution, it may be hard for web developers to decide which defenses need to be deployed, and whether there are any alternatives. To tackle these issues, and facilitate the deployment of defenses, we introduce Leakbuster as a dynamic web interface4 . The tool is based on our model, the classification of attacks, and the expressions that capture which attacks are thwarted by certain defenses. Upon entering the values for the relevant security headers and policies, web developers will be presented with a list of XS-Leak attacks they are still susceptible to along with a list of prioritized suggestions. By following the recommendations of Leakbuster, website owners will be able to protect their users to the best extent possible.
8.3
9
RELATED WORK
Most closely related to our work, is the concurrent work by Knittel et al. [18], who also introduce a formal model. Via a preprint provided to us by the authors, we detected many similarities in both models, and chose to adopt the same formulation for reasons of consistency. By introducing the concept of stateful “components”, we are able to better capture the underlying characteristics that cause XS-Leaks, and use that to propose a methodology to identify new vulnerabilities, or ensure the absence thereof. Knittel et al. also perform an evaluation of different browsers and identify several novel XS-Leak attacks as a result of their analysis. Other works that provide an extensive overview of XS-Leaks, is the research by Sudhodanan et al. [49] and the XS-Leaks wiki [46]. These works mainly focus on the type of information that can be inferred, and introduce classes that are mainly descriptive of how an attack is performed. In our work, we introduce an extended model that abstracts away from the specific technicalities of the different attacks, allowing us to capture the intrinsic characteristics. Furthermore, we leverage this model to analyze XS-Leak defenses, categorizing these according to three main strategies. For an overview of known XS-Leaks attacks, we refer to the classification in Table 1, with an accompanying summary of each attack in Appendix A. In the context of violations to the same-origin policy, Schwenk et al. evaluated the implementation of the same-origin policy in different browsers and detect varying browser behavior because of the lack of a formal specification [40]. Other violations of the same-origin policy have been explored by Somé, who found that the permissions of browser extensions could be leveraged to leak data across site-boundaries [45]. Schuster et al. present an attack where contention on the network layer is abused to infer which videos are being played by the user based on the bursts on the network [39]. We believe that this technique could potentially also be used as an XS-Leak, to infer information about web pages. Finally, Franken et al. explored how same-origin policy violations could be abused in browser engines that are used to display e-books [8]. A related research topic that often leverages similar techniques as XS-Leak attacks, is history sniffing. In contrast to XS-Leaks, history leaks aim to infer the state that is retained in the browser by a prior visit of the user, and thus the state-introduction occurs inadvertently (and is not initiated by the attacker). The state-retrieval stage can be very similar to XS-Leak attacks. For instance, an adversary can
Challenges of adoption
As we discussed in Section 7.2, website are still facing several challenges when trying to adopt XS-Leak defenses, especially when the website wants to support cross-site interactions. In this section we elaborate on these challenges based on a case-study of a large technology company that deployed COOP and RIP based on Fetch Metadata across 500+ services, serving over a billion users. The information and insights presented here were obtained by working and discussing with the team that deployed these defenses. When a web application is published, other sites may (legitimately) interact with it in ways that are not clear to the web developers; e.g. other sites might want to open the application in a pop-up and close this pop-up after some time. If the web application would set a COOP policy, this behavior would break as the embedding web site would not be able to close the pop-up. As a result, just setting an enforcing policy could interfere with intended behavior and deteriorate users’ browsing experience. To overcome this challenge, it is generally advised to gradually roll out a defense and first enable a report-only version of the defense; these are available for both COOP and COEP, and as Fetch Metadata is enforced on the server side, it is possible to generate reports when a violation occurs. Unfortunately, the reporting of COOP violations is not complete, as this could possibly leak additional information in specific cases. We document these reporting gaps in Appendix B. We believe that further research on this topic is needed to ensure that the violations captured in report-only mode match those that would occur in the enforcing mode. This is necessary for web developers to reliably determine which violations could still occur when switching to an enforcing policy. In our case study, violations of COOP and RIP were captured for several weeks in a report-only mode. Surprisingly, in contrast to CSP violations, which are known to be very noisy [21], the unintended violations were fairly limited, and were mainly due to browser extensions or JavaScript libraries that would interact with window.opener. After filtering these undesirable interactions, ~2% 4 https://distrinet.github.io/leakbuster/.
794
