We will describe all of them in detail during this chapter, but in the bug bounty hunter forums, it is possible to find other kind of XSS, such as these:
We will also review them. Although they are part of the main XSS types (reflected, stored, or DOM-based), there are little variations that are important to know in order to write good reports, which expand support to the vulnerability that we are reporting.
In some literature, it is possible to find this vulnerability named first order XSS, but it is not a common name. However, this name describes how a reflected XSS works.
Let me explain the process and the impact with an example.
Imagine that it is a Sunday morning and you receive a call from your grandmother, who is so scared because all the money in her bank account has been stolen. You, as a good grandchild, enter the online bank application and review the account. All is correct: there is a transaction that moved all the money to another account.
When your grandmother calls the bank, the bank just answers that this transaction was executed with her valid credentials, and is not possible to do anything because all is correct.
How did this happen?
Talking with your grandmother, you discovered that a day ago she received a message by email from the bank with a promotion to win a vacation at Cancun. She logged in to the website and following the recommendation that you as a security expert gave to her: she checked in the web browser's address bar that the bank's domain was correct. She called to the bank again to confirm this promotion, but the assistant tells her that no one in the bank knows about the promotion. You know what happened now: your grandmother was the victim of a reflected XSS sent by an email to steal the credentials of her bank account.
Reflected XSS is a type of XSS that is executed at the moment. Mostly, it affects GET requests.
If you examine the email received by your grandmother, you can see that the email contains a link to the promotion; this link includes the valid bank's domain name, something like this:
www.bankforoldpeople.com/access?account='><script><alert...
Yes, the domain is valid. But if you see the variable account, the value assigned to the variable does not appear like an account number; it actually is JavaScript code, you can identify it by the <script> tag, which is the tag used in HTML to insert a code script.
Now, you can infer that the account variable is vulnerable, it has a lack of input validation that allowed an attacker to inject JavaScript code and send a lot of emails with the malicious link to people in order to execute the attack.
This is the reason why this type of XSS is called first order, because you see the result of the XSS at the moment it is executed, but if you enter the real URL without using the malicious link, you will not see the attack. The attack just affects the user who is clicking the link.
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 cam...