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

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

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.

Security level low

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

Stored XSS


  • 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.

HTML Injection confirmed

  • 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>

Testing for Stored XSS and HTML injection

Hacked pop up alert

  • 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>

Stored XSS payload



Security: Medium (Stored XSS)

  • Setting the security to medium and PHPIDS as disabled.

Security level medium

  • 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.

Win Win

  • 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>

Stored XSS payload input

  • 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.

XSS payload


Hacked pop up alert

  • 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>

XSS payload




Security: High (Stored XSS)

  • Setting the security to High and PHPIDS as disabled.

Security level High

  • 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.

Stored XSS

  • 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>

XSS payload


Hacked pop up alert

  • 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>

XSS Payload

Love from Titans



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



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”.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top