StackZero
  • Homepage
  • Cryptography and Privacy
  • Ethical Hacking
  • Reverse Engineering
  • Contacts
  • About Me
No Result
View All Result
StackZero
No Result
View All Result

How to exploit a stored XSS vulnerability on DVWA

September 24, 2022
in Ethical Hacking
0 0
How to exploit a stored XSS vulnerability on DVWA
0
SHARES
7.8k
VIEWS
Share on FacebookShare on Twitter

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):

  • The terrifying world of Cross-Site Scripting (XSS) (Part 1)
  • The terrifying world of Cross-Site Scripting (XSS) (Part 2)
  • XSS in practice: how to exploit XSS in web applications
  • Reflected XSS DVWA – An Exploit With Real World Consequences
  • How to exploit a stored XSS vulnerability on DVWA
  • How to exploit DOM XSS on DVWA

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!

Table of Contents

Toggle
  • Step #1. Stored XSS on DVWA with low security
  • Step #2. Stored XSS on DVWA with medium security
  • Step #3. Stored XSS on DVWA with high security
  • Conclusion

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
dvwa login page

The security level is set by default as impossible, so change it to low from the settings on the left sidebar:

DVWA set security

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!

stored xss dvwa low security exploit successful

Now try to reload the page and the alert popup is still alive because the script is stored into 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 by 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:

inspect stored xss vulnerable field on Firefox

Now with the double left-click onto 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:

stored xss dvwa medium security exploit successful

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, obviously, 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 Sign Guestbook button

This is the result:

stored xss dvwa high security exploit test

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 onerror attribute 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!

stored xss dvwa high security exploit successful

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.

Tags: application securitycybersecuritydvwajavascriptstored xssvulnerable applicationweb application securityweb exploitationweb securityxss
Previous Post

How To Perform Command Injection Attacks (DVWA) For Aspiring Hackers!

Next Post

How to exploit DOM XSS on DVWA

Next Post
How to exploit DOM XSS on DVWA

How to exploit DOM XSS on DVWA

You might also like

Cryptographic functions

Cryptographic Hash Functions in Python: Secure Your Data Easily

November 3, 2024
Malware Obfuscation Techniques: All That You Need To Know

Malware Obfuscation Techniques: All That You Need To Know

March 25, 2024
How To Do Process Enumeration: An Alternative Way

How To Do Process Enumeration: An Alternative Way

March 4, 2024
How To Do DLL Injection: An In-Depth Cybersecurity Example

How To Do DLL Injection: An In-Depth Cybersecurity Example

February 8, 2024
Process Injection By Example: The Complete Guide

Process Injection By Example: The Complete Guide

January 24, 2024
How To Build Your Own: Python String Analysis for Malware Insights

How To Build Your Own: Python String Analysis for Malware Insights

November 10, 2023

StackZero

StackZero is a specialized technical blog dedicated to the realm of cybersecurity. It primarily provides insightful articles and comprehensive tutorials designed to educate readers on developing security tools. The blog encompasses a broad spectrum of subjects, starting from the foundational principles of cryptography and extending to more sophisticated areas such as exploitation and reverse engineering. This makes StackZero an invaluable resource for both beginners and professionals in the field of cybersecurity.
The blog covers a wide range of topics, from the basics of cryptography to the more advanced topics of exploitation and reverse engineering.

Tags

application security blind sqli blind sql injection bruteforce c cesar cipher command injection cryptography ctf cybersecurity debugging dom-based xss dvwa ethical-hacking ethical hacking exploitation file inclusion gdb hacking injection javascript malware malware analysis malware evasion network-security pentesting lab picoctf pico ctf python reflected xss reverse engineering sql sqli sql injection static analysis stored xss substitution substitution cipher vulnerable application web application security web exploitation web security windows windows api xss
  • About Me
  • Contacts
  • HomePage
  • Opt-out preferences
  • Privacy Policy
  • Terms and Conditions

Welcome Back!

Login to your account below

Forgotten Password?

Retrieve your password

Please enter your username or email address to reset your password.

Log In
Manage Cookie Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage {vendor_count} vendors Read more about these purposes
View preferences
{title} {title} {title}
No Result
View All Result
  • Homepage
  • Cryptography and Privacy
  • Ethical Hacking
  • Reverse Engineering
  • Contacts
  • About Me