Cross-Site Scripting Attacks

Cross-site scripting (XSS) is a vulnerability derived from input validation errors in most part of the web
applications. From a bug bounty hunter's approach, it is one of the most juicy bugs to look for in an
application. It is the reason why XSS bugs are the most commonly reported bugs in bounty programs.
XSS exists due to a lack of validation controls in all the different inputs in an application. Traditionally,
they are found in HTML forms that have interaction with the user; however, it is not the only kind of
vulnerable input; it is also possible to find XSS vulnerabilities, because of the interaction between other
applications, environmental variables, external data sources, and more. The relevance of the XSS
vulnerabilities is so important; evidence of that is this vulnerability is included in the OWAS TOP 10 as
one of the most prevalent in the applications in the last 10 years. One curious characteristic of this
vulnerability, between others, is that it is focused on the client. Most of the vulnerabilities reviewed in
this book are focused on the application itself, meaning that the application is exploited from a backend
perspective in order to generate the failure. As we will see, in this chapter XSS attacks need user
interaction to be successful. We will cover the following topics in this chapter: Understanding XSS attacks
Detecting XSS in bug bounty programs Top XSS report examples

Types of cross-site scripting

There are different types of XSS; the most basics are as follows: Reflected XSS Stored XSS DOM-based XSS
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: Blind XSS Flash-based XSS Self XSS 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.

Reflected cross-site scripting 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. Cross-Site Scripting Attacks Chapter 6 [ 89 ] 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='> 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. Cross-Site Scripting Attacks Chapter
6 [ 91 ] DOM-based XSS In reflected and stored XSS, there is something in common, a user or a data
source that interacts with the application by inserting a value, which is then read by the application. The
third kind of XSS is different. In a DOM-based XSS, the user sends a crafted URL with the code injected
into it. Then, the server processes the information, but in the response, it does not include the injection;
instead of it, the user's browser processes the response and the script is executed. To understand how
DOM-based XSS works, it is necessary to explain the DOM concept. The Document Object Model (DOM)
is an interface for HTML and XML documents to modify the document itself in a structured way. The
DOM structures a document in a series of nodes and objects, with properties and methods that connect
the documents with the programming language, and not just JavaScript, but all types of programming
languages. For example, let's check the next snippet of code: The script parses the web page, to extract
the value for the message parameter. When the message parameter is found, the script shows it in the
web browser. If the value for the message parameter is a malicious string, the script will show the attack
to the user in the browser. But, the malicious string never came from the server, or was never processed
by the server. It was all processed on the client side, meaning in the web browser using a property
contained in the DOM