Posted in Penetration Testing, web app testing

XSS (Reflected) DVWA

I was in two minds on whether to write this up as Cross Site Scripting (XSS) is such a massive subject and this really just touches the foundations, however, I’ll give it a go.

What is Reflected Cross Site Scripting (XSS)? (From the OWASP website)

Reflected Crosssite Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page.

Put simply, the attacker is able to send malicious javascript code to a victim via a crafted  link and on opening the the victim is met with whatever the javascript code was designed to do reflected to the screen. That, it seems, is in its simplest form. I will hopefully explain further below.

Damn Vulnerable Web App

An excellent resource for any new person training in web application security. On clicking the “XSS (Reflected)” link you will see this screen.

Figure 1 – Default state of the XSS app

A simple question. What is your name? When a name is entered it will be displayed back to you on the web page.

Figure 2 – Any data entered is displayed on the webpage

During testing, it seems that any data we enter is displayed back to us, and is contained in the core HTML code of the site.

Figure 3 – Entered data forms part of the web apps html code

If we look at the source PHP code for the app

Figure 3 – Source PHP code

The PHP code just uses the GET function to pull the entered ‘data’ and then display it back to the user. This could prove to be dangerous if there is no checking of the submitted data.

Executing XSS

The most common way to test for Cross Site Scripting is to try and pop an alert box to the screen by getting the browser to run your malicious javascript code. This can be done with a simple addition to the URL.


*Wordpress removes the script tags from the above code. See real URL below

Figure 4 – URL with malicious script added

When the link is executed by the victim, the screen should show a pop up alert with the number zero in it.

Figure 5 – A successful XSS attack

If the attacker sends the above link to anyone it would execute the javascript code unless something was done to prevent this attack. Looking at the PHP source code available to use, there doesn’t seem to be any checking of any kind and because the site is designed to display the entered data into the website again, the javascript code is executed.

Figure 6 – Confirmation that the alert box script is a part of the sites code

The browser will execute the code it is given which results in the alert box pop up. There are many uses for this kind of attack. A more common attack is to steal a users session cookie while they are still logged in meaning the attacker can be logged in as that user simultaneously.

How can we protect against this?

DVWA has some added security settings (Medium & High) to show how to protect against this type of attack, however, you will see that this too can be circumvented to still display the pop up alert box. The alert box simply shows that the site is vulnerable to XSS. It shows the site managers that it is possible to run any javascript code in one HTTP request and have it reflect back to the user who is sent the link. This can be very damaging to end users.

The next post will delve a little deeper into how the Medium and High settings try to prevent this attack but we can still get around the measures put in place to stop the attack.


One thought on “XSS (Reflected) DVWA

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s