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.
Stored XSS
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…
