Pentesterlab is a website where you can find many vulnerable VMs in their exercises section. On the homepage it states, “Learn Web Penetration Testing: The Right Way” which I assume they mean by hands on experience. This is the best approach and this article aims to break down some of the things I learned while working on these exercises. These exercises not only provide the pre-configured ISO prepared for testing, but they also include a course to go along with it. I highly recommend reviewing the course material to get a better understanding of the topic. This particular vulnerable VM focuses on web application pentesting and its fundamental elements.
To get both the ISO and the course, click here
XSS (Cross site scripting) challanges
In these exercises we explore reflective cross site scripting. This is a technique in which user supplied input is reflected back to the page in the source code. This enables an attacker to include his/her own source code(script code) into the victim’s browser causing it in some cases to be executed. In these examples the XSS is not stored on the page and therefore can only be accessed through a crafted url. A wide variety of attacks can be carried where XSS can be found.
This first example is very easy but for educational purposes I will explain it in great detail. The first part of the url is the ip address(192.168.50.103) of the vm but in some cases it will be a full qualified domain name such as sneakerhax.com. The /xss/ represent the folder the file we want to load is in followed by the file we want to load which is example1.php. The next piece of information to review is the ? which means you are about to pass a parameter to the page which in this example is name=hacker. Notice that the passed parameter is reflected back to the page without modification. This is the essence of reflective cross site scripting. Since all this information is all sent in the url it is a GET request. If you inspected the page source you would see that the information passed into the parameter gets incorporated into code on the page.
192.168.50.103 This will usually be a website name
/xss/ The folder name
example1.php The file name
?name=hacker The parameter which will be reflected back in the page source code
So what if you were to put some script into the passed parameter? What if this was incorporated into the page source? In my solution I replace “hacker” with <script>alert(‘xss’)</script> which is a common technique used to test for cross site scripting. Off course this can get far more complicated as restrictions are put into place. After doing this and refreshing the page you can see that the script was in fact incorporated into the page source and run. This produced our pop up window confirming the xss vulnerability as seen below.
This is an extremely simple xss challenge but a great example for people trying to understand the concept. Owasp Cross-site Scripting(XSS) provides more detailed information and some great examples.
Now let’s move onto example 2 of the XSS challenges. It appears very similar but if you attempt the same attack it will fail because there is now some sort of filtering for xss. I have to admit this one threw me off for a few minutes because I was overthinking it:
Challenges like this have led me to a great resource provided by Owasp called the XSS Filter Evasion Cheat sheet
After a few minutes of testing I realized that there was a simple block in place to stop the use of <script> from being used in user input. However it was weakly implemented and simply putting <sCript> or any variation will bypass the filter.
The starting page is the same on 1-7 so I will only paste the solution. My solution was different than the one pentesterlab provided. In my solution I figured out that anything with <script> was not making it back into the source. I started using the inspect element window to quickly review what the source code looked like after running my request.