Английская Википедия:Cross-site leaks

Содержание

Текст

Текст

Текст

Текст

Текст

Текст

Текст

Текст

Текст

Cross-site leaks, also known as XS-Leaks, are a class of Internet security attacks that allow an attacker to access sensitive information about a user's interactions with other websites using long-standing information leakage issues inherent to 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, which used a web cache to gain information about a different website. Since then, cross-site leaks have become increasingly sophisticated; researchers find newer leaks with varying efficacy levels, targeting web browser components. While more-recent techniques are continually being discovered, some older methods are blocked through updates to browser software, and the introduction and removal of features on the Internet.

To perform a cross-site leak attack, 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 and identify at least one way in which they can distinguish between the two responses. Using information-leakage issues (side channel) in web browsers can reveal observable differences between the two responses. The attacker must also be able to phish or entice the victim to visit an attacker-controlled website that would deliver the exploit to the user.

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. Well-known cross-site leaks include timing attacks, which rely on timing-specific events in the web browser; error events, which use the presence and absence of events to leak data; and cache-timing attacks, which rely on the web cache to reveal data. More recently, newer attacks that use operating system and web browser limits to gain information about patterns in the victim website's operation.

Despite being known about since 2000, most modern defences against this class of attacks have been more-recently introduced in the form of extensions to the hypertext transfer protocol (HTTP) that 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 is SameSite cookies, which allow websites to set a specific directive, preventing other websites from accessing and sending specific-sensitive cookies. Other successful approaches include the use of HTTP headers to limit which third-party websites can use embedding techniques to embed a website; and cache partitioning, which is a defense against a 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)

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 application.Шаблон:Refn 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 application changes between well-defined states.Шаблон:Sfn

To securely isolate web applications from each other, the interactions between the execution contexts of these apps are governed by the same-origin policy.Шаблон:Sfn An execution context, in this case, is considered to be equivalent to a web origin.Шаблон:Sfn A web app cannot reach into another web app's execution context and arbitrarily interact with the execution state of the other web app.Шаблон:Sfn A web app can embed content from other web apps using frames or requests to third-party sites via cross-origin requests.Шаблон:Sfn Cross-site leaks allow attackers to break this cross-origin barrier, which is inherent in web app contexts. By using 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 app.Шаблон:Sfn The attacker can then access information about a user's previous browsing activity.Шаблон:Sfn

Mechanism

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.Шаблон:SfnШаблон:Sfn

To perform a cross-site leak, the attacker must identify and include at least one state-dependent URL in the victim 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.Шаблон:Sfn 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.Шаблон:SfnШаблон:Sfn

While every method of including 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.Шаблон:Sfn 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.Шаблон:SfnШаблон:Sfn

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.Шаблон:Sfn

<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 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.Шаблон:SfnШаблон:Sfn

This simple functionality is vulnerable to a cross-leak attack, as shown by the following JavaScript snippet.Шаблон:SfnШаблон:Refn

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 iff the victim app returns at least one result, the attacker can determine whether the victim app returned any results for the given query.Шаблон:SfnШаблон:Sfn

History

Cross-site leaks have been known about since 2000;Шаблон:Sfn 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.Шаблон:Sfn 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.Шаблон:Sfn In 2015, researchers from Bar-Ilan University described a cross-site search attack that used similar leaking methods but used an amplification technique in which the input was crafted to extensively 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.Шаблон:Sfn

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. In 2018, Luan Herrara described a security exploit that allowed them to exfiltrate data about sensitive security issues using the search functionality of Google's Monorail bug tracker that is actively used by open-source projects such as the Chromium, Angle and Skia Graphics Engine.Шаблон:Sfn 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.Шаблон:Sfn

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 in an attempt to create an open-knowledge database, and analyzing and compiling information about cross-site leak attacks.Шаблон:SfnШаблон:Sfn

Since 2020, there has been some interest among the academic security community to standardize 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. Шаблон:SfnШаблон:Sfn 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. Шаблон:SfnШаблон:Sfn 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.Шаблон:SfnШаблон:Sfn 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 comprise a highly varied range of attacksШаблон:Sfn for which there is no established, uniform classification.Шаблон:Sfn These attacks are typically categorized by the leaking techniques used during an attack.Шаблон:Sfn Шаблон:As of, researchers have identified over 38 leak techniques that target components of the browser, and new techniques are discovered due to ongoing changes in web platform APIs, which are JavaScript interfaces that allow websites to query the browser for specific information.Шаблон:Sfn 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.Шаблон:Sfn

Timing attacks

Timing attacks rely on the ability to time specific events across multiple responses.Шаблон:Sfn These were discovered by researchers at Stanford University in 2007, making them one of the oldest-known types of cross-site leak attacks.Шаблон:Sfn

While initially used only to differentiate between the time it took for a HTTP request to resolve a response,Шаблон:Sfn research performed after 2007 has shown 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.Шаблон:SfnШаблон:Sfn

In 2021, Knittel et al. showed 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 the amount of time shown to the user to be negative when a redirect occurred. Google Chrome subsequently fixed this bug.Шаблон:Sfn 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. Шаблон:Sfn

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.Шаблон:Sfn

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.Шаблон:Sfn 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.Шаблон:SfnШаблон:Sfn

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.Шаблон:SfnШаблон:Sfn 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.Шаблон:Sfn In 2021, Knittel et al. showed error events that are generated by a sub-resource 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.Шаблон:SfnШаблон:Sfn

Cache-timing attacks

Cache-timing attacks rely on the ability to infer hits and misses in shared caches on the web platform.Шаблон:Sfn 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.Шаблон:SfnШаблон:SfnШаблон:Sfn

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.Шаблон:SfnШаблон:SfnШаблон:Sfn 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.Шаблон:SfnШаблон:Sfn

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.Шаблон:Sfn The attack abuses global operating systems or hardware limitations to starve shared resources.Шаблон:Sfn 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.Шаблон:Sfn

Other techniques

In 2019, Gareth Heyes discovered 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. 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.Шаблон:SfnШаблон:Sfn

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. Similarly, the widespread introduction of cache partitioning in all major browsers in 2020 has reduced the potency of cache-timing attacks.Шаблон:Sfn

Defences

Despite being known about since 2000, most defences against cross-site leaks have been introduced after 2017.Шаблон:Sfn Before the introduction of these defences, 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 limits link sharing, and is thus infeasible and impractical.Шаблон:SfnШаблон:Sfn

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.Шаблон:Sfn

Isolating shared resources

Файл:Histogram of cross-site leaks cache timing attack example.png

Raw data from the cache timing attack discussed in Шаблон:Section link. 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.Шаблон:Legend Шаблон:Legend

One of the earliest and best-known 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.Шаблон:SfnШаблон:Sfn Шаблон:As of, most browsers have implemented HTTP cache partitioning, drastically reducing the effectiveness of this approach.Шаблон:Sfn 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 concatenating the resources 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.Шаблон:Sfn

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.Шаблон:SfnШаблон:Sfn 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.Шаблон:Sfn

As part of a effort to mitigate cross-site leaks, the developers of the browsers Chrome, Brave, Microsoft Edge, Firefox and Safari have implemented storage partitioning,Шаблон:Sfn 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.

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.Шаблон:Sfn 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.Шаблон:Sfn By disallowing 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.Шаблон:Sfn

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. This feature was originally introduced as part of a series of mitigations against the Spectre vulnerabilityШаблон:Sfn 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.Шаблон:SfnШаблон:Sfn

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.Шаблон:RefnШаблон:Sfn 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.Шаблон:Sfn 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.Шаблон:SfnШаблон:Sfn 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 iff the request is sent while navigating the page and it occurs within two minutes of the cookie being set.Шаблон:Sfn This has led to bypasses and workarounds against the SameSite=Lax limitation that still allow cross-site leaks to occur.Шаблон:Sfn

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. 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.Шаблон:Sfn 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.Шаблон:Sfn

See also

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

References

Sources

• Шаблон:Cite book
• Шаблон:Cite conference
• Шаблон:Cite book
• Шаблон:Cite journal
• Шаблон:Cite book
• Шаблон:Cite journal
• Шаблон:Cite thesis
• Шаблон:Cite book
• Шаблон:Cite book
• Шаблон:Cite journal
• Шаблон:Cite book
• Шаблон:Cite book
• Шаблон:Cite book
• Шаблон:Cite journal
• Шаблон:Cite book
• Шаблон:Cite book
• Шаблон:Cite book
• Шаблон:Cite journal
• Шаблон:Cite journal
• Шаблон:Cite book
• Шаблон:Cite conference
• Шаблон:Cite bookШаблон:Creative Commons text attribution notice
• Шаблон:Cite book
• Шаблон:Cite book
• Шаблон:Cite journal
• Шаблон:Cite book
• Шаблон:Cite journal

Further reading

• Шаблон:Cite book
• Шаблон:Cite book
• Шаблон:Cite book
• Шаблон:Cite conference

External links

• Шаблон:Cite web
• Шаблон:Cite web