In the second part of our mini-series, we are going to look at the types of XSS and what we can do to evade those pesky filters! In the last part, we are diving deeper into exploiting these filter evasions in different contexts.
Stored vs Reflected
Stored and reflected XSS are two types that differ by the way their attack vector is retrieved, their exploitability, and their attack scenarios. We have to know the difference but not just how they differ when executing them but also where the dangers lie.
When we store an XSS attack vector, we input our data, and the server stores it somewhere. That can be a database for example, where it later retrieves that value. This means that you can not simply send a URL to a victim, yet this type of XSS is generally considered more impactful. This is because stored XSS, when executed successfully, will just have to user browse a website and without knowing it, the attacker could execute an XSS in the background using an attack vector they entered a long time ago or even in a totally different endpoint. (For example, your name might give an XSS popup when you open the invoices since that contains your name).
In my lab, you can clearly see what I mean. I store the blogposts somewhere on the server and later retrieve them:
This type of XSS is what we have been practicing most until now, the attack vector is in one of the parameters of a URL so we can send a link to a victim. This means there is more interaction required (Since you will have to get the victim to click on the link), so that is why this is often called a type of XSS with a bit less exploitability but don’t let that fool you. This attack type can be just as dangerous as stored XSS because the impact is not reduced. We can still execute any arbitrary JS code. For example, if you click this link, you will get a popup:
Just like everyone else, you will see a similar situation. In a Stored XSS attack, I can also send you a URL but the attack vector is retrieved from the database and…