Cross-site scripting (XSS) is one of the most common vulnerabilities in web applications, in fact, it is considered third in the OWASP Top 10 from 2013 (https://www.owasp.org/index.php/Top_10_2013-Top_10).
In this recipe, we will see some key points to identify a cross-site scripting vulnerability in a web application.
- Log into DVWA and go to XSS reflected.
- The first step in testing for vulnerability is to observe the normal response of the application. Introduce a name in the text box and click on Submit. We will use
Bob.
- The application used the name we provided to form a phrase. What happens if instead of a valid name we introduce some special characters or numbers? Let's try with
<'this is the 1st test'>.
- Now we can see that anything we put in the text box will be reflected in the response, that is, it becomes a part of the HTML page in response. Let's check the page's source code to analyze how it presents the information, as shown in the following screenshot:
The source code shows that there is no encoding for special characters in the output and the special characters we send are reflected back in the page without any prior processing. The < and > symbols are the ones that are used to define HTML tags, maybe we can introduce some script code at this point.
- Try introducing a name followed by a very simple script code.
Bob<script>alert('XSS')</script>
The page executes the script causing the alert that this page is vulnerable to cross-site scripting.
- Now check the source code to see what happened with our input.
It looks like our input was processed as if it is a part of the HTML code. The browser interpreted the
<script>tag and executed the code inside it, showing the alert as we set it.
Cross-site scripting vulnerabilities happen when weak or no input validation is done and there is no proper encoding of the output, both on the server side and client side. This means that the application allows us to introduce characters that are also used in HTML code. Once it was decided to send them to the page, it did not perform any encoding processes (such as using the HTML escape codes < and >) to prevent them from being interpreted as source code.
These vulnerabilities are used by attackers to alter the way a page behaves on the client side and trick users to perform tasks without them knowing or steal private information.
To discover the existence of an XSS vulnerability, we followed some leads:
- The text we introduced in the box was used, exactly as sent, to form a message that was shown on the page; that it is a reflection point.
- Special characters were not encoded or escaped.
- The source code showed that our input was integrated in a position where it could become a part of the HTML code and will be interpreted as that by the browser.
In this recipe, we discovered a reflected XSS. This means that the script is executed every time we send this request and the server responds to our malicious request. There is another type of cross-site scripting called "stored". A stored XSS is the one that may or may not be presented immediately after the input submission, but such input is stored in the server (maybe in a database) and it is executed every time a user accesses the stored data.