Exploiting a Self Stored XSS with an IDOR

In this post, I’ll be talking about an interesting bug chain I discovered a few months ago; Stored XSS + IDOR (Cross Site Scripting and Insecure Direct Object Reference respectively).

The target is an application that helps manage finances. Before finding this particular bug chain, I had discovered and reported a few IDORs in the application which were already fixed and paid within 30 minutes. Then it occured to me that some of the IDORs are sitewide and they also fixed it too.

Cross Site Scripting

They have a feature to request suppliers in the application. So, I injected a XSS payload in the “Name of supplier” and requested the supplier. Nothing happened at first until I opted to delete the supplier and got a pop-up! That was successful but this doesn’t seem exploitable as it was Stored but Self XSS.

PS: I didn’t include the payload here since anyone would have worked.

Insecure Direct Object Reference

Although I know they had fixed some IDORs in the past, but wanted to escalate the Stored Self XSS anyway. Luckily for me, I found another IDOR which was not handled by the previous fix. This time I was able to view, edit, and delete suppliers of other users.

The body of the PUT request looked like the following:

{"shop_account_request":{"request_name":"Name of supplier","reference_contact_name":"ContactName","reference_contact_email":"Email","reference_contact_phone":"Phone","id":IncrementalID}}

Then I could set a XSS payload as the “Name of supplier” for any of the request for supplier via the Incremental IDs. And whenever they feel a name is weird and opt to delete, the XSS payload would be executed.

Thank you for your time. And I hope you enjoyed reading this.