DVWA – Reflected Cross Site Scripting (Low/Med/High)

In this walk through, we will be going through the Reflected Cross Site Scripting vulnerability section from DVWA Labs. We will be exploring and learn about Reflected-XSS attacks and what makes an application vulnerable to it. We will start with the security level as Low and will gradually increase the difficulty as we progress further. So, let’s get started with the Hacking without any delay.

Reflected Cross Site Scripting Attacks:

Reflected Cross Site Scripting (XSS) is an attack where an attacker send malicious javascript in the an HTTP request and the application includes that data within the immediate response in an unsafe way. This type of XSS attack only affects the user that is currently accessing the application with the malicious code loaded in it. That means, in order to execute it on the victim’s machine, attacker have to send a malicious link to the victim. Once the victim clicks on the link, the attacker embedded javascript code will trigger on his browser and perform nefarious actions accordingly.

Security: Low (Reflected XSS)

• Setting the security to low and PHPIDS as enabled.

• The application consist of the form box which is asked for the user’s name and display it with greetings. It uses a GET request as per the intercepted request via Burpsuite.

• I analyzed the source code and it uses a get variable to get the name of the user and send feedback to the user. As we can see the header for “X-XSS protection” is set to 0.

• I tried the below generic payload to test the XSS vulnerability however got flagged.

<script>alert("Hello")</script>

• I disabled the PHPIDS and then test the same payload and got the response. Post this, i tried to bypass the PHPIDS using various payloads however was unable to do so. So, we will move ahead with PHPIDS as disabled.

• Let’s dump the user’s cookie with the below payload.

<script>alert(document.cookie)</script>

Security: Medium (Reflected XSS)

• Setting the security to Medium and PHPIDS as disabled.

• The application consist of the form box which is asked for the user’s name and display it with greetings.

• I tried the below payload to test the XSS vulnerability however it didn’t executed the javascript entered rather took as an Input.

<script>alert("Hello")</script>

• After analyzing the source code, i found out that the “X-XSS protection” header is still set to 0. Along with that, our input is being stripped out if script tag is used in it which we have to bypass.

• I manipulated the payload a little and i was able to get pass through the sanitization.

<sCriPt>alert("Hello")</script>

• Let’s dump the user’s cookie with the below payload.

<sCriPt>alert(document.cookie)</script>

Security: High (Reflected XSS)

• Setting the security to High and PHPIDS as disabled.

• The application consist of the form box which is asked for the user’s name and display it with greetings.

• I used the below payload that i used in the medium security level however the whole payload was stripped out by the application and only a “>” was included in the output.

<sCriPt>alert("Hello")</script>

• After analyzing the application’s source code, found out that the application is replacing the script tag in various format with null value making it harder for us to execute our payload.

• To bypass the above sanitization, i used the below payload which uses the body tag and execute a javascript code onloading of it and then trigger the alert. You can use various other payloads to circumvent this.

<body/onload=&lt;!--&gt;&#10alert(1)>

• Let’s dump the user’s cookie value with the below payload.

<body/onload=&lt;!--&gt;&#10alert(document.cookie)>

Also Read: DVWA – File Upload (Low/Med/High)

Conclusion:

So, we finally completed all the security levels for the DVWA Reflected Cross Site Scripting Vulnerability. We looked into the various ways how application has been set up in various levels and how we can bypass the security controls implemented. Next, we can mitigate the potential Reflected-XSS attacks by performing input sanitization on endpoints, whitelist the allowed characters in the input and using a WAF. On that note, i will take your leave and will meet you in next one with another DVWA vulnerability writeup, till then “Keep Hacking”.