---------[ Whisker: next-generation CGI scanner
								
Wait...CGI scanning isn't that complex, is it?  Well, to do it right,
yes.  Why?  Hmmm...I can think of a few reasons:

1.  /cgi-bin is pretty damn common, I'll give you that.  But I've also
been on many a hosting provider that used /cgi-local.  And I've seen
people use /cgi, /cgibin, etc.

Point of the point: wouldn't it be nice to define multiple
directories?

2.  You know what really irks me?  Seeing a CGI scanner thrash around
through /cgi-bin or whatnot, when /cgi-bin doesn't even exist.

Point of the point: save noise/time by querying parent dirs

3.  Why should I query for, say, test-cgi on an IIS server? Or
/scripts/samples/details.idc on Apache?

Point of the point: tailor your scan to the server you're scanning

4.  Virtual hosts.

Point of the point: there's a whole 'nother world out there hiding
behind virtual hosts--and you may not be scanning who you think you
really are

5.  Some places user custom error pages.  Unfortunately, the
implementation is such that instead of generating a 404 'not found',
you always get a 200 'success', with HTML to indicate the missing
page.

Point of the point: being able to minimize this anomaly would lessen
false positives

6.  More wishes: at a decent rate, it seems more CGI and webserver
problems are found.  Plus, I might like to customize which scans I
want to do against a particular host.

Point of the point: if this was all scriptable, that'd be nifty

7.  Input sources.  Sometimes I want to just feed in output from nmap
(after all, it has a list of the found open port 80's, right?),
sometimes just a laundry list of IPs/domains, and sometimes, I'd just
like to do a single host on the command line.

Point of the point: flexibility of input would be nice as well.

8.  IDS/log avoidance.

Point of the point: being able to spoof IDSs would be a nice feature

Well, that's enough wishes, don't you think?  Now, do they come
true....