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.
0 kommentar(er)
