{"id":766,"date":"2025-04-09T16:40:32","date_gmt":"2025-04-09T14:40:32","guid":{"rendered":"https:\/\/www.cloudtango.net\/blog\/?p=766"},"modified":"2025-04-09T16:40:32","modified_gmt":"2025-04-09T14:40:32","slug":"from-stored-xss-to-account-takeover-how-vulnerabilities-combine-into-major-risks","status":"publish","type":"post","link":"https:\/\/www.cloudtango.net\/blog\/2025\/04\/09\/from-stored-xss-to-account-takeover-how-vulnerabilities-combine-into-major-risks\/","title":{"rendered":"From Stored XSS to Account Takeover: How Vulnerabilities Combine into Major Risks"},"content":{"rendered":"

Recently, during a web application penetration test, we uncovered a situation where a combination of seemingly small vulnerabilities led to a major security breach. We found a stored Cross-Site Scripting (XSS) flaw in the comments section of a support ticketing system. This, paired with weak session security, allowed us to hijack a user\u2019s account.<\/p>\n

While automated scanning tools typically miss these complex vulnerability chains, manual penetration testing like ours can reveal these hidden risks. In this article, we\u2019ll break down how the attack worked and offer some practical advice on how to protect your application from similar threats.<\/p>\n

The Vulnerabilities in Play<\/h2>\n

Let\u2019s first understand the vulnerabilities involved:<\/p>\n

1. Stored Cross-Site Scripting (XSS):<\/strong><\/p>\n

Stored XSS happens when a malicious script gets permanently stored on a web server, often through user-generated content like comments or messages. When other users view this content, the script runs in their browser, allowing attackers to execute unwanted actions or steal sensitive information remotely.<\/p>\n

2. Session Tokens Exposed in URLs: <\/strong><\/p>\n

Session tokens help confirm user identity without forcing them to log in repeatedly. However, putting these tokens directly into URLs increases the risk of accidental exposure through browser history, logs, or even malicious interception. Attackers that capture these tokens can impersonate legitimate users, especially when they’re obfuscated using simple methods like Base64 encoding.<\/p>\n

3. Session Hijacking: <\/strong><\/p>\n

Session hijacking is when an attacker steals a user’s login information (session token) to access their account without knowing their password.<\/p>\n

Exploit Walkthrough:<\/h3>\n

Here\u2019s how we combined these vulnerabilities to take over an account, along with the evidence we provided to the client:<\/p>\n

Step 1 \u2013 Stored XSS identification via Support Comments <\/strong><\/p>\n

While testing the support ticket feature, I tried some basic XSS payloads to see if the system properly validated inputs. Initially, input validation mechanisms stripped certain special characters required for typical HTML-based XSS payloads.<\/p>\n

However, by using obfuscation and bypass techniques, specifically the JavaScript function String.fromCharCode()<\/strong>, I successfully bypassed the filters, confirming the presence of stored XSS.<\/p>\n

Step 2 \u2013 Base-64 Encoded Session Token in URL identification <\/strong><\/p>\n

Next, I noticed URLs associated with viewing support tickets included an unusual base64-encoded parameter. After decoding, it became clear that this encoded string was actually the user’s PHP session token \u2014an important piece of information that could grant access to the user\u2019s account.<\/p>\n

The image below displays the identified Base-64 encoded value being decoded to present the PHPSession cookie value utilised to identify the active session.<\/p>\n

\"Base-64<\/p>\n

Step 3 – Using Stored XSS to Capture the Token<\/span><\/strong> <\/span><\/p>\n

Knowing the session token was embedded in the URL, I crafted an XSS payload that sent the victim\u2019s document location (the URL) to a server I controlled. When the victim clicked on the ticket containing the malicious code, it sent their session token straight to my server.<\/span><\/p>\n

\"Session<\/span><\/p>\n

Step 4 \u2013 Decode Captured Token <\/span><\/strong> <\/span><\/p>\n

Once I had the session token, I simply decoded the Base64 string to retrieve the user’s valid session cookie. This gave me full access to the victim’s session without needing their password.<\/span> <\/span><\/p>\n

\"Users<\/span><\/p>\n

Step 5 \u2013 Hijacking the Session<\/span><\/strong> <\/span><\/p>\n

Once I had the stolen session token, I simply replaced my session cookie with it, giving me full access to the victim’s account. Since there was no re-authentication required, I could do things like disable Multi-Factor Authentication (MFA), change the registered phone number, update the email address, and reset the password.<\/span> <\/span><\/p>\n

Ultimately, this permitted me to fully hijack the account, locking out the original user entirely, as demonstrated by the image below. <\/span><\/p>\n

\"Account<\/span><\/p>\n

Real-World Impact<\/span><\/strong><\/h3>\n

You might be wondering what the real-world impact would be if this issue wasn\u2019t identified and addressed within a controlled testing environment prior to public release. In short, this vulnerability could result in the complete compromise of any high-level or administrative account accessing support tickets. Attackers exploiting this could gain unrestricted access to sensitive customer data, perform unauthorised account modifications, escalate privileges, and potentially cause severe financial, regulatory, and reputational damage to the affected organisation.<\/span> <\/span><\/p>\n

Mitigation Considerations<\/span><\/strong> <\/span><\/h3>\n

To prevent attacks like this, here are a few key things to keep in mind:<\/span><\/p>\n

1. Strict Input Validation, Sanitisation, and Output Encoding<\/span><\/strong><\/p>\n