Hi Philip Btw you can specify a ingoreRegex for the webSpider if you just want to ignore some URIs.
It would be great if you can open a ticket [0] if you really find a bug in the newest svn release that isn't yet in our trac system. [0] https://sourceforge.net/apps/trac/w3af/newticket cheers floyd ----- http://www.floyd.ch ----- Ursprüngliche Mail ---- Von: philip hartlieb <philip.hartl...@us.army.mil> An: Floyd Fuh <floyd_...@yahoo.de> CC: w3af-users@lists.sourceforge.net Gesendet: Donnerstag, den 4. November 2010, 14:07:31 Uhr Betreff: Re: [W3af-users] scoping a scan Hi Floyd, Thank you for the feedback! I think this answers my question. My approach is imperfect, but will not result in an epic fail with regard to results. That is, it *is* acceptable to feed the audit and/or grep plugins a list of fuzzable requests from a file rather than from a "runaway" discovery process. The ImportResults and "export fuzaable requests" feature will make life much easier. Thanks for the heads up. For the record, I have identified the URIs that blow my scan times up to 3+ days. Whether I fed it the URIs to audit.xss in small batches or allowed the discovery plugin to do it for me appears to have been irrelevant. The Drupal search components choke the tool for days. I need to find out why. Thanks again, VR -pjh On Nov 4, 2010, at 4:15 AM, Floyd Fuh wrote: > Hi Philip > > Looks like your page is huge (or as you said w3af doesn't stop crawling). > > Because you're running on Fedora, I assume you're using python 2.6 or 2.7. > W3af is *officially* only supported in python 2.5. But in my experience it > runs under 2.6 (but I guarantee for nothing). Never tried 2.7. > > In your situation I suggest you do the scan in two steps: > 1. discovery > 2. audit > > For phase 1 I suggest you update to at least revision 3656. From that > version the "export fuzzable requests" feature was fixed. Phase 1: > 1. enable some discovery plugins (try first with just webSpider), no other > plugins > 2. Go to Configuration - Misc > 3. Go to Core Settings and change the maxDiscoveryTime to your needs > 4. Go to Export Fuzzable Request and type in where you want to save the CSV > 5. Start w3af as usual > 6. Copy the CSV to somewhere else (to make sure it won't get overwritten in > phase 2) > 7. Remove duplicate URIs and add if some are missing > > For phase 2: > 1. enable only the importResults discover plugin and specify the path to the >CSV > 2. enable the audit/grep plugins you wish to run (btw you don't need the > frontpage plugin when > you test a Drupal installation...) > 3. run the scan > > Of course you can redo phase 2 with other plugins. > > About your questions: Of course it is always possible to miss vulnerabilities > (like xss). No > tool is perfect. If you really want to do a lot of XSS tests you might want > to > set numberOfChecks > to 15 inside the xss plugin. > > cheers > floyd > > ----- > http://www.floyd.ch > > > > ----- Ursprüngliche Mail ---- > Von: philip hartlieb <philip.hartl...@us.army.mil> > An: w3af-users@lists.sourceforge.net > Gesendet: Mittwoch, den 3. November 2010, 16:17:56 Uhr > Betreff: [W3af-users] scoping a scan > > Hello: > > I'm hoping to get some feedback on the following issue. > > Background > We are running the following: > - w3af revision 3623 > - w3af host: Fedora core <<2.6.33.3-85.fc13.i686.PAE>> > - target: custom drupal installation with end user data > > Objective: > - I would like to bring back data for the OWASP-top-10 discovery and audit > plugins > - discovery allowedMethods, content_negotiation, detectReverseProxy, > detectTransparentProxy, digitSum, dir_bruter, domain_dot, > favicon_identification, findBackdoor, fingerprint_os, hmap, phpEggs, phpinfo, > pykto, robotsReader, serverHeader, serverStatus, slash, urlFuzzer, > urllist_txt, > > webSpider, wordnet, wsdlFinder > - audit frontpage, eval, blindSqli, phishingVector, xsrf, mxInjection, > preg_replace, localFileInclude, LDAPi, osCommanding, ssi, sqli, buffOverflow, > xpath, generic, htaccessMethods, remoteFileInclude, responseSplitting, > formatString, globalRedirect, xst, xss, fileUpload > > > Approach: > - To begin scoping the scan, I decided to keep it very simple and run > **only** > the WebSpider and xss plugins. After 3+ days the scan had not completed. > This > > was not tenable. > - I then decided to run the owasp-top-10 discovery plugins only. This scan > completed overnight and delivered 23,000 lines of output in the text file. I > now had a data set to audit. > - There were 20022 URIs reported. <<For the purposes of this email, I'm >assuming > > a URI = https://this.is.our.site/go/to/this?name1=value1&name2=value2 > - However, I parsed through the output and discovered that there were only ~ >240 > > unique URIs **if** I ignore the differences in the parameter values. The > presence of end user data seems to have ballooned the discovery results. > - If I then batch these URIs into groups of ~ 25 and place them after the > "set > target" directive ***and** only run the xss audit plugin, I can get good >results > > in about 3 hours for all 240 targets. > > Questions: > - I know that w3af is designed to work recursively in that the discovery and > audit plugins work back and forth to discover new injection points and find > additional URIs/URLs. Is is possible that I am missing true xss >vulnerabilities > > by using the approach above? > - I noticed that the XSS plugin **will** discover the allowed methods and > parameters for each URL you feed it. If that's the case, then it would seem > that this is a legitimate way to scope the scan and save time as the xss > plugin > > will be fuzzing all of the possible injection points? > > thoughts? > > > ---- > Philip J. Hartlieb (PhD.) > GSLC / Security+ > Systems Engineer > > "They would take their software out and race it in the black desert of the > electronic night." -- Snow Crash > > > > > ------------------------------------------------------------------------------ > Achieve Improved Network Security with IP and DNS Reputation. > Defend against bad network traffic, including botnets, malware, > phishing sites, and compromised hosts - saving your company time, > money, and embarrassment. Learn More! > http://p.sf.net/sfu/hpdev2dev-nov > _______________________________________________ > W3af-users mailing list > W3af-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/w3af-users > > > ---- Philip J. Hartlieb (PhD.) GSLC / Security+ Systems Engineer Space and Naval Warfare (SPAWAR) Systems Center - Atlantic "They would take their software out and race it in the black desert of the electronic night." -- Snow Crash ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ W3af-users mailing list W3af-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-users ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ W3af-users mailing list W3af-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-users
