DVWA: Damn Vulnerable Web Application Cross Site Scripting (XSS Stored) (Low, Medium, High)

 "Disclaimer: The information provided in this article is intended for educational and research purposes only. It is not intended to promote or encourage any illegal or unethical activities. Always act responsibly and obtain proper consent before using any tools or techniques described in this article." 

XSS is a technique in which attackers inject malicious scripts into a target website and may allow them to gain access control of the website. If a website allows users to input data like comments, username field, and email address field without controls then an attacker can insert malicious code script as well.

Types of XSS:

1. Reflected XSS
2. Stored XSS
3. Dom Base XSS

In this tutorial, we will cover, Stored XSS(cross-site scripting):

Stored XSS occurs when the input supplied by the user is stored on the server side without performing proper sanitization or HTML encoding. The storage place can be a database, a message forum, a visitor log, a comment field, etc. Instead of reflecting back immediately, it may reflect back when you login into the website next time. When you visit the vulnerable web page you will get a pop-up as an alert window. Stored XSS is more dangerous than reflected XSS because it will harm the whole community just by popping an alert box on every user’s browser who visits the vulnerable page. The payload used in stored XSS is the same as reflected XSS.

Let's Start Our Tutorial Now

This tutorial demonstrates how you can complete an XSS attack on DVWA (Damn Vulnerable Web Application).

• Kali Linux

• DVWA

Lab requirements

This tutorial assumes you have set up the required lab environments to run the penetration test. If you need help setting up DVWA, Please comment I will post an article regarding it soon.

Navigate to the DVWA web page, login and set the security to ‘low’, and go to XSS stored.

As usual, the low level in DVWA it’s a kind of warmup, so we can try to type just the basic exploit into the textbox “Message”.

Let’s write

<h1>Oyee Coder<h1> 

 

And it worked perfectly, there is no filter on the H1 tag.

This time we will enter the payload,

<script> alert("Hacked By Oyee Coder") </script>

in the message field and submit the request.

Now we will reload the page and check if the alert popup is still alive or not. 

And it worked, we can see a popup box on the page after reloading which confirms that it is vulnerable to stored XSS. The browser executed our code from the message box and we successfully exploited it at low-level security. As the script is stored in a guestbook’s comment, that’s the real difference with the Reflected XSS! 

The tutorial for XSS Stored on medium and high security will follow soon.

If you got stuck or have any questions, leave a comment, and I’ll do my best to get back to you.