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

In this walk through, we will be going through the Stored Cross Site Scripting vulnerability section from DVWA Labs. We will be exploring and learn about Stored 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.

Stored Cross Site Scripting Attacks:

Stored Cross Site Scripting (XSS) Attack is an attack where the attacker’s sent malicious input is stored in application’s database. This type of XSS attack is devastating as it is persistent and affects all the users accessing the application. In terms of exploitability, the key difference between reflected and stored XSS is that a stored XSS vulnerability enables attacks that are self-contained within the application itself. The attacker does not need to find an external way of inducing other users to make a particular request containing their exploit. Rather, the attacker places their exploit into the application itself and simply waits for users to encounter it.

Security: Low (Stored XSS)

• Setting the security to low and PHPIDS as disabled.

• The application has a typical comment box system where a user can comment with his name and a message.

• I tried to test if the application is sanitizing the user input when i uses the bold HTML tag but it didn’t. It executes the code as and makes my input comment bold.

• After analyzing application’s source code. I can see that a the application is issuing a post request after getting the user’s name and message as parameter. Any scrutiny is not being done for on the user’s input.

• Let’s add a comment in the application which will store the DB but will have our payload inside it. Once stored in the application, any user which hovers on the comment executes the code unknowingly.

<b onmouseover='alert("Hacked")'>Spartan</b>

• Now as per the task objective, let’s redirect the user to our specified webpage (maybe malicious). Here we are commenting a “w” which when hovered by any user will redirect him to x or twitter.com. The comment box does not allow larger length that this, that’s why a short redirect URL and comment is used here.

<b onmouseover=window.open("http://x.com")>w</b>

Security: Medium (Stored XSS)

• Setting the security to medium and PHPIDS as disabled.

• As per our last test, the application let us comment on the server and our comments gets stored in the DB which can be viewed by other users.

• After analyzing the application’s source code found out that the application is stripping some tags in message field and sanitizing the name field by changing the script tags to null value. We have to circumvent this in order to execute our payloads.

• I used the mouseover payload that we first used to check the existence of XSS in the application however it didn’t work as the application strip out the tags from our message field.

<b onmouseover='alert("Hacked")'>Spartan</b>

• Next, i wanted to try the same payload in the Name field as it was just checking for the script tag however i wasn’t able to input the full payload in the application as it was trimming the input to 10 characters. So, i intercepted the request via Burpsuite and manipulated it over there and sends the request back to the application which saves my malicious comment in the DB which when hovered on executes the script.

• Let’s use the same technique to redirect the user to another URL here x.com using the below payload.

<b onmouseover=window.open("https://x.com")>Kratos</b>

Security: High (Stored XSS)

• Setting the security to High and PHPIDS as disabled.

• As per our last test, the application let us comment on the server and our comments gets stored in the DB which can be viewed by other users.

• After analyzing the source code, i found out that the application is now sanitizing all the input in the name filed related to script tag in the name field. The message field is still sanitizing all the tags. We have to bypass it in order to execute our payload.

• Let’s try the below payload in the name field and see it works.

<b onmouseover='alert("Hacked")'>Kratos</b>

• The above payload worked like a charm as it did not use the script tag to execute any code. Let’s use the same technique to redirect the user to our specified URL using the below payload and complete this task.

<b onmouseover=window.open("https://x.com")>Kratos</b>

Also Read: DVWA – SQL Injection (Low/Med/High)

Conclusion:

So, we finally completed all the security levels for the DVWA Stored 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 Stored XSS attacks by performing input sanitization and encoding special characters to ensure that the program interprets them literally and use choose certain javascript framework like Angular and react that are not inherently susceptible to the attack. On that note, i will take your leave and will meet you in next one with another DVWA vulnerability writeup, till then “Keep Hacking”.