Are the WebInspect developers naughty..naughty boys?

comments5 comments    userZapotek

August 7th, 2010 

UPDATE
I run the most recent trial version of WebInspect again its test site and I noticed an option specifically related to it.
The option was to login to the site with certain credentials.
It was separated from the “Web Form Editor”, which holds values to be automatically passed to forms during the crawl, so I hadn’t noticed it at first.

This led me to believe that WebInspect used hard-coded values to gain access to vulnerable pages that other scanners couldn’t.
After checking again I noticed that this specific option was enabled by default.

I guess there was something similar going on with the older versions as well that’s why WebInspect did a lot better on its test site than the other 2 scanners.

——————————–

This story begins like so:
I just implemented the expert-system/trainer for Arachni and like any other time that I make changes I tested it against the test sites of the big boys.

As I’ve said before my usual baseline is the Anantasec report: http://anantasec.blogspot.com/2009/01/web-vulnerability-scanners-comparison.html

Do me a favor and download the PDf file. Now scroll to page 23.
Doesn’t something look suspicious?
Like how WebInspect completely annihilates the competition?
These are the 2 URLs where WebInspect kicks ass:

The first one has a couple of curveballs, the form is not closed properly and the submit button is actually using JS.
Analyzing the broken form is kiddy stuff and you don’t even need JS to post it since you have the form action and method.

The second one looks like it should be an “action” attribute to some form nowhere to be found.

Thing is, the other scanner couldn’t find the vulnerabilities because there’s no path that leads to these pages from the web app’s index.
Arachni’s spider couldn’t find it, I couldn’t find it manually and the other scanners missed them too.

So I thought I’d get a trial version of WebInspect and see for myself and that’s when I noticed that the trial version only allows you to run WebInspect against its own test site.

Could it be that WebInspect has these hidden pages hard-coded to look good?
Image the following scenario:
You’ve got your hands on an number of trial versions of web scanners.
The other scanners impose some restrictions but allow you to run them against any site.
WebInspect only allows you to test it against its own test site.
So you end up running all of them against WebIspect’s test site to have the same baseline.
And WebInspect scores amazingly high while the others crash and burn.

Of course, some of my assumptions may be wrong.
Anantasec’s report may be outdated and the test site may have changed since then, the scanners may have changed etc etc…
And if that is that case I do apologize, however you’ve got to admit that this whole thing looks kind of sketchy.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon

Posted in: Security, Web Application

Tags: , , , , , , ,



5 Comments

rssComments RSS transmitTrackBack Identifier URI


I had the same question about some of these items when I looked at the report. I won’t speak to all of the issues, but it turns out that the pformresults.asp is legitimate. Ironically, this puts me in the strange position of defending the competition. :-)

In the course of the scan, they find:

http://zero.webappsecurity.com/login.asp
http://zero.webappsecurity.com/pindex.asp

By means of forceful browsing, they uncover:

http://zero.webappsecurity.com/login.asp.bak
http://zero.webappsecurity.com/pindex.asp.bak

Parsing through these backup files, you can see the link to pformresults.

Hopefully that clears up one of the issues.
Danny

Comment by Danny on 09/08/2010 16:15


Cheers for the explanation Danny.
Analyzing the backup files was smart, I’ll fire up the trail version again and see if I find an explanation for the “form.asp” page.

Comment by Zapotek on 09/08/2010 18:51


Did you mean join.asp? I believe this was found by sending a forceful browsing request to:

http://zero.webappsecurity.com/login.asp

You can see the link to join.asp in the source. Again, this would be a legitimate test and finding.

Comment by Danny on 09/08/2010 21:21


Yeah, sorry, I meant “join.asp”.
I could swear that the trial version didn’t find those files– or it didn’t update the site structure window on the left.

I had only configured WebInspect to crawl but I don’t think that that’s the problem since I saw the forceful browsing requests happen during the crawl from Wireshark.

I’ll fire it up again and do a full scan this time to see if they appear.
In any case, thanks for solving the mystery Danny. :)

And since you’re so kind as to shed light on this situation I have another, unrelated, question for you.

Let’s say that there’s a vulnerable GET var like:
http://zero.webappsecurity.com/banklogin.asp?err=Invalid%20Login:%20%3Cstrong%3EI%20am%20vulnerable%20to%20XSS%3C/strong%3E

In this case you have to submit the form and follow the redirection for the “err” var to appear.

If after submitting the form, another form dynamically appears, and then another one after that, etc etc, and after the final form a vulnerable GET variable appears (like in the scenario above), would WebInspect realize that the page is changing dynamically and follow the new forms as they appear?

I tested Acunetix and, surprisingly, it doesn’t.
Btw, I’ve setup a test page in PHP for Arachni… I can send it to you if want.

Comment by Zapotek on 10/08/2010 08:38


I don’t know enough about the way that WebInspect works to answer this question. Sorry. My assumption is that in general it would depend upon whether each of these forms was considered unique. Web app scanning is always a trade-off between time and accuracy. If the form appeared to be the same (i.e. submission URI, method, form elements, etc) it would not submit again, but if it appeared to be unique, it would continue submitting till it hit the scan configuration limit. Again … assumption.

The challenge … It is “difficult” (impossible?) for a scanner to know that on the first 10 form submissions the error would not appear, but it would show up on the 11th time without have some application source knowledge. Ironically, it would be simple to make this happen through app coding. In fact, in the case of a login form, this might even be a plausible scenario in the real world. Maybe on the 11th failed login attempt, it says, “Hey, do you know we’re tracking you …” with related information displayed such as the agent string. Pop some javascript into the user-agent and you have XSS – but only on the Nth attempt.

Comment by Danny on 12/08/2010 17:28

addLeave a comment