From Reflected to Stored: Unveiling Hidden Vulnerabilities of Self XSS

In the realm of web security, cross-site scripting (XSS) is a significant threat that can lead to various types of attacks. Among these, reflected XSS and stored XSS are two common vulnerabilities that often overlap in unexpected ways. In this post, we’ll start by briefly explaining these concepts and then dive into a practical example where I discovered a hidden stored XSS vulnerability through a reflected XSS attack.

Understanding Reflected XSS

Reflected XSS occurs when user input is immediately reflected back onto a web page without proper sanitization or escaping. This means that malicious scripts injected through user input can be executed in the context of the victim’s browser, potentially leading to unauthorized actions or data leakage. For instance, an attacker might craft a URL containing malicious JavaScript, tricking a user into clicking it. When the malicious script is reflected and executed, it can steal cookies, session tokens, or perform other malicious actions.

Stored XSS: A Deeper Threat

Stored XSS, on the other hand, involves injecting malicious scripts into a web application where they are then stored and served to other users. This type of XSS can be more severe because the injected script persists across multiple sessions and can affect all users who access the compromised resource. Examples include injecting scripts into user profiles, comment sections, or other persistent data stores.

Self XSS: Understanding Its Impact

Self XSS refers to a situation where a vulnerability allows an attacker to trick a user into executing malicious scripts in their own browser. This typically involves social engineering, where the user is persuaded to paste or execute a script in their browser’s console or other input fields. While self-XSS might have limited impact because it only affects the user who executes the script, it can still be significant.

Uncovering the Hidden Stored XSS Vulnerability

In my recent investigation, I discovered a fascinating case where reflected XSS was leveraged to expose a hidden stored XSS vulnerability (Self stored XSS). Here’s how it unfolded:

1. Finding the Exploit: While experimenting with the website, I observed that one of the cookies set during account creation was directly reflected on the account page. Attempts to manipulate this cookie after the account creation didn’t have any immediate effect, as the cookie was stored in a JSON file associated with the account rather than being set directly in the user’s cookie store. Initially, this led to what seemed like a self-XSS vulnerability, where the impact was limited to only the user exploiting the vulnerability.
2. Exploiting Reflected XSS: Despite the initial limitations, I identified that using a reflected XSS attack allowed me to set this cookie for any new user through a crafted link. The link injected a script that set the cookie (cookie_1) with a long expiration time. This cookie was then used during the new user’s account creation process, meaning that any new user who accessed my specially crafted link would have the cookie I set reflected on their account page. The crafted link looked like this:
   <img src='x' onerror='document.cookie=&quot;cookie_1=<script>alert(document.cookie)</script>; Domain=.████████.com; path=/; Secure&quot;' /> <meta name='language' content='0;http://www.████████.com' HTTP-EQUIV='refresh' />
3. Persistent Impact: The critical insight here was that this cookie, set via reflected XSS, was stored and used in the account creation process for new users. As a result, the crafted cookie would be reflected (Via JSON) on the account page of any new user indefinitely.

Conclusion

This case highlights how reflected XSS can sometimes reveal hidden stored XSS vulnerabilities. Even if a self-XSS vulnerability appears to have limited impact at first glance, it’s crucial to reconsider its potential risks. There is often a way to escalate or exploit self-XSS vulnerabilities, making them significant threats. All types of XSS should be treated as highly impactful, as they can compromise the security of web applications and sensitive user data. It’s essential for web developers and security professionals to rigorously test and sanitize user inputs to mitigate these risks and protect against potential attacks.