DVWA - XSS (Stored)

Information

• How to install dvwa on Kali.
• Official GitHub repository.

The DVWA server itself contains instructions about almost everything.

Damn Vulnerable Web Application (DVWA) is a PHP/MySQL web application that is damn vulnerable. Its main goal is to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and to aid both students & teachers to learn about web application security in a controlled class room environment.

The aim of DVWA is to practice some of the most common web vulnerabilities, with various levels of difficultly, with a simple straightforward interface.

The DVWA server has 4 different security levels which can be set as seen below:

• Low: This security level is completely vulnerable and has no security measures at all. It’s use is to be as an example of how web application vulnerabilities manifest through bad coding practices and to serve as a platform to teach or learn basic exploitation techniques.
• Medium: This setting is mainly to give an example to the user of bad security practices, where the developer has tried but failed to secure an application. It also acts as a challenge to users to refine their exploitation techniques.
• High: This option is an extension to the medium difficulty, with a mixture of harder or alternative bad practices to attempt to secure the code. The vulnerability may not allow the same extent of the exploitation, similar in various Capture The Flags (CTFs) competitions.
• Impossible: This level should be secure against all vulnerabilities. It is used to compare the vulnerable source code to the secure source code.

Cross-Site Scripting (XSS) (Stored)

XSS attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application using input from a user in the output, without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the JavaScript. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

The stored XSS is stored in the database. The stored XSS is permanent, until the database is reset or the payload is manually deleted.

Objective: Redirect everyone to a web page of your choosing.

Security: Low

Low level will not check the requested input, before including it to be used in the output text (Source code).

1. There are 2 input fields: Name and Message. Let’s start with something simple to see if it works:

    <script>alert("XSS")</script>
   

   

2. Let’s try the payload we used in both previous sections, DOM and Reflected XSS, but this time instead of stealing the cookie we will redirect the users to another site:

    <script>window.location='https://cspanias.github.i
   

3. So it seems that a character limit is set for both fields that does not allows us to input our payload. We can modify the character length as follows:

   

   The maxlength is set to 50 characters, so let’s change that to 250:

   

4. Let’s try inserting our payload again:

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

   Once we press enter:

   

   Now, if we go back to DVWA home, and we click on the XSS (Stored) tab, we will be automatically redirected to https://cspanias.github.io.

5. For clearing the guestbook, we need to go to the DVWA homepage and change the security level to Impossible. Once this is done, we can safely go to the XSS (Stored) tab and clear the guestbook:

   

   

Security: Medium

The developer had added some protection, however hasn’t done every field the same way (Source code).

1. This time the developer has put a great effort in sanitizing the Message field, but not so much the Name field. For the latter, the <script> tag is getting removed, so we can try any of the methods used on the XSS (Reflected) task, after first changing the field’s maxlength:

   

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

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

    <scr<script>ipt>window.location='https://cspanias.github.io/'</script>
   

   

Security: High

The developer believe they have disabled all script usage by removing the pattern <s*c*r*i*p*t (Source code).

1. This time the developer changed the blacklisted pattern to <s*c*r*i*p*t, exactly like the High level of the XSS (Reflected) task. This blocks our last two attacks from the Medium level as they include the <script> tag, but not the first one:

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

   

   Don’t forget to increase the value of the maxlength variable.

Security: Impossible

Using inbuilt PHP functions, such as htmlspecialchars(), its possible to escape any values which would alter the behaviour of the input (Source code).

Resources

• Cryptocat’s video walkthrough.
• OWASP’s Cross Site Scripting (XSS).
• GitHub’s XSS Payload List.