DVWA Walkthrough XII - Stored Cross Site Scripting (XSS)

To further your understanding of DVWA, explore the comprehensive DVWA walkthrough or browse the full DVWA series to master every vulnerability level.

Stored Cross Site Scripting (XSS)

What’s this?

Stored XSS occurs when malicious scripts are injected into persistent storage like databases via user inputs (e.g., comments, profiles) and served to all subsequent visitors, executing in their browsers. PortSwigger Academy describes this persistent variant as more dangerous than reflected XSS since it affects multiple users automatically without needing phishing links. In DVWA, it simulates unsafe storage and output of inputs across security levels.

Stored XSS compromises all site visitors, enabling mass session theft, data exfiltration, or worm-like propagation until remediation.

Objective

The main goal of this module is to redirect everyone to a web page of your choosing.

Notes

Anytime you need to clear the guestbook, access the module with security level impossible and clear it.

Security: Low

Help
Low level will not check the requested input, before including it to be used in the output text.

Check the source code here.

At this security level, we have a guestbook where we can leave messages without any security measures in place. We can simply post a comment containing a payload, and every time a user visits the page, the JavaScript code will execute:

<script>window.location='https://ch3ngo.github.io'</script>

When we try to submit the payload, it gets cut off halfway. This happens because the input field has a length restriction. We can bypass it by modifying the HTML on the fly using the browser’s developer tools:

After removing the restriction, we can submit the payload successfully. Any user who visits the guestbook page will now be automatically redirected to the attacker-controlled site.

Security: Medium

Help
The developer had added some protection, however hasn’t done every field the same way.

Check the source code here.

In this case, the message field is properly protected, so we can’t exploit it directly. However, the name field is still vulnerable. We can abuse it by using an <svg> tag to execute JavaScript code. As before, we need to remove the maxlength parameter from the HTML:

<svg/onload=window-location='https://ch3ngo.github.io'>

Security: High

Help
The developer believe they have disabled all script usage by removing the pattern “<s*c*r*i*p*t”.

Check the source code here.

This security level can be exploited in the same way as the medium one. The code was only modified to apply stricter <script> tag filtering, but it still fails to prevent alternative Cross-Site Scripting techniques.

References

• PortSwigger Stored XSS

Wanna talk? Contact me here!