DVWA shows this vulnerability by a basic guestbook application, the user enters a name and a message and it will be publicly displayed. This seems like a fairly innocent webapp however, it is vulnerable to XSS.
On low security, DVWA has no protection against XSS, any input will be accepted and stored. The only protection on low security is the name field being limited to 10 characters which means there is very little opportunity for XSS, however, this limit is client side so it can be easily bypassed but I’ll come back to that later.
XSS is most commonly done by including script tags in an input. If we submit the following comment:
This time, DVWA has a bit of protection against XSS. If the same message used for low security is sent again, the message ends up like this:
Changing the maxlength attribute to 100 is more than enough to include an XSS attack in the name.
When this message is submitted, you would expect it to function exactly the same as last time. However, the comment is shown like this:
This means the developer is removing script tags from the name input. The script tags have been removed instead of being sanitised, this means the developer is likely using a find and replace to remove the script tags. Assuming it is just a simple find and replace, doing something to make the input unique will avoid it. In this case, changing the case of some letters will avoid the find and replace.
When this message is submitted, it will bypass the XSS filter because it is only looking for <script> and not <Script>. This happens because web browsers are made to process any bad input so whilst the script tag should be lowercase, it will still accept one with upper case however the find replace is only looking for lower case script tags.
When the website loads, we see the message box which proves the XSS has worked.
On high security, this is much harder to exploit. Using similar input to medium security gives an unexpected result.
Whilst its obviously not XSS, it isn’t anywhere near what a good XSS filter would show. Because its left one angle bracket at the end, it appears to be removing instances of the word script and everything between them. If we can include html, we can include XSS even if it’s not using script tags. The following input is simply a test to see if html can be included:
When the page loads, the name appears as an invalid image and a popup appears which proves that XSS happened.
XSS can be mitigated by proper input sanitising. This can be done manually by, for example using htmlspecialchars after stripslashes in php(this is DVWA’s impossible level – it is completely secure), however, there are lots of ways it can go wrong depending on the context of the input so it is recommended to use an encoding library such as Zend Escaper to prevent XSS. If you still want to try and prevent it manually, OWASP provide a set of rules to follow to filter XSS.
DVWA is easy to set up and is definitely worth using to test your skills. In the next few weeks, I will explain more of the vulnerabilities in DVWA.