Cross-site leaks: Difference between revisions

In [[internet security]], '''cross-site leaks''', also known as '''XS-leaks''', are a class of attacks that allow an attacker to access sensitive information about a user's interactions with other websites. Typically, a website will interact with more web servers using the [[hypertextWeb transferbrowser|Web protocolbrowsers]] (HTTP) protocol. To prevent unwanted access to these interactions, the browser will block any other untrusted websites from accessingseeing thethis HTTPinformation responses from these servers usingthrough a set of rules called the [[same-origin policy]]. Cross-site leaks, however, circumvent thisthese restrictionrules by using techniques that abuse [[Web API|features in the web browser]] that have historically been known to leakreveal information about other websites. These attacks are often initiated through [[phishing]] or other social engineering tactics,by enticing users to visit the attacker's website. Upon visiting, embeddedthe [[JavaScript]]attacker isuses utilizedmalicious bycode theon attackertheir website to sendinteract maliciouswith HTTPother requestswebsites. toThis anothercan webbe app,used withby thea aimattacker ofto extracting informationlearn about athe user's interactionsprevious withactions on the webwebsite. app,The aiminginformation tofrom this attack can [[Data re-identification|deanonymizeuniquely identifing]] the user to the attacker.

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 defences involves using [[List of HTTP header fields|HTTP headers]] to restrict which websites can embed a particular site. Cache partitioning also serves as a defence against cross-site leaks, preventing other websites from using the web cache to exfiltrate data.

To performcarry out a cross-site leak attack, thean attacker must identifyfirst atstudy leasthow onea [[Statewebsite (computerinteracts science)|state-dependent]]with URLusers. inThey theneed victimto appidentify fora usespecific in[[URL]] thethat attackproduces app.different Depending[[HTTP|Hyper onText theTransfer victimProtocol]] app's(HTTP) state,responses thisbased [[URL]]on mustthe provideuser's atpast leastactions twoon differentthe [[HTTP]] responsessite.{{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 an 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 state-dependent 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}}

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 attacks[[side channels]], they are also considered timing attacks.{{sfn|Snyder|Karami|Edelstein|Livshits|2023|p=7095}}

* {{Cite book |last1=Rautenstrauch |first1=Jannis |title=2023 IEEE Symposium on Security and Privacy (SP) |last2=Pellegrino |first2=Giancarlo |last3=Stock |first3=Ben |date=2023-05-21 |publisher=IEEE |isbn=978-1-6654-9336-9 |pages=2744–2760 |chapter=The Leaky Web: Automated Discovery of Cross-Site Information Leaks in Browsers and the Web |doi=10.1109/SP46215.2023.10179311 |chapter-url=https://ieeexplore.ieee.org/document/10179311 |s2cid=259321089 |url=https://figshare.com/articles/conference_contribution/The_Leaky_Web_Automated_Discovery_of_Cross-Site_Information_Leaks_in_Browsers_and_the_Web/24614724 |s2cid-access=free |via=CISPA – Helmholtz Center for Information Security Publication Database}}

* {{Cite book|last1last=Van Goethem |first1first=Tom |last2=Vanhoef |first2=Mathy |last3=Piessens |first3=Frank |last4=Joosen |first4=Wouter |date=2016 |title=Request and Conquer: Exposing {Cross-Origin} Resource Size |url=https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/vangoethem |language=en |pages=447–462 |isbn=978-1-931971-32-4}}

* {{Cite book |last=Zalewski |first=Michal |url=https://books.google.com/books?id=NU3wOk2jzWsC&newbks=0&hl=en |title=The Tangled Web: A Guide to Securing Modern Web Applications |date=2011-11-15 |publisher=No Starch Press |isbn=978-1-59327-388-0 |language=en}}

* {{Cite book |last1=Rautenstrauch |first1=Jannis |title=2023 IEEE Symposium on Security and Privacy (SP) |last2=Pellegrino |first2=Giancarlo |last3=Stock |first3=Ben |date=2023-05-21 |publisher=IEEE |isbn=978-1-6654-9336-9 |pages=2744–2760 |chapter=The Leaky Web: Automated Discovery of Cross-Site Information Leaks in Browsers and the Web |doi=10.1109/SP46215.2023.10179311 |chapter-url=https://ieeexplore.ieee.org/document/10179311 |s2cid=259321089 |url=https://figshare.com/articles/conference_contribution/The_Leaky_Web_Automated_Discovery_of_Cross-Site_Information_Leaks_in_Browsers_and_the_Web/24614724 |s2cid-access=free |via=CISPA – Helmholtz Center for Information Security Publication Database |ref=none}}