I will describe this kind of XSS, using a personal example from a past job. In order to understand, as in the first case, the way to exploit this vulnerability and its impact.

Around a year ago, I was working in a digital advertising agency; where there was an internal application with a lot of forms to create customer profiles and marketing campaigns.

There I was working as a QA engineer, and for one of my functional tests, I used the Intruder tool in Burp Suite to insert a list of values into the application's fields. Also, I added this string:

    '><script>alert(1)</script>

But, I kept in mind that this simple string attack may not work because in this company, the developers were using Laravel. Laravel is a PHP framework, currently used in a lot of projects, which includes input validation controls to avoid most common injection attacks.

I started the tests, inserting around 5000 values into the application, and after an hour I started to see some developers talking nervously between themselves, opening the code, training to modify some things, doing SQL queries.

The customers started calling the company, because the application started to fail, showing a lot of pop-ups in the browser. The quantity of pop-ups was so great that the application was impossible to be acceded, and if a customer tried to access to other application's section, the same thing happened.

What happened here?

Some lazy developers avoided using Laravel's methods to validate inputs, and wrote the code using PHP directly into the application. When Burp Suite's Intruder inserted the string, all the fields in the forms accepted the string. As I mentioned before, the forms were used to create customer profiles for marketing campaigns, so all this information was stored in a MySQL database to be consulted by the user afterward.

When the customers accessed the application to see the revenue generated by the campaigns, the application searched the profile information in the database, read the string, and showed the alert pop-up for each field consulted.

This is stored XSS, which means that in contrast to the reflected XSS, the attack string is stored in data storage, and when the application accesses this information the XSS in the web browser showed this information again and again to the user.

It is possible to call this kind of attack second order XSS, because you need two steps to execute the attack. First, you need to inject a malicious string into a form, and then the application needs to show this malicious string to the user.