Table of Contents:


  In this blog post I will explain how I turned a Self-XSS (cross-site scripting) vulnerability into a Stored-XSS by chaining it with an IDOR (insecure direct object reference) vulnerability. By chaining these two, I was able to turn a limited attack into a much more serious one. But first, let’s define these terms:  

XSS (cross-site scripting) is a type of vulnerability that allows an attacker to inject malicious code into a website, which is then executed by the victim’s browser, while on the other side, IDOR is a type of vulnerability that occurs when an application exposes internal object references, such as database IDs, in a way that allows an attacker to manipulate them. This can be exploited to access sensitive information or perform unauthorized actions.  

Where did the vulnerability occur?  

An admin user could create his own folder structure within the web application. The created folder’s name was not properly sanitized, which allowed the attacker to inject malicious javascript code. Because only the owner of the folder could see and access it, this resulted in a Self-XSS. Due to the presence of an IDOR, an attacker could use it to increment the organization ID, transforming this vulnerability into a stored XSS that could attack other organization administrators and possibly takeover their accounts. Making it even worse, this could also be exploited from low-privileged users.  

Because there was no WAF (web application firewall) and the organizational IDs were easily guessable, this flaw was easily exploited and demonstrates the need of properly securing web applications and protecting them against all types of vulnerabilities.


  I’ve logged into an admin account and proved that a folder containing a malicious payload was not present, as seen on the screenshot below.


Now using a low-privileged account, I’ve created a new folder and intercepted the request in order to modify the data before the folder is created on the backend.


As seen on the screenshot above, I modified the following data:  

&parent_folder_id=7 //<- Admin's main folder
&company_id=10 //<- Admin's Company
&folder_name=><img+src=x+onerror=alert(document.domain)>  // <- malicious payload

  Heading back to the admin account, we can see that the malicious folder has been created.   image53  

  In order for the payload to get executed, the victim, in this case the admin user should perform an action such as “Previewing” or “Moving” any of the present files inside that structure.



Suggested Fix

In order to mitigate XSS (cross-site scripting) attacks, the below requirements should be followed (as suggested by OWASP):  


Whereas for IDOR (insecure direct object reference) the below checks should be in place:  

  Thank you for taking the time to read this, and I hope you’ll find it useful.