Today we're going to continue our journey through the word of web application security - more accurately XSS exercises from PentesterLab. It's great way to practice what we have learned so far and also - good challenge. Let's jump into the first one!
Here we have a very basic example of Cross Site Scripting where you have to change the variable that is visible in the URL (which is our example is name=hacker) into the alert script that will allow us to see whether if it works.
Great, it works perfectly, let's move to the next one!
Firstly I wanted to try whether the method from the previous one works but as I suspected it didn't. What we got after entering script was this source code.
It may be somehow filtering our input - maybe changing it to uppercase will help us?
Great! It works and we've bypassed the filter. Let's move on to the next one!
This one is a little harder - it doesn't allow script or even sCript so we have to try something else. From what I learned about methods to bypass filtering it may be possible to use this simple trick.
If you don't know how this works - the filter firstly looks for script tag, deletes it, and then sends the result. But after taking out the script two other parts scr and ipt will merge into one creating our payload.
Here it looks like more advanced version of filter, it completely takes out the word script and when the request matches script, it will stop. So what options do we have to bypass it? We can put img tag with some attributes allowing us to create a paylod. Onmouseover will be an excellent example but you can use any other you will think that will work.
It will even better work with onerror since it will execute automatically when the page loads.
This one is a little trickier - it allows script tags but doesn't allow alert function. How can we make it alert something without actually typing it? We can translate this into the ASCII characters.
Which after small redesign will result in actually working XSS!
Here w're dealing with similar challenge as in the previous one.
Using the previous strategy I manage to get the XSS alert working.
Hmmm... We've got the input field that will not allow any of our XSS tricks. I actually had no idea how to attack this example so I checked out hints provided by PentesterLab. Let's take a look at them.
Here, the value echoed back in the page is correctly encoded. However, there is still a XSS vulnerability in this page. To build the form, the developer used and trusted PHP_SELF which is the path provided by the user. It’s possible to manipulate the path of the application in order to:
- call the current page (however you will get an HTTP 404 page);
- get a XSS payload in the page.
This can be done because the current configuration of the server will call /xss/example8.php when any URL matching /xss/example8.php/... is accessed. You can simply get your payload inside the page by accessing /xss/example8.php/[XSS_PAYLOAD]. Now that you know where to inject your payload, you will need to adapt it to get it to work and get the famous alert box.
Wow, I haven't thought about that. Let's see what happens if we simply add it /xss/example8.php/[XSS_PAYLOAD] like in here.
But it still doesn't work. We have to somehow tweak it into the working version.
If we take a look at it a little closer we can see that if we add "> after the example8.php it will close the path and allow script to execute.
To the last one!
By looking at the source code it reveals to us that the script is simply executing everything after the hash string.
Solution will look like this. I don't know why but it worked for me only in Chrome browser, not in Firefox. Luckily we managed to complete this set of exercises.
Thanks for tuning in! It was great challenge, and I'm sure to complete other exercise on Web for Pentester ISO. Hopefully there will be more XSS challenges as I'm really enjoying them.
Keep learning and stay safe! ~ W3ndige