I found a stored XSS in a private program (I can’t mention it). A user can add a favorite article to his/her watch list to keep track of them for future use.
As an attacker, the request was interecepted, and a malicious javascript is inserted in its parameters. This makes the website to add an article to the watchlist which contain a javascript payload.
Since everyone can see or share his/her watchlist, an attacker could send the malicious watchlist to a victim and this will result in manipulation of his/her browser.
The watchlist is stored in the database, thus whenever an attacker think of victim that can be tricked, the attacker could use the same URL to trick more victims.
The strange thing is this vulnerability was found at first by someone else, and the team fixed it but luckily for me, I tried a different method to reproduce the same vulnerability without knowing that another guy found it and it worked.
That’s why we should always try to think out of the box, and keep searching for a way how to exploit the same vulnerability even if it’s fixed.
I saw first that the API endpoint that add articles is /api/v2/add/ and I sent this payload:
But nothing happened … Hmm why not ? I could see the Javascript payload inserted in article title, but couldn’t be executed. Strange …
Suddenly, I asked myself the endpoint “Add” does contain a slash next to it, I removed the slash from add ? /api/v2/add/ -> /api/v2/add
Think what ? It worked !! I removed the slash and tried again the same method, and booom !! Popup fired !! A big one though !
It’s weird right ? The only logical explanation to this is there are two endpoints with the same name but the trailing slash is missing on one. Maybe they fixed it by adding a new endpoint but they kept the old one which resulted in a bug.
In fact, I found two ways to produce the same vulnerability. I reported this to the company and rewarded me with a bounty.
Today’s lesson is: Try different things, with the same request.
More to come stay tuned.
Categories: Bug bounty
Leave a Reply