Cross-site leaks

Cross-site leaks, also known as XS-Leaks, are a class of web security vulnerabilities. This class of vulnerabilities allows an attacker to access sensitive information about a user's interactions with other websites. This is done by leveraging long-standing information leakage issues inherent to the design of the web platform, such as the use of CSS attributes or timing information related to the HTTP Cache to reveal a user's previous browsing habits.

The existence of cross-site leaks has been documented as far back as 2000. However, most modern defences against this class of attacks have been introduced relatively recently in the form of extensions to the HTTP protocol, which allow websites to instruct the browser to selectively disallow or annotate certain kinds of stateful cross-origin requests.

Background

Further information: Web security and Same-origin policy

A demonstration of the typical mechanism of a cross-site leak attack

For a web application, or web app, there are two primary components: a web browser and one or more web servers. The web browser typically interacts with the web servers via the HTTP protocol and socket connections to deliver a web application. Certain parts of the web application need to react to user input or other client-side logic; this is done by rendering HTML or CSS or by executing Javascript as part of the process of delivering the website. During this process, the web app transitions between well-defined states.

To isolate different web applications from each other securely, the interactions between the execution contexts of these apps are governed by the same-origin policy. An execution context, in this case, is considered to be equivalent to a web origin. A web application cannot reach into a different web app's execution context and arbitrarily interact with the execution state of the other web application. However, a web application can embed content from other web apps using frames or requests to third-party sites via cross-origin requests. Cross-site leaks allow attackers to break this cross-origin barrier inherent in web application contexts. By leveraging information leakage issues (side channels), an attacker can execute code to infer information about the current state of a different execution context via cross-origin requests or by embedding the victim web app in the attacking web application. This can lead to the attacker accessing information about a user's previous browsing activity.

Mechanism

The threat model of a cross-site leak relies on the attacker being able to direct the victim to a malicious website entirely or partially under the attacker's control. The attacker can accomplish this by compromising a previously good web page, by phishing the user to a web page allowing the attacker to load arbitrary code, or by using a malicious advertisement on an otherwise safe web page.

To perform a cross-site leak, the attacker must identify and include at least one state-dependent URL in the malicious application. This URL must provide at least two different responses depending on the victim application's state. A URL can be crafted, for example, by linking to content that is only accessible to the user if they are logged into the target website. Including this state-dependent URL in the malicious application will initiate a cross-origin request to the target application. Since the request is a cross-origin request, the same-origin policy prevents the attacker from reading the contents of the response. However, using a browser leak method, the attacker can query specific identifiable characteristics of the response, such as the HTTP status code. This allows attackers to distinguish between different responses and gain insight into the victim application's state.

While every method of including a URL in a web page can, in theory, be combined with every browser leak method, this does not work in practice since dependencies exist between different inclusion methods and browser leaks. Certain browser leak methods require specific inclusion techniques to succeed. For example, suppose the browser leak method relies on checking CSS attributes such as the width and height of an element. In that case, the inclusion technique must use an HTML element with a width and height property (such as an image element) that changes when a cross-origin request returns an invalid or a differently sized image.

Example

To demonstrate a common scenario of how a cross-site leak attack could occur, an example of a basic Python-based web application with a search endpoint interface implemented using the following Jinja template is taken.

<html lang="en">
<body>
   <h2>Search results</h2>
   {% for result in results %}
   <div class="result">
      <img src="//cdn.com/result-icon.png" />
      {% result.description %}
   </div>
   {% endfor %}
</body>
</html>

The underlying application authenticates the user based on the cookies attached to the request and performs a textual search on the user's private information based on a string provided in a GET parameter. For every result returned, an icon that is loaded from a Content Delivery Network (CDN) is shown alongside the result.

However, this simple functionality is vulnerable to a cross-leak attack, as shown by the following JavaScript snippet.

let icon_url = 'https://cdn.com/result-icon.png';
iframe.src = 'https://service.com/?q=password';
iframe.onload = async () => {
     const start = performance.now();
     await fetch(icon_url);
     const duration = performance.now() - start;
     if (duration < 5) // loaded resource from cache
         console.log('Query had results');
     else
         console.log("No results for query parameter");
};

This JavaScript snippet, which can be embedded in an attacker-controlled web application, loads the victim web application inside an iframe, waits for the document to load and subsequently requests the icon from the CDN. The attacker can determine if the icon was cached by timing how long it takes to return it. Since the icon will only be cached iff the victim application returns at least one result, the attacker can determine if the victim application returned any results for the given query.

History

Cross-site leaks, interchangeably called XS-Leaks, have existed for over 23 years (as of 2023). There are research papers dating as far back as 2000 from Purdue University that describe a theoretical attack that leverages the HTTP cache to compromise the privacy of a user's browsing habits. In 2007, Andrew Bortz and Dan Boneh from Stanford University published a white paper detailing an attack that leveraged the use of timing information to determine the size of cross-site responses. In 2015, researchers from the Bar Ilan University detailed an attack called a cross-site search attack which used similar leaking methods but used an amplification technique, where the input was crafted in a manner so as to grow the size of the responses extensively. This subsequently led to a proportional growth in the time taken to generate the said responses, thus increasing the accuracy of the attack.

Over the years, independent security researchers have published blog posts detailing various cross-site leak attacks against real-world applications. In 2009, Chris Evans detailed an attack against Yahoo! Mail via which a malicious site could search a user's inbox for sensitive information. More recently, in 2018, Luan Herrara detailed a security exploit that allowed them to exfiltrate data about security sensitive issues using the search functionality of Google's Monorail bug tracker that is actively used by open-source projects such as Chromium, Angle and Skia. In 2019, Terjanq, a Polish security researcher published a blog post detailing a cross-site search attack that allowed them to exfiltrate sensitive user information across multiple high-profile Google products.

As part of its increased focus on dealing with security issues that hinge on misusing long-standing web-platform features, Google launched the XSLeaks Wiki in 2020, an attempt to create an open-knowledge database analyzing and compiling information about cross-site leak attacks.

Recently, there has been some interest amongst the academic security community to standardize these attacks. In 2020, Sudhodanan et al. systematically summarized previous work in cross-site leaks and developed a tool called BASTA-COSI that could be used to detect leaky URLs for a specific website. In 2021, Knittel et al. proposed a formal model to evaluate and characterize cross-site leaks, allowing them to find multiple new leaks across various browsers. In 2022, Van Goethem et al. extended the model to include the concept of components and evaluated currently available defences against these attacks. In 2023, a paper published by Rautenstrauch et al. systemizing previous research into cross-site leaks was awarded the Distinguished Paper Award at the IEEE Symposium of Security and Privacy.

Types

Cross-site leaks are a highly diverse class of attacks. As a result, no formal, consistent classification of cross-site leaks exist. Instead, most cross-site leaks tend to be grouped based on the different leak techniques used to perform the specific attack. As of 2021, over 38 different leak techniques have been found targetting various components in the browser and new ones continue to be found as a result of changes in web platform APIs. While a majority of them rely on directly detecting state changes in the victim web application, specific newer and older attacks also leverage changes in shared components in the browser to infer information about the victim web application indirectly.

Timing attacks

Timing attacks are a subset of cross-site leaks that rely on being able to time specific events across multiple responses. These are one of the oldest types of cross-site leak attacks currently known, being initially discovered by researchers at Stanford University in 2007.

While initially used only to differentiate between the amount of time it took for an HTTP request to resolve a response, recent research has shown the application of this leak technique to detect other differences across web app states. In 2017, Vila et al. showed that timing attacks could infer cross-origin execution times across embedded contexts. This was made possible by a lack of site-isolation features amongst browsers at that time, which allowed for the ability to slow down and amplify timing differences caused by differences in the amount of Javascript being executed when events were sent to a victim web app.

More recently, in 2021, Knittel et al. showed that the Performance API could leak the presence or absence of redirects in responses. This was possible due to a bug in the Performance API that allowed for the amount of time shown to the user to be negative when a redirect occurred. Google Chrome subsequently fixed this bug. In 2023, Snyder et al. showed that timing attacks could be used to perform "pool party" attacks, where websites could block specific shared resources by exhausting their global quota. By having the victim web app execute Javascript that then used these shared resources and then timing how long these executions took, the researchers were able to reveal information about the specific states a web app was in.

Error events

Error events are a leak technique that allows an attacker to distinguish between multiple responses by registering various error event handlers and listening for events via those handlers. Due to their versatility and ability to leak a wide range of information, they are considered a classic cross-site leak vector.

One of the most common use cases for error events in cross-site leak attacks is determining HTTP responses. This can be done by attaching the onload and onerror event handlers to a specific HTML element and then waiting for specific error events to occur. A lack of error events indicates that no HTTP errors occurred. In contrast, if the onerror handler is triggered with a specific error event, the attacker can then use that information to distinguish between various HTTP content types, status codes and media type errors. In 2019, researchers from TU Darmstadt showed that this particular leak technique could be used to perform a fine-grained deanonymization attack against users of multiple popular web services such as the likes of Dropbox, Google Docs, and Github which allowed users to share arbitrary content amongst each other.

In more recent years, the capabilities of error events have been expanded. In 2020, Janc et al. showed that by setting the redirect mode for a fetch request to manual, a website could leak whether a specific URL was a redirect. Around the same time, Jon Masas and Luan Herrara showed that by abusing various URL-related limits, an attacker could trigger error events, which could also be used to leak redirect information about specific URLs. In 2021, Knittel et al. showed that error events generated due to a sub-resource integrity check, a mechanism used to confirm that a particular sub-resource loaded by a website has not been changed or compromised, could also be used to guess the raw content of an HTTP response as well as leak the content length of the response.

Cache timing attacks

Cache timing attacks are a subset of timing attacks that rely on being able to infer hits and misses in various shared caches on the web platform. One of the first instances of a cache timing attack involved making a cross-origin request to a specific page and then probing for the existence of the resources loaded by the request in the shared HTTP and the DNS cache. The paper describing the attack, authored by researchers at Purdue University in 2000, also explores the ability of the attack to leak a large portion of a user's browsing history by selectively checking if specific resources unique to a particular domain had been loaded.

Over the years, this attack has become increasingly sophisticated, allowing for the leakage of other types of information. In 2014, Jia et al. showed that this attack could geo-locate a person's location by measuring the time it took for the specific localized domain of a group of multinational websites to load. In 2015, Van Goethem et al. showed that using the then newly introduced Application Cache, a website could instruct the browser to disregard and override any caching directive sent by the victim website. Further, the paper demonstrated that by timing the cache access, a website could gain information about the size of the cached response.

Global limits

Global limits are an example of a leak technique that does not rely directly on a specific state of the victim web application. It is a new kind of cross-site leak, first discovered by Knittel et al. in 2020 and then later expanded by Knittel et al. in 2023. The attack relies on abusing particular global operating system or hardware limitations to starve specific shared resources. A few examples of global limits that could be abused include the total number of raw socket connections that can be registered and the number of service workers that can be registered. An attacker can infer if the victim website is in a specific state by performing an activity that triggers these global limits and comparing any differences in browser behaviour when the same activity is performed without the victim website loaded.

Defences

Despite being known about since 2000, most defences against cross-site leaks have been introduced relatively recently. Before the introduction of these defences, websites had two options to defend against cross-site leaks. The first was ensuring that the same response was returned for all application states, thwarting the attacker's ability to tell the requests apart. However, this approach was infeasible for any non-trivial website. The second approach was to create session-specific URLs that would not work outside of a user's specific session. This approach would limit link sharing and thus was infeasible and impractical.

Most modern defences against cross-site leaks are extensions to the HTTP protocol that either prevent state changes, make cross-origin requests stateless, or completely isolate shared resources across multiple origins.

Completely isolating shared resources

One of the earliest and most well-known methods of performing cross-site leaks was using the HTTP Cache. This approach relied on querying the browser cache for unique resources that a victim's website might have loaded. By measuring the time it took for a cross-origin request to resolve an attacking website, one could determine if the resource was cached and, if so, which state the victim application was in. However, as of October 2020, most browsers have implemented HTTP Cache partitioning, drastically reducing the effectiveness of this approach. HTTP Cache partitioning works by multi-keying each cached request based on which website requested the resource. This means that if victim.com loads a resource and caches it, attacker.com will not be able to infer if the resource has been cached, and the request will instead always be treated as a cache miss unless attacker.com has previously cached the same request.

Another, more developer-oriented feature that allows the isolation of execution contexts includes the Cross-Origin-Opener-Policy (COOP) header, which was originally added to address Spectre issues in the browser. It has proved useful for preventing cross-site leaks since if the header is set with a same-origin directive as part of the response, the browser will disallow cross-origin websites from being able to hold a reference to the defending website when it is opened from a third-party page.

In addition to this, as part of a recent effort to mitigate cross-site leaks, Chrome, Brave, Microsoft Edge Firefox and Safari committed to implementing storage partitioning. This feature will allow all shared resources used by each site to be multi-keyed, thereby dramatically reducing the number of inclusion techniques that can infer the states of a web application.

Preventing state changes

Cross-site leak attacks depend on the ability of the malicious web page to receive cross-origin responses from the victim application. By preventing the malicious application from being able to receive the cross-origin responses in the first place, the user is no longer in danger of having the state changes leaked. This approach is seen in defences such as the deprecated X-Frame-Options header as well as the newer frame-ancestors directive in Content-Security Policy headers, which allow the victim application to specify which websites can include it as an embedded frame. By disallowing the embedding of the website in untrusted contexts, the malicious app can no longer observe the response to the cross-origin requests made to the victim application using the embedded frame technique.

A similar approach is taken by the Cross-Origin Resource Blocking (CORB) mechanism as well as the Cross-Origin-Resource-Policy (CORP) header, which allows a cross-origin request to succeed but blocks the loading of the content in third-party websites if there is a mismatch between the content type that was expected and the content type that was received. While this feature was originally introduced as part of a series of mitigations against the Spectre vulnerability, it has proved useful in preventing cross-origin leaks since it blocks the malicious web page from receiving the response and thus inferring state changes.

Making cross-origin requests stateless

One of the most effective approaches to mitigate cross-site leaks has been using the SameSite parameter in cookies. Once set to Lax or Strict, this parameter prevents the browser from sending cookies in most third-party requests, effectively making the request stateless. However, adoption of Same-Site cookies has been slow due to it requiring changes in the way many specialized web servers, such as authentication providers operate. In 2020, Chrome and Firefox announced that they would be turning on SameSite=Lax as the default state for cookies across all platforms. However, despite this, there are still certain cases where SameSite=Lax cookies are not respected, such as the LAX+POST mitigation by Chrome which allows a cross-origin site to use a SameSite=Lax cookie in a request iff the request is sent while navigating the page and it occurs within two minutes of the cookie being set. This has led to bypasses and workaround being found against the SameSite=Lax limitation that allow cross-site leaks to still occur.

Another approach to mitigating cross-site leaks has been using Fetch metadata headers. These headers include the Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-User and Sec-Fetch-Dest header, which provides information about the domain that initiated the request, details about how the request was initiated, and the destination of the request respectively to the defending web server. This allows the web server to distinguish between legitimate third-party, same-site requests and harmful cross-origin requests. By discriminating between these requests, the server can send a stateless response to malicious third-party requests and a stateful response to routine same-site requests. To prevent the abusive use of these headers, a web application is not allowed to set these headers, and they must instead only be set by the browser.

See also

• Cross origin resource sharing
• Same origin policy
• Cross-site scripting
• Cross-site request forgery

References

Sources

• Knittel, Lukas; Mainka, Christian; Niemietz, Marcus; Noß, Dominik Trevor; Schwenk, Jörg (2021-11-12). "XSinator.com: From a Formal Model to the Automatic Evaluation of Cross-Site Leaks in Web Browsers". Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. Association for Computing Machinery. pp. 1771–1788. doi:10.1145/3460120.3484739. ISBN 978-1-4503-8454-4. S2CID 244077807.
• Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (2022-05-30). "SoK: Exploring Current and Future Research Directions on XS-Leaks through an Extended Formal Model". Proceedings of the 2022 ACM on Asia Conference on Computer and Communications Security. Association for Computing Machinery. pp. 784–798. doi:10.1145/3488932.3517416. ISBN 978-1-4503-9140-5. S2CID 248990284. This article incorporates text by Tom Van Goethem, Gertjan Franken, Iskander Sanchez-Rola, David Dworken and Wouter Joosen available under the CC BY 4.0 license.
• Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (September 6, 2021). Understanding Cross-site Leaks and Defenses (PDF). 2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P), SecWeb Workshop Proceedings. p. 1. Archived (PDF) from the original on October 11, 2023. Retrieved October 11, 2023.
• Rautenstrauch, Jannis; Pellegrino, Giancarlo; Stock, Ben (2023-05-21). "The Leaky Web: Automated Discovery of Cross-Site Information Leaks in Browsers and the Web". 2023 IEEE Symposium on Security and Privacy (SP). IEEE. pp. 2744–2760. doi:10.1109/SP46215.2023.10179311. ISBN 978-1-6654-9336-9. S2CID 259321089 – via CISPA – Helmholtz Center for Information Security Publication Database.
• Sudhodanan, Avinash; Khodayari, Soheil; Caballero, Juan (2020). "Cross-Origin State Inference (COSI) Attacks: Leaking Web Site States through XS-Leaks". Proceedings 2020 Network and Distributed System Security Symposium. Internet Society. doi:10.14722/ndss.2020.24278. ISBN 978-1-891562-61-7. S2CID 199452779.
• Felten, Edward W.; Schneider, Michael A. (2000-11-01). "Timing attacks on Web privacy". Proceedings of the 7th ACM conference on Computer and Communications Security. Association for Computing Machinery. pp. 25–32. doi:10.1145/352600.352606. ISBN 978-1-58113-203-8. S2CID 456809.
• Bortz, Andrew; Boneh, Dan (2007-05-08). "Exposing private information by timing web applications". Proceedings of the 16th international conference on World Wide Web. WWW '07. Association for Computing Machinery. pp. 621–628. doi:10.1145/1242572.1242656. ISBN 978-1-59593-654-7. S2CID 7399871.
• Gelernter, Nethanel; Herzberg, Amir (2015-10-12). "Cross-Site Search Attacks". Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. CCS '15. Association for Computing Machinery. pp. 1394–1405. doi:10.1145/2810103.2813688. ISBN 978-1-4503-3832-5. S2CID 14924784.
• Schwenk, Jörg; Niemietz, Marcus; Mainka, Christian (2017). {Same-Origin} Policy: Evaluation in Modern Browsers. USENIX Association. pp. 713–727. ISBN 978-1-931971-40-9. S2CID 9641053.
• Zaheri, Mojtaba; Curtmola, Reza (2021). "Leakuidator: Leaky Resource Attacks and Countermeasures". In Garcia-Alfaro, Joaquin; Li, Shujun; Poovendran, Radha; Debar, Hervé; Yung, Moti (eds.). Security and Privacy in Communication Networks. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering. Vol. 399. Springer International Publishing. pp. 143–163. doi:10.1007/978-3-030-90022-9_8. ISBN 978-3-030-90022-9. S2CID 237476137.
• Mishra, Vikas; Laperdrix, Pierre; Rudametkin, Walter; Rouvoy, Romain (2021). "Déjà vu: Abusing Browser Cache Headers to Identify and Track Online Users". Proceedings on Privacy Enhancing Technologies. 2021 (2): 391–406. doi:10.2478/popets-2021-0033. ISSN 2299-0984. S2CID 231779262. Archived from the original on 2023-10-29. Retrieved 2023-10-29.
• Doan, Trinh Viet; van Rijswijk-Deij, Roland; Hohlfeld, Oliver; Bajpai, Vaibhav (2022-02-12). "An Empirical View on Consolidation of the Web". ACM Transactions on Internet Technology. 22 (3): 70:1–70:30. doi:10.1145/3503158. ISSN 1533-5399. S2CID 246803043. While recent browser implementations [69, 113] address this problem by HTTP Cache Partitioning, this fix results in larger traffic volume and higher load times, as cached resources are re-fetched if they are requested in a different context.
• Reis, Charles; Moshchuk, Alexander; Oskov, Nasko (2019). "Site Isolation: Process Separation for Web Sites within the Browser". SEC'19: Proceedings of the 28th USENIX Conference on Security Symposium. USENIX Association. pp. 1661–1678. ISBN 978-1-939133-06-9. Archived from the original on 2023-11-07. Retrieved 2023-11-07.
• Van Goethem, Tom; Sanchez-Rola, Iskander; Joosen, Wouter (2023). "Scripted Henchmen: Leveraging XS-Leaks for Cross-Site Vulnerability Detection". 2023 IEEE Security and Privacy Workshops (SPW). IEEE. pp. 371–383. doi:10.1109/SPW59333.2023.00038. ISBN 979-8-3503-1236-2. S2CID 259267534. Retrieved 2023-11-07.
• Calzavara, Stefano; Roth, Sebastian; Rabitti, Alvise; Backes, Michael; Stock, Ben (2020). "A Tale of Two Headers: A Formal Analysis of Inconsistent {Click-Jacking} Protection on the Web". SEC'20: Proceedings of the 29th USENIX Conference on Security Symposium: 683–697. ISBN 978-1-939133-17-5.
• Khodayari, Soheil; Pellegrino, Giancarlo (2022). "The State of the SameSite: Studying the Usage, Effectiveness, and Adequacy of SameSite Cookies". 2022 IEEE Symposium on Security and Privacy (SP). IEEE. pp. 1590–1607. doi:10.1109/SP46214.2022.9833637. ISBN 978-1-6654-1316-9. S2CID 251140677.
• Beer, Philip; Veronese, Lorenzo; Squarcina, Marco; Lindorfer, Martina (September 6, 2021). The Bridge between Web Applications and Mobile Platforms is Still Broken (PDF). 2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P), SecWeb Workshop Proceedings. Archived (PDF) from the original on November 7, 2023. Retrieved November 7, 2023. The Fetch Metadata HTTP request headers [45] are a set of HTTP headers that provide the context of the HTTP request to the server. The server can use the context to determine whether the request is malicious or it should be allowed.
• Vila, Pepe; Köpf, Boris (2017). "Loophole: Timing Attacks on Shared Event Loops in Chrome". SEC'17: Proceedings of the 26th USENIX Conference on Security Symposium: 849–864. ISBN 978-1-931971-40-9.
• Snyder, Peter; Karami, Soroush; Edelstein, Arthur; Livshits, Benjamin; Haddadi, Hamed (2023-10-26). "Pool-party: exploiting browser resource pools for web tracking". Proceedings of the 32nd USENIX Conference on Security Symposium. SEC '23. USA: USENIX Association: 7091–7105. ISBN 978-1-939133-37-3.
• Staicu, Cristian-Alexandru; Pradel, Michael (2019). "Leaky Images: Targeted Privacy Attacks in the Web". Proceedings of the 28th USENIX Conference on Security Symposium. SEC '19: 923–939. ISBN 978-1-939133-06-9.
• Jia, Yaoqi; Dong, Xinshu; Liang, Zhenkai; Saxena, Prateek (2015-01-01). "I Know Where You've Been: Geo-Inference Attacks via the Browser Cache". IEEE Internet Computing. 19 (1): 44–53. doi:10.1109/MIC.2014.103. ISSN 1089-7801.
• Zaheri, Mojtaba; Oren, Yossi; Curtmola, Reza (2022). "Targeted Deanonymization via the Cache Side Channel: Attacks and Defenses". Proceedings of the 31th USENIX Conference on Security Symposium. SEC '22: 1505–1523. ISBN 978-1-939133-31-1.
• Bansal, Chetan; Preibusch, Sören; Milic-Frayling, Natasa (2015). Federrath, Hannes; Gollmann, Dieter (eds.). "Cache Timing Attacks Revisited: Efficient and Repeatable Browser History, OS and Network Sniffing". ICT Systems Security and Privacy Protection. IFIP Advances in Information and Communication Technology. Cham: Springer International Publishing: 97–111. doi:10.1007/978-3-319-18467-8_7. ISBN 978-3-319-18467-8.

External links

• "XSLeaks Wiki - Introduction". xsleaks.dev.
• "XSinator - XS-Leak Browser Test Suite". xsinator.com.