self XSS

Hey everyone. Our company ENCIPHERS recently conducted a penetration test for a certain client XYZ and in this post, we will be sharing my XSS finding which was among the most critical vulnerabilities we found in the application.
The client here was a very reputed company which works in the field of video creation and animation. We can’t release the name of the client because the bug hasn’t been fixed yet as the test was done recently.

So our team started testing the application http://www.xyz.com. The first thing we did was to create 2 accounts one with the more features of a Paid account and the other was a Free Account and started cross-testing it for certain issues. But we soon found out, that there was an option to create our own videos and save it for future use. You can edit the videos or the text plus Export them or Upload to your google drive and several other features.

Now, what we did was to log in to our free account and created a video for ourselves. We saved the video with the payload

"><img src=x onerror=alert(document.cookie)>

as name. But we got no popup and even checking in my videos list there was no success to be found because the name wasn’t getting reflected anywhere on the page.
Right beside it was an option for Collaboration. That means that we could share a copy of my video with other people who can work on them and can then again share it with us. As soon as we clicked the option for Collaboration, we got the popup as it was saying the video with “Video name” will be shared with these peoples and as a result, the name of the video was getting reflecting back. But the main thing was that till now, it was just a Self-XSS and it was not a high priority bug that could be used to attack others.

But there were two options which struck in our mind. The first was there was no X-Frame-Header or Click-jacking Protection present which could turn this into a Stored XSS. And the other method is what we actually did to turn it into a Stored XSS.

We went to the Collaboration option and gave our Paid account’s email id. We logged in to our Paid account and accepted the invitation to collaborate. As we think you must have guessed now, it had the same exact options as with the original one. So now if this user again goes to the Collaborate option to start sharing with some other person, the name gets reflected without any HTML sanitization and the user gets the popup. This was a simple method to get Stored XSS and in this case, it was a high priority issue because a user with an account for FREE features can get the session id and cookies of a PRO user and hijack the session. This is the POC screenshot.

‍

Moreover, since it was STORED it can have as many victims as the attacker wants. Clickjacking in the whole application issue made the issue more CRITICAL because an attacker could use it to make the user accept the invitation for Collaboration.

This was all we did to get the above-stored XSS. The main thing to take out from this is there are always ways to convert any self-XSS to a General one. You just need to be on the lookout for that opportunity. Abusing Self-XSS using CSRF and Clickjacking are two of the well-known cases where any Self-XSS can be turned into a general one if the site is already vulnerable to attacks like CSRF and Clickjacking.

Meanwhile, keep hacking and we at ENCIPHERS will make sure to keep updating our blogs and tutorials so that you can learn different techniques with each post. Until then, Happy Hacking.:)

‍