We’ll now set up a rule inside the proxy intercept to alert us when we stumble across the vulnerable “comment” parameter.
So for this example let’s ignore the big comment box on the home page and pretend we didn’t see that. I didn’t pick the greatest example because the “comment” parameter shouldn’t be that hard to find in this application because it’s fairly small and the parameter is actually providing some context, adding a comment, which doesn’t always happen.
So the challenge is to find that “comment” parameter that burp flagged as vulnerable but without a simple GET request this can be difficult.
Burp suite scan code#
This is also reflected in burp where we see the 302 redirect status code that sends us back to the home page. Next I’ll paste the URL from the XSS finding into the address bar.Īfter I enter this request I get redirected to the home page. I’ll be starting out on the about page of the Peruggia application. Let’s walk through an example to understand the challenges. With a GET request this is easier but POST requests add a level of difficulty. Especially for XSS (cross site scripting) vulnerabilities I like to obtain screen shots of the alert box to prove to the customer that I was able to exploit the vulnerability. Because of this it can be hard to determine where in the application the vulnerability exists. This is the nature of POST requests we can’t just put the URL into the address bar and be take to that location. If you were to copy and paste the URL into the browser and make that request you’ll be redirected to the home page. In the top third tab we see the response was redirected which means we’ll get a 302 status code. Here we see it’s a POST request and I wanted to focus on a POST request because some of the challenges faced with these requests. I picked this request for a number of reasons but first let’s take a look the details of the request below. I’m going to focus on the highlighted cross site scripting vulnerability in the screen shot above. So I ran the active scan against peruggia and got the following results. I’ll be using an intentionally vulnerable web application named Peruggia found within the owaspbwa project which is a great project to learn web app testing. Let’s walk through an example of using the burp intercept feature to find where scanner results are located.
It’s even worse for POST requests because going directly to the URL without the parameters can produce errors within the application. Let’s say the scanner reports back that is vulnerable, well this is a generic URL without much context so it’s not obvious where you would have to browse to stumble upon that request. In big applications simply knowing a what GET or POST request is vulnerable may not tell you where the vulnerability lies.
It’s not crucial to know this because with burp or any decent web proxy we can replay that request to retrieve and prove the vulnerable results but when dealing with laymen and even developers you have to hand hold them through the exploitation process via the browser as much as possible hence the need to know where in the application the vulnerability exists. Meaning first click here, then here, then here, and modify parameter X. So you get the results back and you have some good findings but you’re not exactly sure where that finding resides inside the application. So the problem I have in my job and maybe others do as well is that when assessing a web application for vulnerabilities you want to throw automated tools at it first to get the low hanging fruit.