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

These attacks have been documented since 2000, when researchers at Purdue University detailed one of the first cross-site leak attacks. The attack leveraged the web cache to gain information about a completely different website. Since then, cross-site leaks have become increasingly sophisticated, with researchers finding newer cross-site leaks with varying efficacy levels, targeting various web browser components. While more recent techniques are continually being discovered, some older methods are being addressed and eliminated through updates in the web browser and the introduction and removal of features on the web.

Performing a cross-site leak attack requires particular conditions. The attacker must find at least one URL in a victim website that provides at least two different responses based on the website's internal state. The attacker must also identify at least one way in which they can distinguish between the two responses. Leveraging information leakage issues (side channel) in various web browsers can reveal observable differences between the two different responses. Lastly, the attacker must be able to phish or entice the victim to visit an attacker-controlled website, which would be used to deliver the exploit to the user.

As a class of attacks, cross-site leaks are incredibly diverse. Consequently, there is no consistent classification of such attacks. Multiple sources classify cross-site leaks based on the technique used to leak information. A few well-known cross-site leak types include timing attacks, a class of attacks that rely on timing specific events in the web browser; error events, which use the presence and absence of certain events to leak data; and cache timing attacks, a particular subset of timing attacks that rely on the web cache to reveal data. More recently, newer attacks have also been discovered that use operating systems and web browser limits to gain information about specific patterns in the victims website's operation.

Despite being known about since 2000, most modern defenses against this class of attacks have been introduced relatively recently in the form of extensions to the hypertext transfer protocol (HTTP), which allow websites to instruct the browser to selectively disallow or annotate certain kinds of stateful requests coming from different origins. One of the most successful approaches browsers have implemented in recent years is SameSite cookies, which allow websites to set a specific directive preventing other websites from accessing and sending specific sensitive cookies. Other approaches that have shown success include the use of various HTTP headers to limit which third-party websites can use certain embedding techniques to embed a specific website and cache partitioning, which is a defense against the well-known attack that allows other websites to use the web cache to exfiltrate data.

Background

A diagram demonstrating the four steps in a cross-site leak attack, namely finding a state-dependent URL using a study target, preparing an attack target, getting the user to visit the attack URL and finally the inference of information
A demonstration of the typical mechanism of a cross-site leak attack (the numbers denote the different stages of the 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 hyper text transfer protocol (HTTP) and websocket connections to deliver a web application.[note 1] 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.[2] During this process, the web application transitions between well-defined states.[3]

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.[4] An execution context, in this case, is considered to be equivalent to a web origin.[3] 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.[5] However, a web application can embed content from other web apps using frames or requests to third-party sites via cross-origin requests.[6] 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 application in the attacking web application.[7] This can lead to the attacker accessing information about a user's previous browsing activity.[8]

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.[9][10]

To perform a cross-site leak, the attacker must identify and include at least one state-dependent URL in the victim application. Depending on the victim application'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 application.[11] 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.[12][13]

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.[14] 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.[15][16]

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.[16]

<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.[9][17]

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

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.[16][17][20]

History

Cross-site leaks have been known about since 2000.[21] 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.[22] 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.[23] 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 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.[24]

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.[25] 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.[26][27] 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.[7][20]

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.[25][28][29]

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. [29][30] 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. [29][31] In 2022, Van Goethem et al. extended the model to include the concept of components and evaluated currently available defences against these attacks.[29][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 of Security and Privacy.[32]

Types

Cross-site leaks encompass a highly varied range of attacks.[18] Consequently, there is no established, uniform classification for cross-site leaks.[33] Instead, these attacks are typically categorized based on the leak techniques employed during a specific attack.[14] As of 2021, researchers have identified over 38 distinct leak techniques that target various components within the browser, and the discovery of new techniques persists due to ongoing changes in web platform APIs, which are JavaScript interfaces that allow websites to query certain specific information from the browser.[9] Although the majority of these techniques involve directly detecting state changes in the victim web application, certain attacks also exploit alterations in shared components within the browser to indirectly glean information about the victim web application.[14]

Timing attacks

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

While initially used only to differentiate between the amount of time it took for an HTTP request to resolve a response,[23] recent research has shown the application of this leak technique to detect other differences across web application 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 a 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.[35][36]

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.[37] 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 application 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 application was in. [38]

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.[39]

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.[40] In 2019, researchers from TU Darmstadt showed that this particular leak technique could be used to perform a targeted deanonymization attack against users of multiple popular web services which allowed users to share arbitrary content amongst each other, such as the likes of Dropbox, Google Docs, and Github.[41][42]

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.[43][36] 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.[44] 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.[45][46]

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.[47] 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 web page had been loaded.[48][47][49]

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.[47][50][51] 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.[52][53]

Global limits

Global limits, also known as pool-party attacks 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 Snyder et al. in 2023.[38] The attack abuses particular global operating systems or hardware limitations to starve specific shared resources.[54] 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.[55]

Other techniques

In addition to the techniques listed above, multiple other techniques exist for performing cross-site leak attacks. In 2019, Gareth Heyes discovered that by setting the URL hash of a website to a specific value and subsequently detecting if a loss of focus on the current web page occurred, an attacker could determine the presence and position of various elements on a victim website.[56] More recently, in 2020, Knittel et al. showed that by obtaining a reference to the window object of a victim website, (via framing the website or by creating a popup of the victim website) an attacker could leak whether or not a Cross-Origin-Opener-Policy header was set. Additionally, 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.[37][57]

While newer techniques continue to be found, certain older techniques of performing cross-site leaks have become obsolete due to changes in the W3C specifications and updates to browsers. In December 2020, Apple updated Safari's Intelligent Tracking Prevention (ITP) mechanism, rendering a variety of cross-site leak techniques that had been discovered by researchers at Google ineffective.[58][59][60] Similarly, the widespread rollout of cache partitioning across all major browser in 2020 have reduced the potency of the cache timing attack in recent years.[61]

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 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.[21][62]

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.[61]

Completely 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 un-cached responses, whereas, with cache partitioning, the two response times overlap.
  cached response
  un-cached response

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.[17][63] However, as of October 2020, most browsers have implemented HTTP cache partitioning, drastically reducing the effectiveness of this approach.[64] HTTP cache partitioning works by multi-keying each cached request based on which website requested the resource. This means that if a website loads a resource and caches it, the cached request is linked to a unique key generated from concatenating the url of the resource and the URL of the requesting website. Consequently, 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.[65][66][67]

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.[68][69] 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.[70][71][72]

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.[73][74][75]

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.[76] 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.[77] 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.[78][79]

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.[80] While this feature was originally introduced as part of a series of mitigations against the Spectre vulnerability,[81] 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.[78][82][83]

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.[note 3][83] 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.[85] In 2020, Chrome and Firefox announced that they would be turning on SameSite=Lax as the default state for cookies across all platforms.[86][87] 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.[88] This has led to bypasses and workaround being found against the SameSite=Lax limitation that allow cross-site leaks to still occur.[89][90]

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.[91] 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.[92] To prevent the abusive use of these headers, a web application is not allowed to set these headers, and they must only be set by the browser.[93][66]

See also

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 protocol interactions and websocket connections are considered important.[1] The rest of the article will assume that the HTTP protocol interactions and websocket connections are the only two ways for web browsers to interact with web servers.
  2. ↑ The code here is taken from the paper, SoK: Exploring Current and Future Research Directions on XS-Leaks through an Extended Formal Model p. 786 which is licensed under the CC-BY 4.0 license.[18] A minor modification has been made to the code. Namely, the addition of async in line 3, which fixes a syntactical error from occurring in line 5 due to incorrect use of the await keyword.[19]
  3. ↑ 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.[84]

Citations

  1. ↑ Knittel et al. 2021, pp. 1773, 1776.
  2. ↑ "How the web works – Learn web development | MDN". developer.mozilla.org. 24 July 2023. Archived from the original on 24 September 2023. Retrieved 1 October 2023.
  3. 1 2 Knittel et al. 2021, p. 1771.
  4. ↑ Schwenk, Niemietz & Mainka 2017, p. 713.
  5. ↑ Schwenk, Niemietz & Mainka 2017, p. 716.
  6. ↑ "What is CORS? – Cross-Origin Resource Sharing Explained – AWS". Amazon Web Services, Inc. Archived from the original on 28 September 2023. Retrieved 1 October 2023.
  7. 1 2 Knittel et al. 2021, p. 1772.
  8. ↑ Van Goethem et al. 2021, p. 1.
  9. 1 2 3 4 Van Goethem et al. 2022, p. 786.
  10. ↑ Sudhodanan, Khodayari & Caballero 2020, p. 11.
  11. ↑ Sudhodanan, Khodayari & Caballero 2020, p. 1.
  12. ↑ Rautenstrauch, Pellegrino & Stock 2023, p. 2747.
  13. 1 2 Van Goethem et al. 2022, p. 787.
  14. 1 2 3 Van Goethem et al. 2022, p. 788.
  15. ↑ Rautenstrauch, Pellegrino & Stock 2023, p. 2745.
  16. 1 2 3 Van Goethem et al. 2022, p. 785.
  17. 1 2 3 Felten & Schneider 2000, p. 26.
  18. 1 2 Van Goethem et al. 2022, p. 784.
  19. ↑ "Async Functions". tc39.es. Archived from the original on 11 November 2023. Retrieved 11 November 2023.
  20. 1 2 "Mass XS-Search using Cache Attack – HackMD". terjanq.github.io. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  21. 1 2 Rautenstrauch, Pellegrino & Stock 2023, p. 2754.
  22. ↑ Felten & Schneider 2000, pp. 25, 26, 27, 31.
  23. 1 2 3 Bortz & Boneh 2007, pp. 623–625.
  24. ↑ Gelernter & Herzberg 2015, pp. 1394–1397.
  25. 1 2 "New XS-Leak techniques reveal fresh ways to expose user information". The Daily Swig | Cybersecurity news and views. 21 March 2019. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  26. ↑ Van Goethem et al. 2021, pp. 1, 6.
  27. ↑ 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.
  28. ↑ Van Goethem et al. 2021, p. 10.
  29. 1 2 3 4 Rautenstrauch, Pellegrino & Stock 2023, p. 2756.
  30. ↑ Sudhodanan, Khodayari & Caballero 2020, p. 2.
  31. ↑ Knittel et al. 2021, p. 1773.
  32. ↑ "IEEE Symposium on Security and Privacy 2023". sp2023.ieee-security.org. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  33. ↑ Rautenstrauch, Pellegrino & Stock 2023, p. 2748.
  34. ↑ Van Goethem et al. 2022, pp. 796, 797.
  35. ↑ Vila & Köpf 2017, pp. 851–853.
  36. 1 2 Van Goethem et al. 2022, p. 796.
  37. 1 2 Knittel et al. 2021, p. 1778.
  38. 1 2 Snyder et al. 2023, p. 7095.
  39. ↑ Knittel et al. 2021, p. 1775.
  40. ↑ Knittel et al. 2021, pp. 1775, 1785.
  41. ↑ Staicu & Pradel 2019, pp. 924, 930.
  42. ↑ Zaheri, Oren & Curtmola 2022, p. 1505.
  43. ↑ Knittel et al. 2021, p. 1785.
  44. ↑ Knittel et al. 2021, pp. 1777, 1785.
  45. ↑ Knittel et al. 2021, pp. 1778, 1782.
  46. ↑ Van Goethem et al. 2022, p. 789.
  47. 1 2 3 Mishra et al. 2021, p. 404.
  48. ↑ Felten & Schneider 2000, pp. 25, 28, 29.
  49. ↑ Bansal, Preibusch & Milic-Frayling 2015, p. 97.
  50. ↑ Jia et al. 2015, pp. 1, 2.
  51. ↑ Bansal, Preibusch & Milic-Frayling 2015, p. 99.
  52. ↑ Van Goethem, Joosen & Nikiforakis 2015, pp. 1385, 1386.
  53. ↑ Kim, Lee & Kim 2016, pp. 411–413.
  54. ↑ Snyder et al. 2023, pp. 7096, 7097.
  55. ↑ Knittel et al. 2021, pp. 1782, 1776–1778.
  56. ↑ "XS-Leak: Leaking IDs using focus". PortSwigger Research. 8 October 2019. Archived from the original on 28 December 2023. Retrieved 28 December 2023.
  57. ↑ Van Goethem et al. 2022, p. 797.
  58. ↑ "Google finds Apple Safari anti-tracking feature actually enabled tracking". CNET. Archived from the original on 11 December 2023. Retrieved 28 December 2023.
  59. ↑ "Preventing Tracking Prevention Tracking". WebKit. 10 December 2019. Archived from the original on 16 November 2023. Retrieved 28 December 2023.
  60. ↑ "Information Leaks via Safari's Intelligent Tracking Prevention". research.google. Archived from the original on 28 December 2023. Retrieved 28 December 2023.
  61. 1 2 Knittel et al. 2021, p. 1780.
  62. ↑ Zaheri & Curtmola 2021, p. 160.
  63. ↑ Mishra et al. 2021, p. 399.
  64. ↑ Doan et al. 2022.
  65. ↑ "Gaining security and privacy by partitioning the cache". Chrome for Developers. 6 October 2020. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  66. 1 2 Van Goethem et al. 2021, p. 7.
  67. ↑ "Google Chrome partitions browser HTTP cache to defend against XS-Leak attacks". The Daily Swig | Cybersecurity news and views. 13 October 2020. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  68. ↑ Reis, Moshchuk & Oskov 2019, p. 1674.
  69. ↑ Van Goethem, Sanchez-Rola & Joosen 2023, p. 379.
  70. ↑ Van Goethem et al. 2022, p. 792.
  71. ↑ "Cross-Origin-Opener-Policy – HTTP | MDN". developer.mozilla.org. 10 April 2023. Archived from the original on 31 October 2023. Retrieved 31 October 2023.
  72. ↑ "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.
  73. ↑ "Introducing State Partitioning – Mozilla Hacks – the Web developer blog". Mozilla Hacks – the Web developer blog. Archived from the original on 31 October 2023. Retrieved 29 October 2023.
  74. ↑ "What is the state of third party storage today in the various browsers? · Issue #12 · privacycg/storage-partitioning". GitHub. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  75. ↑ "Cookies Having Independent Partitioned State (CHIPS) origin trial". Chrome for Developers. 17 March 2022. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  76. ↑ Van Goethem et al. 2022, p. 791.
  77. ↑ Calzavara et al. 2020, pp. 684, 685.
  78. 1 2 Van Goethem et al. 2021, p. 5.
  79. ↑ "X-Frame-Options – HTTP | MDN". developer.mozilla.org. 25 July 2023. Archived from the original on 27 October 2023. Retrieved 29 October 2023.
  80. ↑ "Cross-Origin Read Blocking (CORB)". chromium.googlesource.com. Archived from the original on 7 November 2023. Retrieved 7 November 2023.
  81. ↑ Reis, Moshchuk & Oskov 2019, pp. 1665, 1666.
  82. ↑ "Cross-Origin Resource Policy (CORP) – HTTP | MDN". developer.mozilla.org. 10 May 2023. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  83. 1 2 Knittel et al. 2021, p. 1781.
  84. ↑ Khodayari & Pellegrino 2022, p. 1592.
  85. ↑ Khodayari & Pellegrino 2022, p. 1590.
  86. ↑ "Get Ready for New SameSite=None; Secure Cookie Settings | Google Search Central Blog". Google for Developers. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  87. ↑ "Changes to SameSite Cookie Behavior – A Call to Action for Web Developers – Mozilla Hacks – the Web developer blog". Mozilla Hacks – the Web developer blog. Archived from the original on 30 October 2023. Retrieved 30 October 2023.
  88. ↑ "SameSite Frequently Asked Questions (FAQ)". www.chromium.org. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  89. ↑ "Bypassing SameSite cookie restrictions | Web Security Academy". portswigger.net. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  90. ↑ "SameSite: Hax – Exploiting CSRF With The Default SameSite Policy". Pulse Security. Archived from the original on 31 October 2023. Retrieved 31 October 2023.
  91. ↑ "Protect your resources from web attacks with Fetch Metadata | Articles". web.dev. Archived from the original on 7 November 2023. Retrieved 7 November 2023.
  92. ↑ Beer et al. 2021.
  93. ↑ "Sec-Fetch-Site – HTTP | MDN". developer.mozilla.org. 25 October 2023. Archived from the original on 29 October 2023. Retrieved 29 October 2023.

Sources

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. 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 (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.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.