Stored XSS in Bug Bounty


So I started to participate in bug bounty programs not so long before, and soon I found at least 2 places are vulnerable for stored XSS on a (quite big, I believe? They have many users and having some big banks and firms being their partner.) website which helps users to prepare their interviews.


The website’s dashboard shows meeting proposal submitted by users. XSS payloads can be added into the meeting proposal and trigger XSS on the browser of any users visiting the dashboard (OMG).

When a logged in user visits the profile of a specific user(my testing account in this case), XSS triggered.

How did I discover

After I found that this website is running a bug bounty program, first I look for any reflected XSS entry points like searching function on the website and improper error messages displayed. And I had no luck 😦 . But sometimes misfortune is a blessing in disguise.

After digging a while as a guest, I decided to signup an account to test other functionalities. Soon I found that I can leave something on the dashboard :

Users can add meeting proposals and every proposal will display on the dashboard (for a while, it reminds me “welcome new members” function on some forums in the old days!). Hmm…so that means we can probably leave some text, such as proposal content, on the dashboard? Good place to test.

I found that a user can add comment for his/her meeting proposal. Let’s see will this simple script work:

It turns out that it works! The comment is inserted in the HTML without any filtering, so now it keeps alerting ‘1’ every time we visit the dashboard (which is also the homepage of the website — if you are logged in)

And I decided to explore more. There must be more place which displays user input without filtering. So I visited the profile editing function and I found something called headline (“test” right under the username “pk”)

Hmm…..So that means I can show customized text to every user who visits my profile. What if I insert javascript here?

And again, the website did not filter this user input and insert it directly into HTML. So we got another stored XSS:

That’s it. There must be more places vulnerable to XSS. I will keep track on it.