Executing Stored Cross Site Scripting (XSS) Attacks

Last post focused on exploiting reflected cross site scripting (XSS) attacks. To refresh, a reflected XSS attack is when the malicious code only run when a target users visits a specific URL crafted or written by an attacker. This post focuses on the more dangerous stored XSS attack. 

A stored XSS attack occurs when the JavaScript code gets stored into the database so anytime someone accesses that specific page, the code will be executed. This type of attack is also known as persistent XSS.

For this lab, I used Kali Linux (https://www.kali.org/downloads/) installed on an Oracle VirtualBox (https://www.virtualbox.org/wiki/Downloads). I also used Metasplotable (https://information.rapid7.com/metasploitable-download.html) which comes with the Damn Vulnerable Web Application (DVWA) used to conduct this lab already installed. Lastly, I used the a vulnerable application by Google called Gruyere (https://google-gruyere.appspot.com/) to show different tactics that could be successful and were not used with DVWA.

Similar to past labs, I first wanted to ensure that the security settings on the DVWA were set to low.

Next, navigate to the XSS Stored page using the navigation tabs on the left of the DVWA page.

Simply add a name in the name input box and a message to see what the outcome is.

As you can see, the input has been added to the database and is now displayed on the page.

To test and see if this site is vulnerable to an XSS attack, I decided to add a new entry. This time, I entered Injection into the name input box and put the malicious payload into the message box.

As you can see, upon clicking the Sign Guestbook button, the script was successfully executed.

To demonstrate how a stored XSS attack works, I opened a private browsing session in the FireFox browser.

I navigated to DVWA from the private browser session. Once there, I clicked on the Stored XSS attack. The code was successfully executed.

Next, I adjusted the security settings to medium.

With this setting, the code needs to be input into the name field. However, there is a character limitation of 10 characters. To bypass this, I right clicked on the name field, clicked on Inspect Element, and adjusted the character length from 10 to 100.

Some sites run filters on both single quotes and double quotes. To bypass, - since the medium security setting prevent code from being injected in the message box -  the script needed to be injected into the Name input box. For this, I used one of the scripts from the OWASP XSS Filter Evasion Cheat Sheet (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet). I also used an online CharCode calculator(http://jdstiles.com/java/cct.html) for the string XSS Injected.

Upon submitting, the XSS was successfully executed.

As mentioned previously, I also conducted an experiment using Google's Gruyere. After logging in, I navigated to the Upload page.

Next, I simply opened Notepad and wrote the simple script <a onmouseover="alert(1)" href="#">Stored XSS Example 1</a> to upload to the Gruyere platform. I saved this file as an .html file before uploading. Once uploaded, I simply navigated to the URL where the file is stored.

I then decided to try a different approach using AJAX. AJAX allows programmers to "update a web page without reloading the page, request data from a server - after the page has loaded, receive data from a server - after the page has loaded, and send data to a server - in the background" (https://www.w3schools.com/xml/ajax_intro.asp). 

To initiate this attack, I navigated to the New Snippet page in Gruyere.

Once on the page, I simple input:

This is<span style=display:none>"

+ (alert("This is injected XSS so when a user hits refresh, this message pops up"),"")

+ "</span> the injected code!

into the input box.

Once I clicked Submit, the snippet was added, however, the XSS attack would not be run until a user clicked on the Refresh button.

Once the Refresh button was clicked, the code was executed and the stored XSS attack was successful.

This post explored how stored XSS attacks work. The next post will examine DOM based XSS attacks, and I will close this section out with a final post related exclusively to mitigating and fixing the risk of successful cross site scripting attacks.