|
CurrentResults
Current coverage results of scanners agains wivet
Featured Let me know other scanner coverages/improvements/errors: bedirhanurgun {at} gmail ... 1. w3af %50 http://w3af.sourceforge.net/videos/w3af-vs-wivet/w3af-vs-wivet.htm 2. acunetix %94 http://www.acunetix.com/support/build-history.htm 3. cenzic hailstorm %88 http://www.webguvenligi.org/wivet/offscanpages/statistics.php?id=1238178551 4. hp webinspect %94 http://www.webguvenligi.org/wivet/offscanpages/statistics.php?id=1238767398 5. ibm appscan %83 localtests 6. netsparker %92 localtests |
► Sign in to add a comment
55% for secfail (without javascript/flash engine) :) release soon
Netsparker CE v1.3.7.5 - 78%
NTOSpider %96 localtests.
The two that are missed are:
#6_14b3c - form submit thru select onchange w/ simple alert
#19_2e3a2 - link attached to a swf simple button parameterized onclick event
----
For 6_14b3c NTOSpider is cycling through select list but appears to have issues detecting the changes to the iframe src that take place.
For 19_2e3a2 it appears that this is being generated by actionscript in the swf file which is not supported at this point.
Testing my personal web crawler on WIVET, and its treating every request like a different crawl. I noticed the phpsessid gets sent back on every request (even though i am sending it), so I modded my crawler to ignore changed set-cookies just to test if this was the issue. Even with my crawler sending the same phpsess, WIVET is still treating every request like a separate crawl. Also, Its saying I did not hit pages that I did in fact hit, I have the content-hash to prove it. What is going on here?
Our web server runs in a chroot env. That might be a reason. ı'll chek the log files but in the mean time i suggest you to check svn repsitory and run your own wivet.
Sorry, I forgot to mention I was already running WIVET locally
Yes, it's always a good idea to checkout from svn. I tried a fresh checkout and run wivet on a fresh wamp server, didn't see any problem (it's tracking the session). 1. Can you make sure that, with a browser you can follow some links and collect some "current run" statistics? 2. Can you also make sure that your crawler uses the same cookie wivet (php) sends initially with a personal proxy (webscarab, burp, ...) or browser plugins (firefox; firebug, http live headers OR internet explorer; fiddler)?
I was finally able to get all my eggs in one basket. I was downcasing the set-cookie fields, so when I sent back phpsessid instead of PHPSESSID, wivet was ignoring it. The reason I was downcasing set-cookie fields is to avoid making requests with the same cookie names other than the casing. How do browsers handle sites that set the same cookie fields with different letter casings?
Also, current run is always empty, I have to go into statistics to bring up the results, how does WIVET determine there is no current run?
that's good news. current run brings the results according to the current session. So your crawler and you (when browsing the web app) should use the same PHPSESSID.