Yet another walkthrough, this time I want to enforce your practical understanding of Stored XSS by exploiting DVWA again.
I just want to anticipate that the basic concept is not far from the reflected XSS we have already seen in our previous articles.
However, this vulnerability can be far more dangerous than Reflected XSS due to its persistence.
Just to give you an idea of what I said, the only victim in the case of Reflected XSS is the receiver of the malicious URL, on the contrary, a Stored XSS can hit everybody who visits the exploited page.
Before we get into the world of Stored XSS vulnerability in practice I recommend you take a look at my articles about XSS (they are in order of difficulty):
After reading them, understanding what we are going to do will be a piece of cake!
Assuming you have the previous knowledge, now you should be familiar with what we are going to do.
But before starting to exploit, we need to run an instance of DVWA.
Even in this case, I’m going to opt for the TryHackMe machine as I already did in the tutorial about SQL injection (where you can find the instruction to launch it) and all the tutorials that include a DVWA machine.
So again, as we usually do, let’s get our hands dirty!
Step #1. Stored XSS on DVWA with low security
Before starting I just want to remember you that the default credentials are:
Username: admin
Password: password
The security level is set by default as impossible, so change it to low from the settings on the left sidebar:
Now it’s time to click on XSS (Stored) on the left sidebar and start exploiting the low level of DVWA.
As usual, the low level in DVWA it’s a kind of warmup, so we can try to type just the basic exploit into the textbox “Message”.
Let’s write:
<script>alert('You have been hacked!');</script>
And it worked perfectly, we have the popup!
Now try to reload the page and the alert popup is still alive because the script is stored in a guestbook’s comment, that’s the real difference with the Reflected XSS!
We can change the security level to “medium” and then go to the next step!
Step #2. Stored XSS on DVWA with medium security
The medium level of DVWA introduces another difficulty in our exploit. Trying what we did in the previous level seems not working.
We can also try what we did in the medium level of Reflected XSS in DVWA and try to play with uppercase characters like this:
<SCRIPT>alert('You have been hacked!')</SCRIPT>
It doesn’t work, but just to understand what is happening and if some tag can escape the filter, let’s try sending this string as a message:
<H1>Hello by StackZero </H1>
Again a failed attempt, but we are simulating a black box attack and we cannot read the PHP code, so before keep reading, try to guess our next move by yourself!
I hope you find the solution, but just in case you didn’t, don’t worry and keep exploiting together!
Before trying every single exploit, try to remember that we have two input fields, and we could try also to exploit the “name”.
The first obvious problem is that there is a limit to the input, but luckily the length check comes only to the client side.
If you want to get around it: inspect the element (Right click + Inspect on Firefox) and you should see this box:
Now with the double left-click on the “maxlength” attribute, you would be able to modify and set it to a higher value ( 100 for example) in a way that it can contain our exploit string.
Type a random message and the string below as a name:
<SCRIPT>alert('You have been hacked!')</SCRIPT>
Just click “Sign Guestbook” and look at the result.
It worked! The result is exactly what we expected:
Confident in our abilities, we are ready to change the security level to “high” and beat the next and final level!
Step #3. Stored XSS on DVWA with high security
Finally, we are at the high-security level something has changed and all the attempts we did before are useless.
However, we can note that if we:
Increase the maxlength attribute of the name
Type
<h1>StackZero</h1>Press the Sign Guestbook button
This is the result:
At a quick glance, the <h1> is totally accepted by the server and reflected into the comment, so the application seems to filter just the <script> tag.
We have a lot of possibilities now, but the easiest and fastest way to escape this particular filter, for me, is through the <img> tag.
The idea behind the exploit is:
Type a random comment (the field is mandatory)
Insert an image with a non-existent src value
Insert the inline javascript into the
onerrorattribute in this way:
<img src="x" onerror="alert('You have been hacked!')" />
After submitting the XSS exploit the page reloads and…
BAM! We hit the mark!
There was not so much more than what we have seen in the other tutorials, but I’m sure that this write-up helped you think a little bit more like a hacker.
Conclusion
I hope this tutorial helped you to better understand Stored XSS in a practical way and to know its danger even in relation to its little brother (Reflected XSS).
By the way, XSS is one of the most widespread vulnerabilities on the web, so in order to master the concepts I suggest you to:
Read carefully all the previous tutorials linked in the introduction
Take a look at some cheat sheets like this one and understand the exploits deeply
Try to read the code which leads to the vulnerabilities in DVWA (the bottom-right button “View Source”)
Try to build and exploit your personal vulnerable application
In conclusion, remember that a real hacker never stops learning and looks at problems from different angles.
So, after being the attacker, try to assume the role of the developer and imagine where a vulnerability can occur in your code and how you could fix it!
If you enjoyed the article please support me by following my blog and all my social profiles.