Reflected Cross Site Scripting (XSS) Attacks

According to the Open Web Application Security Project's (OWASP) Top 10 list for 2017, cross site scripting (XSS) is a major security concern (https://www.owasp.org/index.php/Top_10_2017-Top_10).  OWASP defines XSS as flaws that "occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user supplied data using a browser API that can create JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites (https://www.owasp.org/index.php/Top_10_2017-Top_10). Essentially, XSS allows an attacker to inject JavaScript code into a page. JavaScript is a client-side scripting language. With XSS, the JavaScript code is executed when the page loads and is executed on the client machine not the server.

There are three types of XSS attacks:

1. Stored XSS Attacks - These types of attacks are also known as persistent attacks. The JavaScript code gets stored into the database so anytime someone accesses that specific page, the code will be executed.
   
2. Reflected XSS Attacks - These attacks occur when the malicious code only run when a target users visits a specific URL crafted or written by an attacker. Simply put, the attacker injects browser executable code within a single HTTP response.
   
3. DOM Based XSS - According to OWASP, DOM based XSS "is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment" (https://www.owasp.org/index.php/DOM_Based_XSS). 

There are a number of ways to test for XSS vulnerabilities. The easiest ways are:

1. Try to inject JavaScript code into pages
   
2. Test text boxes and URL parameters into input boxes

This post is going to explore different attacks using the reflected XSS attack method. As always, Kali Linux (https://www.kali.org/downloads/), installed on VirtualBox (https://www.virtualbox.org/wiki/Downloads). Additionally, Metasploitable 2 installed on VirtualBox was also utilized. Lastly, the Damn Vulnerable Web Application (DVWA) as well as Mutillidae was used to examine reflected XSS attacks. According to OWASP, Matillidae is "a free, open source, deliberately vulnerable web-application providing a target for web-security enthusiest. NOWASP (Mutillidae) can be installed on Linux and Windows using LAMP, WAMP, and XAMMP for users who do not want to administrate a webserver" (https://www.owasp.org/index.php/OWASP_Mutillidae_2_Project).  More information about DVWA can be found on some of my previous blog posts.

The first step was to ensure that the security settings on DVWA were set to low.

Next, navigate to the Reflected Cross Site Scripting (XSS) tab and enter a name in the box. I used my first name for this test. 

Once you have entered a name, click the Submit button. Notice that the name entered now also appears in the URL.

Instead of passing a name in the input box, I decided to see if I could pass a simple JavaScript code <script>alert("XSS")</script>. The code is written to simply return a popup on execution that reads XSS. To execute, simply click submit.

The code was executed and returned the expected popup, as seen below.

I conducted the same attempt after increasing the security level of DVWA to medium.

I then tried injecting the script using the same method that was used previously.

As you can see from the results, the script was not able to execute. The filtering on the medium security setting filters for script. To bypass this, I used a method used in previous exploits by playing with the cases. By capitalizing some of the letters in the script tag.

This method was successful.

OWASP also has some recommended methods for bypassing filters to aid for a successful execution of a reflected XSS attack (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet). For this, I used the script <IMG SRC=/ onerror="alert(String.fromCharCode(88,83,83))"></img>.

This was also successful.

Using Mutillidae, I was also able to conduct a successful reflected XSS attack.

For this attack, I used the password generator feature.

When you first generate a password, the site creates a password for username anonymous. You can see this in the URL.

To test and see if the site is susceptible to any attack, I changed the username to 'adam' and regenerate a password. This worked and created a new password for the username changed in the URL parameter.

I attempted to inject the alert script used in DVWA. This did not work and returned an error, however, the error returned code on the page which is an indication that there is something broken.

I right clicked on the error and inspected the code. The script that was trying to be injected was being passed into another script tag. 

To get this script to execute, I needed to make some modifications. First, the script tag around it needed to be removed. Second, the quote for "This password is for... needed to be closed. Once the quote was closed, a semicolon needed to be added to run the second command within the script tag. Once this was added, the malicious code could be added and also finished with a semicolon. Finally, two backslashes which treats everything trailing as a comment so nothing past the malicious script can be executed.

I found an online application by Google called Gruyere (https://google-gruyere.appspot.com/) that is used to help people like me discover and exploit web vulnerabilities. To start, you will need to create an account.

Once your account has been created, I navigated to the upload tab. I first wanted to see if I would be able to upload a script file to successfully deploy a XSS attack.

I opened notepad, a created a simple JavaScript script that would return the session cookie. The script I used was <script>alert(document.cookie)</script> and I saved this as an .html file.

Next, I uploaded the file to Gruyere.

I navigated to the URL provided.

While this attack is not considered a reflected XSS attack, Gruyere does have that vulnerability to test. To do this, navigate to the home page and add the script <script>alert(document.cookie)</script>  to the end of the URL (ex. http://google-gruyere.appspot.com/123/<script>alert(document.cookie)</script>).

According to the Gruyere documentation, "To fix, you need to escape user input that is displayed in error messages. Error messages are displayed using error.gtl, but are not escaped in the template. The part of the template that renders the message is {{message}} and it's missing the modifier that tells it to escape user input. Add the :text modifier to escape the user input:

<div class="message">{{_message:text}}</div>

This flaw would have been best mitigated by a design that escapes all output by default and only displays raw HTML when explicitly tagged to do so. There are also autoescaping features available in many template systems" (https://google-gruyere.appspot.com/). 

This post only focused executing reflected XSS attacks. In future posts, I will explore how to execute stored and DOM based XSS attacks.