Broken Access Control and Stored XSS

Updated: Apr 22

Hello everyone, This is my second blog post and today I'll be sharing my methods of how I was able to hunt an sXSS in a private program. This was a very clean catch so without wasting any more time let's get to the methodology.

Let me tell you something about the target first, The application was intended to block services of a stolen device of a particular region. So if we have proof like police complaints, IMEI numbers, and some details about where it was lost, then we can file a report in that app and block our device until it is found, and similarly, if we found our phone we can simply request to unblock it from the same application.

I started examining the functionalities of the application, there were too many of them, as I was provided with User Roles of the web application I started looking for Broken access control vulnerabilities.

I picked one high privilege admin account and one low privilege admin account and examined the privileges. There was a page where an admin can set privileges according to their limits. I captured a request to see what was happening and saw the request was taking UserID input for modification of users in the Privilege Management page,

Now to confirm broken access control I need to modify a role that was not in the privilege of a low privilege admin and if I can modify it then there is a vulnerability.

I picked a high privilege account UserId (using burp request from a High privilege admin's account) and tried to modify it from the low privilege admin account by manipulating the modifyUserId parameter and,

I was able to set the privileges of an account which only a high privilege admin was able to do. I found the same instance in many functionalities of the application. So with the help of Insecure Direct Object Referencing, I was able to break the access control of the application.

After that, I continued examining the other functionalities, I saw I can change User Details on the User Page

The User's profile (name, mail, phone) update was reflected in the response as:

function setProfValues()

We can see that the user details were submitted without any encoding and proper sanitization, the reflection on the response was defenseless.

Tried escaping every field one by one started with email and mobile and found one weird instance despite improper encoding in both the parameters I was unable to escape both of them instead the response showed no manipulation.

But, The name parameter was vulnerable, I successfully escaped it by using


I tried adding XSS payload it was getting saved in the response but the payload was not getting executed.

Tried understanding the response code made a payload


So now the payload was getting stored in the backed and I was able to hit the XSS payload every time I visit the User tab.

Tip: Always try escaping rather than using multiple payloads in the intruder.

Hope you will find it informative.

See you guys in My next post till then Happy Hunting!

1,503 views0 comments

Recent Posts

See All