DVWA Part 2: Exploiting Cross-Site Scripting (XSS) Vulnerabilities

Published by Ryan Beegel on

For the second installment of our DVWA series, we are going to look at cross-site scripting (XSS) vulnerabilities and how to exploit them in our Damn Vulnerable Web Application. If you missed part one of this series that shows you how to set up DVWA, you can check it out here.

What is XSS?

Cross-site scripting (from here on out, referred to as XSS) is an injection attack in which malicious scripts are injected into a web application. XSS allows an attacker to send a malicious script to a different user of the web application without their browser being able to acknowledge that this script should not be trusted. The user’s browser sees the script as code that originated from the web application, not from the attacker, and can allow the attacker access to information such as session IDs, cookies, and any other information stored by the browser to use for that site. Typically, web applications are vulnerable to this sort of attack in areas where user input is accepted, and the application does not validate it.

The Difference Between Stored and Reflected XSS

The two most common forms of XSS attacks are stored and reflected attacks. Stored XSS attacks, like the name states, stores the script in the website. For example, this can occur in a message forum. The XSS script is injected into the field submitted into the forum and the target runs the script when they visit the forum, and the page is retrieved by the browser. Reflected XSS attacks occur where the injected script is not stored but instead delivered through other means such as an email or search result.

Checking for XSS Vulnerabilities

To check for a possible XSS vulnerability, you need to test every point of user input to see if you can inject HTML and JavaScript code and whether it gets delivered to the output of the page.

We are going to test for this using the XSS (Stored) page on low security in DVWA.

First, let’s check that our XAMPP server is up and running. Open up a terminal and check the status with the command /opt/lampp/lampp status. If the output shows that the services are running, then you are good to go. If the output shows that the services are not running, start them up with the command /opt/lampp/lampp start.

Let’s now navigate to our DVWA application at (refer to the link at the top of the page for part one of the series on how to set up DVWA).

Once logged in (username: admin; password: password), we want to navigate to the DVWA Security tab, select “Low” in the drop-down box, and hit Submit.

Now we need to navigate to the XSS (Stored) tab. Here we see a guestbook where users can enter their name and a message to submit to the page. We are going to test both of these for HTML and JavaScript injection.

First, we will enter a normal name and a message to see what the typical output is.

We can see that our responses are output to the page in a pretty standard text.

Now let’s see if the forms will allow us to use HTML tags to change the fonts of our responses.

As we can see by the output of our second post, the web app allowed us to change the HTML composition of the output by using bold and italic HTML tags for our input. This means that we may be able to inject other sorts of tags such as JavaScript tags.

The Name field only allows a certain number of characters, so we will attempt to add a JavaScript alert to the Message field using <script>alert(“JavaScript!”)</script>

When we submit this entry to the page, look what pops up! An alert stating “JavaScript!”.

We now know that we can inject JavaScript into this form. In the next section, we will take a look at how we can exploit this to get a valid user cookie and session ID

Stored XSS Exploit

Now that we know the page is vulnerable to XSS while on low security, let’s see how we can get our cookie and session ID to display.

To do this, we are going to use a similar JavaScript alert, but this time use document.cookie as the alert parameter.

Note: Hit “Clear Guestbook” button so that you do not get the previous “JavaScript!” alert.

We now have our session ID displayed to the screen. Because this is a stored XSS attack, this will be persistent until we clear the Guestbook. We can click out of the alert, change tabs, and then come back to this tab and this alert will pop up again which means that every time a user visits this tab, their session ID will be displayed in an alert.

Reflected XSS Exploit

Now let’s head on over to the XSS (Reflected) tab and check out how we can do a reflected XSS exploitation.

Our goal for this section is to create a URL that when clicked, displays our cookie and session ID in an alert.

Let’s get started by entering a simple response to the form to see what the standard output is and checking out the URL displayed.

As we can see, our input is taken and then displayed to the screen in the string “Hello [our input]” as well as in the URL where it is added as the value of the name variable.

Let’s now try and input the script that we used in the last section to display the cookie and session ID: <script>alert(document.cookie)</script>.

It works! Our session ID is posted to the screen in an alert, and when we take a look at the URL, it shows the script assigned as the value for the name variable.

Let’s take note of the URL that we want to have submitted to that page for the exploit to work:<script>alert(document.cookie)<%2Fscript>#.

In this case, the user’s cookies will not be displayed when they navigate to XSS (Reflected) tab on their own like in the previous section because the input we give the form is not stored in the application. Instead, we need to send the above link to a user in a social engineering attempt (such as a phishing email) to get them to send the reflected XSS attack themselves. Let’s try this out and open up a new tab and navigate to this link in the new tab (while keeping the previous tab open).

Success! When we navigate to the link, it again displays our cookie and session ID.

So there you have it. In this tutorial, we were able to exploit DVWA with both stored and reflected XSS to display the cookie and session ID in an alert. If we wanted to take this a step further for more practical use, instead of having the alert pop up for a user that visits the website, it could instead be sent to a remote server that we are running. This way, we receive the session ID and can authenticate as that user.

Categories: Tutorials


Ryan Beegel

Security professional and recent MS in cybersecurity graduate. Forever student interested in everything IT and security.

Leave a Reply