Published by Security Testing and Assurance on 24 July
Introduction
This article explains what Cross-Site Leaks (XS-Leaks or XSLeaks) are, as well as providing an example attack, along with mitigation options for application developers and systems administrators.
OWASP (WeismanGitHub et al., 2023) describe XS-Leaks as a class of vulnerabilities used to exploit the core mechanisms of the modern web browser and can be referred to as a browser side-channel attack. XS-Leaks allow websites to interact with each other and abuse legitimate mechanisms to gather information about the user, often based upon responses received, whether it may be timing, error based or abusing features of the browser. The entire attack takes place on the victim’s browser side – just like a Cross-Site Scripting (XSS) attack.
What are Cross-Site Leaks (XS-Leaks)?
To explain what XS-Leaks are, we must first understand how they occur in a web application. Often these attacks occur through malicious websites, when an attacker identifies a Cross-Site Scripting (XSS) vulnerability in a web application, or when a code could be added to a website through ads or third-party scripts.
Cross-site scripting (XSS) is a security vulnerability that occurs when an attacker can inject malicious script code into a web page that is viewed by other users. This type of vulnerability typically arises when a web application does not properly validate user input or encode user-generated content before displaying it to other users.
XS-Leaks then allow attackers to collect information about website visitors that is usually not available. This information can give the attacker clues about the user’s identity. This can include if the victim is logged into other web applications allowing access to user attributes, permissions, or roles. Additionally, a victim’s keyword search history can be queried as well as privately cached browser objects, such as images, based on how the website caches these resources.
The attacker can try to guess the answers depending on the context of the website. The answers are usually just “true” or “false”. The risk to the victim is dependent on the target selected by the attacker, but XS-Leaks threaten a user’s browser privacy and integrity.
It should be noted that not all XS-Leaks techniques will work with all browsers as modern browsers have implemented new security features to mitigate XS-Leak attacks after a number of vulnerabilities were discovered in recent years. However, in this proof-of-concept attack, it has been combined with XSS to bypass those security restrictions on Chrome and Edge browsers.
XS-Leak Proof of Concept
The easiest way to discuss the potential consequences of the XS-Leak vulnerability is to provide a proof of concept (PoC). Figure 1 shows the flow of the attack and an example code snippet to evaluate whether a user has visited a certain web page or not.
Figure 1 Showing the flow an attacker may take to perform an XS-Leak attack using XSS.
While XS-Leaks attacks are quite broad in terms of techniques used to gather certain types of information, in this example we are going to look at a simple example to determine if the user has visited a specific web page based on the image cache stored in the browser. Caching of images or web resources are usually considered standard practice and XS-Leaks focus on abusing these in-built core browser functionalities to extract user information.
The following JavaScript code can be used to determine if the user has visited certain pages within the cybercx.co.nz website, based on the time response. It is noted that this PoC works with Chrome and Edge browsers.
page_urls = ["https://cybercx.co.nz/careers/",// first image
"https://cybercx.co.nz/about-cybercx/", //second image
"https://cybercx.co.nz/solutions/"] //third image
image_urls = [
"https://cybercx.co.nz/wp-content/uploads/2023/03/221005_CYBERX_SESSION2_37371copy-768x512.jpg",
"https://cybercx.co.nz/wp-content/uploads/2023/03/221005_CYBERCX_2_38723copy-1-768x512.jpg",
"https://cybercx.co.nz/wp-content/uploads/2023/03/MicrosoftTeams-image-49-scaled-1-1536x328.webp"]
async function li(i_list, p_list){
console.log('\n\n******************************* XS-LEAKS ***********************************\n');
for(l=0;landlt;i_list.length;l++){
page_name = p_list[l].split('/')[3];
var start = performance.now();
var img = new Image();
img.src = i_list[l];
await new Promise(r=andgt;setTimeout(r,5));
visited = img.complete;
var time = performance.now() - start;
if(visited === true){
result = 'YES';
}
else{ result = 'NO'}
//console.log("Time taken %d ms.", time);
console.log(visited + ' ' + i_list[l]);
console.log('Have you visited the ' + page_name + ' page ? =andgt; ' + result + ', based on timing.');
}
console.log('\n\n*********************************************************************************\n');
}
li(image_urls, page_urls);
For the sake of this PoC let us imagine that the cybercx.co.nz website is vulnerable to XSS, but we will trigger this execution by pasting the JavaScript code into the browser console. Note that the cache may need to be cleared in some cases for the script to work properly to reproduce the screenshots shown below.
Figure 2 shows the results of viewing the JavaScript output in the browser console when visiting the cybercx.co.nz website without viewing any other pages within the website:
Figure 2 Shows the output in the browser console.
Figure 3 shows the results in the network tab showing that all three images are not loaded from disk cache and shows the time taken to load the images used in the JavaScript:
Figure 3 Showing the output in the browser network console.
Figure 4 shows the results of viewing only the solutions page (https://cybercx.co.nz/solutions/) and the JavaScript output in the browser console:
Figure 4 Showing the PoC JavaScript successfully executing.
Figure 5 shows the results in the network tab showing that the image in the Solutions page is loaded from disk cache and shows the time taken to load the images used in the JavaScript:
Figure 5 Showing cached and non-cached images and time taken to load the images.
Figure 6 shows the results of viewing all three pages on the cybercx.co.nz website, or can be performed by running the JavaScript twice in the browser console:
Figure 6 Showing the PoC script executing against all cached images.
Figure 7 shows the results in the network tab showing that all three images are loaded from disk cache and shows the time taken to load the images used in the JavaScript:
Figure 7 Showing the browser cache of all three images.
Consequence
By capturing this information, an attacker can gather information about the user which may reveal the user’s confidential information and potentially deanonymise the user, affecting user privacy which could be used to target users visiting certain web pages, viewing certain images, or searching for certain keywords.
For example, this attack may be used on a news website to determine the user’s political or religious leanings through their browsing habits to build a profile on the user. It could be used on an e-commerce site to determine what the user is interested in purchasing so that the user can be targeted for phishing or social engineering attacks. It may also be used to determine if the user has viewed content which is only available to certain users within a private group, disclosing their membership to that group.
Recommendations
For developers building websites and web applications, on the server-side ensure that the cache timeout is set to be as short a period as possible. For example, the CyberCX website image currently is set to: cache-control: public, max-age=31536000. However, this may result in degraded performance of the website as images and files are not cached by the browser.
As the attack is taking advantage of the core browser features, it is not possible to fully mitigate the issue without having a small cache timeout, therefore, developers should be aware of having a long cache time for sensitive web resources and web pages.
Additionally, a mechanism that allows caching but still prevents an XS-Leak via the browser cache is to add an additional random token for each website object. An example of the CyberCX website image might be:
Screen-Shot-2021-09-02-at-3.51.10-pm-1030×684.png?xsl_token=4267091c46018ed785e900679bfc5d4c574a15caede398c64070e4d037a0820d
This still allows a browser to cache the image if the same image and token combination is requested. But now an attacker would also have to guess the token to check against; provided it is sufficiently secure this would make XS-Leaks more difficult. However, it would still be possible to extract the token value using XSS if this token is attached to the user session, nonetheless it would require additional effort and time from an attacker to successfully exploit the issue.
References
- Arturjanc, and terjanq (2020, December 4). Introduction. XS-Leaks Wiki. Retrieved May 8, 2023, from https://xsleaks.dev/
- Bortz, A., and Boneh, D. (2007, May). Exposing private information by timing web applications. In Proceedings of the 16th international conference on World Wide Web (pp. 621-628).
- Heyes, G. (2019, October 9). XS-Leak: Leaking IDs using focus. PortSwigger Research. Retrieved May 8, 2023, from https://portswigger.net/research/xs-leak-leaking-ids-using-focus
- Teo Selenius (February 24, 2021). XS-Leaks (Cross-Site Leaks) Attacks and Prevention. Retrieved June 14, 2023, from https://www.appsecmonkey.com/blog/xs-leaks
- Walker, J. (2021, June 18). New XS-Leak techniques reveal fresh ways to expose user information. The Daily Swig. Retrieved May 8, 2023, from https://portswigger.net/daily-swig/new-xs-leak-techniques-reveal-fresh-ways-to-expose-user-information
- WeismanGitHub, Confusedcrib, Krzychurra, Miparnisari, and SoheilKhodayari (2023, February 1). Cross-site leaks Cheat Sheet. OWASP Cheat Sheet Series. Retrieved May 8, 2023, from https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html
Author: Aakash Gyawali – Senior Security Consultant
