Cross-site leaks

Cross-site leaks, also known as XS-leaks, is an internet security term used to describe a class of attacks used to access a user's sensitive information on another website. Cross-site leaks allow an attacker to access a user's interactions with other websites. This can contain sensitive information. Web browsers normally stop other websites from seeing this information. This is enforced through a set of rules called the same-origin policy. Attackers can sometimes get around these rules, using a "cross-site leak". Attacks using a cross-site leak are often initiated by enticing users to visit the attacker's website. Upon visiting, the attacker uses malicious code on their website to interact with another website. This can be used by a attacker to learn about the user's previous actions on the other website. The information from this attack can uniquely identify the user to the attacker.

These attacks have been documented since 2000. One of the first research papers on the topic was published by researchers at Purdue University. The paper described an attack where the web cache was exploited to gather information about a website. Since then, cross-site leaks have become increasingly sophisticated. Researchers have found newer leaks targeting various web browser components. While the efficacy of some of these techniques varies, newer techniques are continually being discovered. Some older methods are blocked through updates to browser software. The introduction and removal of features on the Internet also lead to some attacks being rendered ineffective.

Cross-site leaks are a diverse form of attack, and there is no consistent classification of such attacks. Multiple sources classify cross-site leaks by the technique used to leak information. Among the well-known cross-site leaks are timing attacks, which depend on timing events within the web browser. Error events constitute another category, using the presence or absence of events to disclose data. Additionally, cache-timing attacks rely on the web cache to unveil information. Since 2023, newer attacks that use operating systems and web browser limits to leak information have also been found.

Before 2017, defending against cross-site leaks was considered to be difficult. This was because many of the information leakage issues exploited by cross-site leak attacks were inherent to the way websites worked. Most defences against this class of attacks have been introduced after 2017 in the form of extensions to the hypertext transfer protocol (HTTP). These extensions allow websites to instruct the browser to disallow or annotate certain kinds of stateful requests coming from other websites. One of the most successful approaches browsers have implemented is SameSite cookies. SameSite cookies allow websites to set a directive that prevents other websites from accessing and sending sensitive cookies. Another defence involves using HTTP headers to restrict which websites can embed a particular site. Cache partitioning also serves as a defence against cross-site leaks, preventing other websites from using the web cache to exfiltrate data.

Background

Further information: Same-origin policy and Cross-origin resource sharing

Web applications (web apps) have two primary components: a web browser and one or more web servers. The browser typically interacts with the servers via hyper text transfer protocol (HTTP) and WebSocket connections to deliver a web app.^{[note 1]} To make the web app interactive, the browser also renders HTML and CSS, and executes JavaScript code provided by the web app. These elements allow the web app to react to user inputs and run client-side logic.^[2] Often, users interact with the web app over long periods of time, making multiple requests to the server. To keep track of such requests, web apps often use a persistent identifier tied to a specific user through their current session or user account.^[3] This identifier can include details like age or access level, which reflect the user's history with the web app. If revealed to other websites, these identifiable attributes might deanonymize the user.^[4]

Ideally, each web app should operate independently without interfering with others. However, due to various design choices made during the early years of the web, web apps can regularly interact with each other.^[5] To prevent the abuse of this behavior, web browsers enforce a set of rules called the same-origin policy that limits direct interactions between web applications from different sources.^[6][7] Despite these restrictions, web apps often need to load content from external sources, such as instructions for displaying elements on a page, design layouts, and videos or images. These types of interactions, called cross-origin requests, are exceptions to the same-origin policy.^[8] They are governed by a set of strict rules known as the cross-origin resource sharing (CORS) framework. CORS ensures that such interactions occur under controlled conditions by preventing unauthorized access to data that a web app is not allowed to see. This is achieved by requiring explicit permission before other websites can access the contents of these requests.^[9]

Cross-site leaks allow attackers to circumvent the restrictions imposed by the same-origin policy and the CORS framework. They leverage information-leakage issues (side channels) that have historically been present in browsers. Using these side channels, an attacker can execute code that can infer details about data that the same origin policy would have shielded.^[10] This data can then be used to reveal information about a user's previous interactions with a web app.^[11]

Mechanism

• 
  In the absence of a third party, the user's browser sends the web server an HTTP request. The server sends a response dependent on the nature of the request.
• 
  An attacker identifies a vulnerable URL and phishes the user to their website using an email. When the user goes to the attacker's website, the attacker can make malicious requests to the web server using the vulnerable URL.
• 
  The attacker is prevented from reading the web server's response. However, other factors like the response time or size can be measured by the attacker, leaking information about the response – a side-channel attack.

To carry out a cross-site leak attack, an attacker must first study how a website interacts with users. They need to identify a specific URL that produces different Hyper Text Transfer Protocol (HTTP) responses based on the user's past actions on the site.^[12][13] For instance, if the attacker is trying to attack Gmail, they could try to find a search URL that returns a different HTTP response based on how many search results are found for a specific search term in a user's emails.^[14] Once an attacker finds a specific URL, they can then host a website and phish or otherwise lure unsuspecting users to the website. Once the victim is on the attacker's website, the attacker can use various embedding techniques to initiate cross-origin HTTP requests to the URL identified by the attacker.^[15] However, since the attacker is on a different website, the same-origin policy imposed by the web browser will prevent the attacker from directly reading any part of the response sent by the vulnerable website.^{[note 2][16]}

To circumvent this security barrier, the attacker can use browser-leak methods, to distinguish subtle differences between different responses. Browser leak methods are JavaScript, CSS or HTML snippets that leverage long-standing information leakage issues (side channels) in the web browser to reveal specific characteristics about a HTTP response.^[12][13] In the case of Gmail, the attacker could use JavaScript to time how long the browser took to parse the HTTP response returned by the search result. If the time taken to parse the response returned by the endpoint was low, the attacker could infer that there were no search results for their query. Alternatively, if the site took longer, the attacker could infer that multiple search results were returned.^[14] The attacker can subsequently use the information gained through these information leakages to exfiltrate sensitive information, which can be used to track and deanonymize the victim.^[15] In the case of Gmail, the attacker could make a request to the search endpoint with a query and subsequently measure the time the query took to figure out whether or not the user had any emails containing a specific query string.^{[note 3]} If a response takes very little time to be processed, the attacker can assume that no search results were returned. Conversely, if a response takes a large amount amount of time to be processed, the attacker infer that a lot of search results were returned. By making multiple requests, an attacker could gain significant insight into the current state of the victim application, potentially revealing private information of a user, helping launch sophisticated spamming and phishing attacks.^[17]

History

Cross-site leaks have been known about since 2000;^[18] research papers dating from that year from Purdue University describe a theoretical attack that uses the HTTP cache to compromise the privacy of a user's browsing habits.^[19] In 2007, Andrew Bortz and Dan Boneh from Stanford University published a white paper detailing an attack that made use of timing information to determine the size of cross-site responses.^[20] In 2015, researchers from Bar-Ilan University described a cross-site search attack that used similar leaking methods. The attack employed a technique in which the input was crafted to grow the size of the responses, leading to a proportional growth in the time taken to generate the responses, thus increasing the attack's accuracy.^[21]

Independent security researchers have published blog posts describing cross-site leak attacks against real-world applications. In 2009, Chris Evans described an attack against Yahoo! Mail via which a malicious site could search a user's inbox for sensitive information.^[22] In 2018, Luan Herrara found a cross-site leak vulnerability in Google's Monorail bug tracker, which is used by projects like Chromium, Angle, and Skia Graphics Engine. This exploit allowed Herrara to exfiltrate data about sensitive security issues by abusing the search endpoint of the bug tracker.^[23][24] In 2019, Terjanq, a Polish security researcher, published a blog post describing a cross-site search attack that allowed them to exfiltrate sensitive user information across high-profile Google products.^[25][26]

As part of its increased focus on dealing with security issues that depend on misusing long-standing web-platform features, Google launched XSLeaks Wiki in 2020. The initiative aimed to create an open-knowledge database about web-platform features that were being misused and analysing and compiling information about cross-site leak attacks.^[22][27][28]

Since 2020, there has been some interest among the academic security community in standardizing the classification of these attacks. In 2020, Sudhodanan et al. were among the first to systematically summarize previous work in cross-site leaks, and developed a tool called BASTA-COSI that could be used to detect leaky URLs.^[28][29] In 2021, Knittel et al. proposed a new formal model to evaluate and characterize cross-site leaks, allowing the researchers to find new leaks affecting several browsers.^[28][30] In 2022, Van Goethem et al. evaluated currently available defences against these attacks and extended the existing model to consider the state of browser components as part of the model.^[28][13] 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 on Security and Privacy.^[31]

Threat model

The threat model of a cross-site leak relies on the attacker being able to direct the victim to a malicious website that is at least partially under the attacker's control. The attacker can accomplish this by compromising a web page, by phishing the user to a web page and loading arbitrary code, or by using a malicious advertisement on an otherwise-safe web page.^[32][33]

Cross site leak attacks require that the attacker identify at least one state-dependent URL in the victim app for use in the attack app. Depending on the victim app's state, this URL must provide at least two responses. 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 app.^[15] Because the request is a cross-origin request, the same-origin policy prevents the attacker from reading the contents of the response. Using a browser-leak method, however, the attacker can query specific identifiable characteristics of the response, such as the HTTP status code. This allows the attacker to distinguish between responses and gain insight into the victim app's state.^[12][13]

While every method of initiating a cross-origin request to a URL in a web page can be combined with every browser-leak method, this does not work in practice because dependencies exist between different inclusion methods and browser leaks. Some browser-leak methods require specific inclusion techniques to succeed.^[34] For example, if the browser-leak method relies on checking CSS attributes such as the width and height of an element, 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.^[35][36]

Types

Cross-site leaks comprise a highly varied range of attacks^[37] for which there is no established, uniform classification.^[38] However, multiple sources typically categorized these attacks by the leaking techniques used during an attack.^[34] As of 2021^[update], researchers have identified over 38 leak techniques that target components of the browser.^[32] New techniques are typically discovered due to changes in web platform APIs, which are JavaScript interfaces that allow websites to query the browser for specific information.^[39] Although the majority of these techniques involve directly detecting state changes in the victim web app, some attacks also exploit alterations in shared components within the browser to indirectly glean information about the victim web app.^[34]

Timing attacks

Timing attacks rely on the ability to time specific events across multiple responses.^[40] These were discovered by researchers at Stanford University in 2007, making them one of the oldest-known types of cross-site leak attacks.^[20]

While initially used only to differentiate between the time it took for a HTTP request to resolve a response,^[20] research performed after 2007 has demonstrated the use of this leak technique to detect other differences across web-app states. In 2017, Vila et al. showed timing attacks could infer cross-origin execution times across embedded contexts. This was made possible by a lack of site isolation features in contemporaneous browsers, which allowed an attacking website 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.^[41][42]

In 2021, Knittel et al. showed the Performance API^{[note 4]} could leak the presence or absence of redirects in responses. This was possible due to a bug in the Performance API that allowed the amount of time shown to the user to be negative when a redirect occurred. Google Chrome subsequently fixed this bug.^[44] In 2023, Snyder et al. showed timing attacks could be used to perform pool-party attacks in which websites could block shared resources by exhausting their global quota. By making the victim web app execute JavaScript that used these shared resources and then timing how long these executions took, the researchers were able to reveal information about the state of a web app.^[45]

Error events

Error events is a leak technique that allows an attacker to distinguish between multiple responses by registering error-event handlers and listening for events through them. Due to their versatility and ability to leak a wide range of information, error events are considered a classic cross-site leak vector.^[46]

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

Since 2019, the capabilities of error events have been expanded. In 2020, Janc et al. showed by setting the redirect mode for a fetch request to manual, a website could leak information about whether a specific URL is a redirect.^[50][42] Around the same time, Jon Masas and Luan Herrara showed by abusing URL-related limits, an attacker could trigger error events that could be used to leak redirect information about URLs.^[51] In 2021, Knittel et al. showed error events that are generated by a subresource integrity check, a mechanism that is used to confirm a sub-resource a website loads has not been changed or compromised, could also be used to guess the raw content of an HTTP response and to leak the content-length of the response.^[52][53]

Cache-timing attacks

Cache-timing attacks rely on the ability to infer hits and misses in shared caches on the web platform.^[54] One of the first instances of a cache-timing attack involved the making of a cross-origin request to a 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 was written by researchers at Purdue University in 2000, and describes the attack's ability to leak a large portion of a user's browsing history by selectively checking if resources that are unique to a web page have been loaded.^[55][54][56]

This attack has become increasingly sophisticated, allowing the leakage of other types of information. In 2014, Jia et al. showed this attack could geo-locate a person by measuring the time it takes for the localized domain of a group of multinational websites to load.^[54][57][58] In 2015, Van Goethem et al. showed using the then-newly introduced application cache, a website could instruct the browser to disregard and override any caching directive the victim website sends. The paper also demonstrated a website could gain information about the size of the cached response by timing the cache access.^[59][60]

Global limits

Global limits, which are also known as pool-party attacks, do not directly rely on the state of the victim web app. This cross-site leak was first discovered by Knittel et al. in 2020 and then expanded by Snyder et al. in 2023.^[45] The attack to abuses global operating systems or hardware limitations to starve shared resources.^[61] Global limits that could be abused include the number of raw socket connections that can be registered and the number of service workers that can be registered. An attacker can infer the state of the victim website 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 being loaded.^[62] Since these types of attacks typically also require timing side channels, they are also considered timing attacks.^[45]

Other techniques

In 2019, Gareth Heyes discovered that by setting the URL hash of a website to a specific value and subsequently detecting whether a loss of focus on the current web page occurred, an attacker could determine the presence and position of elements on a victim website.^[63] In 2020, Knittel et al. showed an attacker could leak whether or not a Cross-Origin-Opener-Policy header was set by obtaining a reference to the window object of a victim website by framing the website or by creating a popup of the victim website. Using the same technique of obtaining window references, an attacker could also count the number of frames a victim website had through the window.length property.^[44][64]

While newer techniques continue to be found, older techniques for performing cross-site leaks have become obsolete due to changes in the World Wide Web Consortium (W3C) specifications and updates to browsers. In December 2020, Apple updated its browser Safari's Intelligent Tracking Prevention (ITP) mechanism, rendering a variety of cross-site leak techniques researchers at Google had discovered ineffective.^[65][66][67] Similarly, the widespread introduction of cache partitioning in all major browsers in 2020 has reduced the potency of cache-timing attacks.^[68]

Example

The example of a Python-based web application with a search endpoint interface implemented using the following Jinja template demonstrates a common scenario of how a cross-site leak attack could occur.^[36]

<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>

This code is a template for displaying search results on a webpage. It loops through a collection of results provided by a HTTP server backend and displays each result along with its description inside a structured div element alongside a icon loaded from a different website. The underlying application authenticates the user based on cookies that are attached to the request and performs a textual search of the user's private information using 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.^[32][69]

This simple functionality is vulnerable to a cross-leak attack, as shown by the following JavaScript snippet.^[32]

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 app, loads the victim web app inside an iframe, waits for the document to load and subsequently requests the icon from the CDN. The attacker can determine whether the icon was cached by timing its return. Because the icon will only be cached if and only if the victim app returns at least one result, the attacker can determine whether the victim app returned any results for the given query.^[36][69][26]

Defences

Before 2017, websites could defend against cross-site leaks by ensuring the same response was returned for all application states, thwarting the attacker's ability to differentiate the requests. This approach was infeasible for any non-trivial website. The second approach was to create session-specific URLs that would not work outside a user's session. This approach limited link sharing, and was impractical.^[18][70]

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

Isolating shared resources

Raw data from the cache timing attack discussed in § Example. When cache partitioning is disabled, a clear distinction can be made between the cached and uncached responses, whereas, with cache partitioning, the two response times overlap.^[71]

  cached response

  un-cached response

One of the earliest methods of performing cross-site leaks was using the HTTP cache, an approach that relied on querying the browser cache for unique resources 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 whether the resource was cached and, if so, the state of the victim app.^[69][72] As of October 2020^[update], most browsers have implemented HTTP cache partitioning, drastically reducing the effectiveness of this approach.^[73] HTTP cache partitioning works by multi-keying each cached request depending on which website requested the resource. This means if a website loads and caches a resource, the cached request is linked to a unique key generated from the resource's URL and that of the requesting website. If another website attempts to access the same resource, the request will be treated as a cache miss unless that website has previously cached a identical request. This prevents an attacking website from deducing whether a resource has been cached by a victim website.^[74][75][76]

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.^[77][78] It has proved useful for preventing cross-site leaks because 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.^[79][80][81]

As part of an effort to mitigate cross-site leaks, the developers of all major browsers have implemented storage partitioning,^[82] allowing all shared resources used by each website to be multi-keyed, dramatically reducing the number of inclusion techniques that can infer the states of a web app.^[83]

Preventing state changes

Cross-site leak attacks depend on the ability of a malicious web page to receive cross-origin responses from the victim application. By preventing the malicious application from being able to receive cross-origin responses, the user is no longer in danger of having state changes leaked.^[84] This approach is seen in defences such as the deprecated X-Frame-Options header and 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.^[85] If the victim app disallows the embedding of the website in untrusted contexts, the malicious app can no longer observe the response to cross-origin requests made to the victim app using the embedded frame technique.^[86][87]

A similar approach is taken by the Cross-Origin Resource Blocking (CORB) mechanism and 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 that which was received.^[88] This feature was originally introduced as part of a series of mitigations against the Spectre vulnerability^[89] but it has proved useful in preventing cross-origin leaks because it blocks the malicious web page from receiving the response and thus inferring state changes.^[86][90][91]

Making cross-origin requests stateless

One of the most-effective approaches to mitigating cross-site leaks has been the use of 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.^{[note 5][91]} Adoption of Same-Site cookies, however, has been slow because it requires changes in the way many specialized web servers, such as authentication providers, operate.^[93] In 2020, the makers of the Chrome browser announced they would be turning on SameSite=Lax as the default state for cookies across all platforms.^[94][95] Despite this, there are still cases in which SameSite=Lax cookies are not respected, such as Chrome's LAX+POST mitigation, which allows a cross-origin site to use a SameSite=Lax cookie in a request if and only if the request is sent while navigating the page and it occurs within two minutes of the cookie being set.^[92] This has led to bypasses and workarounds against the SameSite=Lax limitation that still allow cross-site leaks to occur.^[96][97]

Fetch metadata headers, which include the Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-User and Sec-Fetch-Dest header, which provide information about the domain that initiated the request, details about the request's initiation, and the destination of the request respectively to the defending web server, have also been used to mitigate cross-site leak attacks.^[98] These headers 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.^[99] To prevent the abusive use of these headers, a web app is not allowed to set these headers, which must only be set by the browser.^[100][75]

See also

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

References

Notes

1. While there are other possible ways for interactions between web browsers and web servers to occur (such as the WebRTC protocol), in the context of cross-site leaks, only the HTTP interactions and WebSocket connections are considered important.^[1] The rest of the article will assume the HTTP interactions and WebSocket connections are the only two ways for web browsers to interact with web servers.
2. This includes metadata associated with the response like status codes and HTTP headers^[16]
3. An example of such a query could be the name of a well known bank, or the contact information of a person or organization that the user is expected to have interacted with.^[17]
4. The Performance API is a set of Javascript functions that allow websites to retrieve various metrics associated with web performance^[43]
5. Setting the Strict directive ensures that all cross-site requests are stateless, whereas Lax allows the browser to send cookies for non-state changing (i.e. GET or HEAD) requests which are sent while navigating to a different page from the cross-origin page.^[92]

Citations

1. Knittel et al. 2021, pp. 1773, 1776.
2. "How the web works – Learn web development | MDN". MDN Web Docs. 24 July 2023. Archived from the original on 24 September 2023. Retrieved 1 October 2023.
3. Wagner, David; Weaver, Nicholas; Kao, Peyrin; Shakir, Fuzail; Law, Andrew; Ngai, Nicholas. "Cookies and Session Management". UC Berkeley CS-161 Computer Security Textbook. Retrieved 24 March 2024.
4. Sudhodanan, Khodayari & Caballero 2020, pp. 2–3.
5. Zalewski 2011, p. 15.
6. Schwenk, Niemietz & Mainka 2017, p. 713.
7. Zalewski 2011, p. 16.
8. Somé 2018, pp. 13–14.
9. "Same-origin policy - Security on the web | MDN". MDN Web Docs. 20 December 2023. Retrieved 24 March 2024.
10. Knittel et al. 2021, p. 1774.
11. Van Goethem et al. 2021, p. 1.
12. Rautenstrauch, Pellegrino & Stock 2023, p. 2747.
13. Van Goethem et al. 2022, p. 787.
14. Gelernter & Herzberg 2015, pp. 1399–1402.
15. Sudhodanan, Khodayari & Caballero 2020, p. 1.
16. Van Goethem et al. 2016, p. 448.
17. Gelernter & Herzberg 2015, p. 1400.
18. Rautenstrauch, Pellegrino & Stock 2023, p. 2754.
19. Felten & Schneider 2000, pp. 25, 26, 27, 31.
20. Bortz & Boneh 2007, pp. 623–625.
21. Gelernter & Herzberg 2015, pp. 1394–1397.
22. Walker, James (21 March 2019). "New XS-Leak techniques reveal fresh ways to expose user information". The Daily Swig. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
23. Van Goethem et al. 2021, pp. 1, 6.
24. Herrera, Luan (31 March 2019). "XS-Searching Google's bug tracker to find out vulnerable source code". Medium. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
25. Knittel et al. 2021, p. 1772.
26. Terjanq. "Mass XS-Search using Cache Attack – HackMD". GitHub. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
27. Van Goethem et al. 2021, p. 10.
28. Rautenstrauch, Pellegrino & Stock 2023, p. 2756.
29. Sudhodanan, Khodayari & Caballero 2020, p. 2.
30. Knittel et al. 2021, p. 1773.
31. "IEEE Symposium on Security and Privacy 2023". sp2023.ieee-security.org. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
32. Van Goethem et al. 2022, p. 786.
33. Sudhodanan, Khodayari & Caballero 2020, p. 11.
34. Van Goethem et al. 2022, p. 788.
35. Rautenstrauch, Pellegrino & Stock 2023, p. 2745.
36. Van Goethem et al. 2022, p. 785.
37. Van Goethem et al. 2022, p. 784.
38. Rautenstrauch, Pellegrino & Stock 2023, p. 2748.
39. Rautenstrauch, Pellegrino & Stock 2023, pp. 2755–2756.
40. Van Goethem et al. 2022, pp. 796, 797.
41. Vila & Köpf 2017, pp. 851–853.
42. Van Goethem et al. 2022, p. 796.
43. "Performance - Web APIs | MDN". MDN Web Docs. 19 February 2023. Retrieved 11 March 2024.
44. Knittel et al. 2021, p. 1778.
45. Snyder et al. 2023, p. 7095.
46. Knittel et al. 2021, p. 1775.
47. Knittel et al. 2021, pp. 1775, 1785.
48. Staicu & Pradel 2019, pp. 924, 930.
49. Zaheri, Oren & Curtmola 2022, p. 1505.
50. Knittel et al. 2021, p. 1785.
51. Knittel et al. 2021, pp. 1777, 1785.
52. Knittel et al. 2021, pp. 1778, 1782.
53. Van Goethem et al. 2022, p. 789.
54. Mishra et al. 2021, p. 404.
55. Felten & Schneider 2000, pp. 25, 28, 29.
56. Bansal, Preibusch & Milic-Frayling 2015, p. 97.
57. Jia et al. 2015, pp. 1, 2.
58. Bansal, Preibusch & Milic-Frayling 2015, p. 99.
59. Van Goethem, Joosen & Nikiforakis 2015, pp. 1385, 1386.
60. Kim, Lee & Kim 2016, pp. 411–413.
61. Snyder et al. 2023, pp. 7096, 7097.
62. Knittel et al. 2021, pp. 1782, 1776–1778.
63. "XS-Leak: Leaking IDs using focus". PortSwigger Research. 8 October 2019. Archived from the original on 28 December 2023. Retrieved 28 December 2023.
64. Van Goethem et al. 2022, p. 797.
65. Ng, Alfred. "Google finds Apple Safari anti-tracking feature actually enabled tracking". CNET. Archived from the original on 11 December 2023. Retrieved 28 December 2023.
66. Wilander, John (10 December 2019). "Preventing Tracking Prevention Tracking". WebKit. Archived from the original on 16 November 2023. Retrieved 28 December 2023.
67. Janc, Artur; Kotowicz, Krzysztof; Weichselbaum, Lukas; Clapis, Roberto. "Information Leaks via Safari's Intelligent Tracking Prevention". Google Research. Archived from the original on 28 December 2023. Retrieved 28 December 2023.
68. Knittel et al. 2021, p. 1780.
69. Felten & Schneider 2000, p. 26.
70. Zaheri & Curtmola 2021, p. 160.
71. Felten & Schneider 2000, pp. 27, 28, 29.
72. Mishra et al. 2021, p. 399.
73. Doan et al. 2022.
74. Kitamura, Eiji (6 October 2020). "Gaining security and privacy by partitioning the cache". Chrome for Developers. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
75. Van Goethem et al. 2021, p. 7.
76. Bannister, Adam (13 October 2020). "Google Chrome partitions browser HTTP cache to defend against XS-Leak attacks". The Daily Swig. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
77. Reis, Moshchuk & Oskov 2019, p. 1674.
78. Van Goethem, Sanchez-Rola & Joosen 2023, p. 379.
79. Van Goethem et al. 2022, p. 792.
80. "Cross-Origin-Opener-Policy – HTTP | MDN". MDN Web Docs. 10 April 2023. Archived from the original on 31 October 2023. Retrieved 31 October 2023.
81. Kitamura, Eiji. "Making your website "cross-origin isolated" using COOP and COEP | Articles". web.dev. Archived from the original on 31 October 2023. Retrieved 31 October 2023.
82. Snyder et al. 2023, p. 7092.
83. "State Partitioning - Privacy on the web | MDN". MDN Web Docs. 24 July 2023. Retrieved 5 February 2024.
84. Van Goethem et al. 2022, p. 791.
85. Calzavara et al. 2020, pp. 684, 685.
86. Van Goethem et al. 2021, p. 5.
87. "X-Frame-Options – HTTP | MDN". MDN Web Docs. 25 July 2023. Archived from the original on 27 October 2023. Retrieved 29 October 2023.
88. "Cross-Origin Read Blocking (CORB)". Chromium Gerrit. Archived from the original on 7 November 2023. Retrieved 7 November 2023.
89. Reis, Moshchuk & Oskov 2019, pp. 1665, 1666.
90. "Cross-Origin Resource Policy (CORP) – HTTP | MDN". MDN Web Docs. 10 May 2023. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
91. Knittel et al. 2021, p. 1781.
92. Khodayari & Pellegrino 2022, p. 1592.
93. Khodayari & Pellegrino 2022, p. 1590.
94. Khodayari & Pellegrino 2022, pp. 1596, 1600.
95. Compagna et al. 2021, pp. 50–51.
96. "Bypassing SameSite cookie restrictions | Web Security Academy". Portswigger Research. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
97. Khodayari & Pellegrino 2022, pp. 1596–1598.
98. Weichselbaum, Lukas. "Protect your resources from web attacks with Fetch Metadata | Articles". web.dev. Archived from the original on 7 November 2023. Retrieved 7 November 2023.
99. Beer et al. 2021.
100. "Sec-Fetch-Site – HTTP | MDN". MDN Web Docs. 25 October 2023. Archived from the original on 29 October 2023. Retrieved 29 October 2023.

Sources

• Bansal, Chetan; Preibusch, Sören; Milic-Frayling, Natasa (2015). "Cache Timing Attacks Revisited: Efficient and Repeatable Browser History, OS and Network Sniffing". In Federrath, Hannes; Gollmann, Dieter (eds.). ICT Systems Security and Privacy Protection. IFIP Advances in Information and Communication Technology. Vol. 455. Springer International Publishing. pp. 97–111. doi:10.1007/978-3-319-18467-8_7. ISBN 978-3-319-18467-8. S2CID 8676881.
• Beer, Philip; Veronese, Lorenzo; Squarcina, Marco; Lindorfer, Martina (6 September 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 7 November 2023. Retrieved 7 November 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 should be allowed.
• Bortz, Andrew; Boneh, Dan (8 May 2007). "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.
• 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. S2CID 214631428.
• Compagna, Luca; Jonker, Hugo; Krochewski, Johannes; Krumnow, Benjamin; Sahin, Merve (1 September 2021). "A preliminary study on the adoption and effectiveness of SameSite cookies as a CSRF defence". 2021 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE. pp. 49–59. doi:10.1109/EuroSPW54576.2021.00012. ISBN 978-1-6654-1012-0. S2CID 240156960.
• Doan, Trinh Viet; van Rijswijk-Deij, Roland; Hohlfeld, Oliver; Bajpai, Vaibhav (12 February 2022). "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.
• Somé, Dolière Francis (29 October 2018). Web applications security and privacy (phd thesis). Université Côte d'Azur.
• Felten, Edward W.; Schneider, Michael A. (1 November 2000). "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.
• Gelernter, Nethanel; Herzberg, Amir (12 October 2015). "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.
• Jia, Yaoqi; Dong, Xinshu; Liang, Zhenkai; Saxena, Prateek (1 January 2015). "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. S2CID 16087472.
• 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.
• Kim, Hyungsub; Lee, Sangho; Kim, Jong (5 December 2016). "Inferring browser activity and status through remote monitoring of storage usage". Proceedings of the 32nd Annual Conference on Computer Security Applications. ACSAC '16. Association for Computing Machinery. pp. 410–421. doi:10.1145/2991079.2991080. ISBN 978-1-4503-4771-6. S2CID 10483542 – via Arizona State University Library.
• Knittel, Lukas; Mainka, Christian; Niemietz, Marcus; Noß, Dominik Trevor; Schwenk, Jörg (12 November 2021). "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.
• 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. hdl:20.500.12210/57495. ISSN 2299-0984. S2CID 231779262. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
• Rautenstrauch, Jannis; Pellegrino, Giancarlo; Stock, Ben (21 May 2023). "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.
• 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. S2CID 199522067. Archived from the original on 7 November 2023. Retrieved 7 November 2023.
• 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.
• Snyder, Peter; Karami, Soroush; Edelstein, Arthur; Livshits, Benjamin; Haddadi, Hamed (26 October 2023). "Pool-party: exploiting browser resource pools for web tracking". Proceedings of the 32nd USENIX Conference on Security Symposium. SEC '23. 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. S2CID 156052170.
• 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.
• Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (6 September 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 11 October 2023. Retrieved 11 October 2023.
• Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (30 May 2022). "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; 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 7 November 2023.
• Van Goethem, Tom; Vanhoef, Mathy; Piessens, Frank; Joosen, Wouter (2016). Request and Conquer: Exposing {Cross-Origin} Resource Size. pp. 447–462. ISBN 978-1-931971-32-4.
• Van Goethem, Tom; Joosen, Wouter; Nikiforakis, Nick (12 October 2015). "The Clock is Still Ticking: Timing Attacks in the Modern Web". Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. CCS '15. Association for Computing Machinery. pp. 1382–1393. doi:10.1145/2810103.2813632. ISBN 978-1-4503-3832-5. S2CID 17705638.
• 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. arXiv:1702.06764. ISBN 978-1-931971-40-9.
• 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.
• 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. S2CID 251092191.
• Zalewski, Michal (15 November 2011). The Tangled Web: A Guide to Securing Modern Web Applications. No Starch Press. ISBN 978-1-59327-388-0.

Further reading

• Knittel, Lukas; Mainka, Christian; Niemietz, Marcus; Noß, Dominik Trevor; Schwenk, Jörg (12 November 2021). "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.
• Rautenstrauch, Jannis; Pellegrino, Giancarlo; Stock, Ben (21 May 2023). "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.
• Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (30 May 2022). "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.
• Van Goethem, Tom; Franken, Gertjan; Sanchez-Rola, Iskander; Dworken, David; Joosen, Wouter (6 September 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 11 October 2023. Retrieved 11 October 2023.

External links

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