Cross-site scripting is one of the prominent attacks of all time. It is still being exploited in the wild. Cross-site scripting is always not about popping an alert box with some random crazy string or domain or cookies. Cross-site scripting vulnerabilities can be chained with other low hanging issues to make a critical impact. It is an obvious impact people write in their report an attacker can steal session cookies of victim user but the question here is how many people are actually exploiting it? usually with a stored XSS, the priority is “medium to high” but if you can actually steal session cookies, you can take over “Victim Session” and do what not making severity as “critical”.

The objective of writing this post is to explain the importance of cross-site scripting, chaining it with other attacks, and leveraging higher profits with low hanging fruits.

Hello fellow Hacker & Bounty Hunters, in this post, I will talk about how I was able to perform privilege escalation to Admin Account with a simple stored cross-site scripting chained with some low hanging fruits.

• Quick Overview of XSS and Stored XSS
• Exploiting Cross-Site Scripting
• Finding Low Hanging Fruits
• Chaining Vulnerabilities
• Getting Admin’s Session Cookies
• Hijacking Admin Session and Privilege Escalation of Attacker to Admin
• Kicking off Admin for Fun :D

Cross-Site Scripting (XSS) is exploited in the wild, even in present. There are multiple scenarios and types of XSS but to stick with this post, let’s quickly understand what Stored XSS is.

When an application accepts user-supplied input as-is, allowing a user to input malicious javascript code which upon execution may lead to serious issues such as stealing session cookies, redirecting users to the attacker-controlled website and whatnot. In the case of Stored XSS, the javascript code stays in the application and whenever an interaction with code happens, the action of code is performed.

For example: Suppose there is a user profile on a community website. An attacker can inject malicious code in the description which is available for public view. Now, whenever a normal user visits the attacker’s profile, the code in description gets executed.

Recently, I was working on a private program that has the same functionality as above where the application was vulnerable to Stored Cross-Site Scripting in the Description field of user’s profile. Let’s call the application “www.target.com”

The usual flow of the application is:

1. The Admin User can add multiple users with restricted roles.
2. Admin Invites a user to join the organization.
3. Invited User creates a profile and all the user’s information is visible under “People’s Directory”.

I started with performing the stored XSS and reported it via Bugcrowd. The next day, when I was testing the application again, something struck in my mind and I was like, I want to exploit XSS in real-time for more fun.

Now, I wanted to increase the impact even further, so I started looking out some other ways to chain the vulnerability. The XSS was already a non-self XSS (Self XSS is one where a user has to input the code himself in order to gain execution). I checked cookies for the presence of “secure and httpOnly flags”.

The cookies having these flags set are not retrieved from a typical XSS execution and usually, the session cookies are set with these flags as true. Due to this the impact of XSS is not actually taking over session by stealing session cookies.

Cool. So now we have a Stored XSS and Insecure Cookies. So I used a simple Cookie Grabber payload which redirects cookies to a remote server.

So Far we have → A Perfect Session Hijacking Method.

Now, I logged in with Admin Account and navigated to “People’s Directory”. As soon as I visited, I got the session cookies of “Admin User” on my Remote Server.

Further, I used the Session Cookies to gain access to the session of “Admin”. I went to “Users” and changed my attacker user’s role to “Admin”.

Now, the lower privileged user has complete access as Admin. Just for fun (my test accounts only), I went ahead and removed the Original Admin from the Attacker’s account.

Initial Severity when Reported— High (p2)

Updated Severity after Exploitation — Critical (p1) + Bonus (For Report)

• Always map the functionalities of an application before starting to hunt bugs, it helps to be systematic.
• Do not get excited and rush to submit a bug as soon as you found, think what are the possible escalation.
• Always check for Insecure Cookies and try to actually show real-time exploitation of Session Hijacking.
• Chain, Chain, Chain & Chain Vulnerability whenever possible.
• Write good reports. You can follow my writeup on Writing Good Reports