Reading tons of pages of Reflected XSS and how it works, could not be enough to understand deeply, so DVWA comes again to our aid.
The best way to make the concept our own is, as usual, the practical one.
In this article, we are going to explore DVWA (Damn Vulnerable Web Application), an application which was the first gym for many great hackers!
If you are not knowledgeable about the subject I suggest you look at my previous articles about XSS.
- 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
Now, before starting to exploit, we need to run an instance of DVWA.
I’m quite lazy, so I’m going to opt for the TryHackMe machine as I already did in the tutorial about SQL injection.
Once everything is ready, Let’s start to exploit!
Step #1. Reflected 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 we are ready to hone our evil skills!
Click on XSS ( Reflected ) on the left side menu.
The goal of the exploit is to make the page execute arbitrary code, in this way the attacker would be able to steal cookies or maybe make malicious activities with browser exploitation tools like Beef.
In this tutorial, we are going just to see a proof of concept, but I will show soon, in my next articles, something cooler.
We can consider the level as passed if the website runs our code, in this case, a simple alert popup.
At this level, we can see an input text where we can insert a name.
What we can do in order to know if it’s a vulnerable field is to insert a custom HTML and see if the tags are filtered in some way.
Let’s try with this input:
<h1>StackZero</h1>And the result is encouraging, there is no filter on the H1 tag:
For further confirmation by pressing CTRL+U, we can see the source code
<div class="vulnerable_code_area">
<form name="XSS" action="#" method="GET">
<p> What's your name? <input type="text" name="name">
<input type="submit" value="Submit">
</p>
</form>
<pre>Hello
<h1>StackZero</h1>
</pre>
</div>I just picked the code of interest and we can see that everything we wrote is reflected on the page without any elaborations.
It’s clearly a good candidate for our exploit!
This time we can try to submit this script
<script> alert("You have been hacked!"); </script>And it worked! The browser executes our code!
Take a quick look at the URL, you should see something like this: http://10.10.151.212/vulnerabilities/xss_r/?name=%3Cscript%3E+alert%28%22You+have+been+hacked%22%29%3B+%3C%2Fscript%3E#
It’s URL encoded and contains the exploit in the query string.
So, just to be clear on how it can be used for an attack; an attacker can send this URL to his victim and make his/hers browser execute that malicious code.
The victim would be more confident because of a probably trusted domain.
Step #2. Reflected XSS on DVWA with medium security
Before proceeding with step two, go to the DVWA settings and set the security as medium
The way to solve the problem is by using input sanitization. However, sometimes, developers don’t do it as well as it has to ( maybe they write a quick custom function which doesn’t cover the more complex exploits).
In this step, we are going to see that the server just removes the tag <script> probably by using either a Regular Expression or a replace function.
Our first try can be just by inserting the same input as the previous step and seeing the result.
By looking at the HTML code with CTRL+U combination this is the section we are interested in:
<div class="vulnerable_code_area">
<form name="XSS" action="#" method="GET">
<p> What's your name? <input type="text" name="name">
<input type="submit" value="Submit">
</p>
</form>
<pre>Hello alert("You have been hacked"); </script>
</pre>
</div>So the server removes the script open tag.
We know that the browser doesn’t care if a letter is uppercase or lowercase (Case-insensitive).
On the contrary, PHP functions are mostly case sensitive, so a nice turnaround can be to alternate randomly upper and lower case characters (hardly the developer would manage every possible combination with the str_replace function).
Let’s try with this input:
<sCRiPt> alert("You have been hacked!"); </script>And our assumptions were correct!
Step #3. Reflected XSS on DVWA with high security
In order to try our hand at the next step, we need to set the security level as high.
This level of DVWA provides for a slightly higher degree of security, so we need to bypass a bit more sophisticated filter.
Before writing our exploit, let’s try with the one in the previous level and look at the result.
This time, as we expected, it doesn’t work, but knowing the output can help us!
So let’s see the source code by pressing CTRL+U.
<div class="vulnerable_code_area">
<form name="XSS" action="#" method="GET">
<p> What's your name? <input type="text" name="name">
<input type="submit" value="Submit">
</p>
</form>
<pre>Hello ></pre>
</div>It has removed the <script> tag, now we want to know if it does the same with another HTML tag, for example <h1> as we did in the first step!
It works! So probably the server just filters the input with a regex. What we can do to evade this filter is try to run javascript from another HTML tag like <img>.
For example, we can add an image from an inexistent URL and then launch our alert in an onerror event in this way!
<img src=X onerror="alert('you have been hacked!')">After clicking the Submit button, the result proves we are right!
Conclusion
As we have seen there are many turnarounds against XSS filters, so a filter implementation error can be very dangerous for a web application.
A more secure way to avoid the XSS threats is by using the function htmlspecialchars in PHP or the equivalent one in your favourite programming language.
In order to better understand the topic, I suggest you view the source code at every level (bottom-right button) and try different methods to exploit the vulnerability.
A good resource to have an idea of how to bypass XSS filters comes from OWASP and is here, you can take a cue from there before writing your exploits.
I hope it was useful for you, and if you liked this content follow my work to get more!
See you soon!
