Hey Floyd,

Yes. I've used it. Works like a charm ;)

Depending on what I find,  I will open a report and share with the community.

My past experience has made me a little reluctant as the problem has often been 
with my specific config and not the tool itself.

Thanks,

-pjh

On Nov 5, 2010, at 3:56 AM, Floyd Fuh wrote:

> 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 <[email protected]>
> An: Floyd Fuh <[email protected]>
> CC: [email protected]
> 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 <[email protected]>
>> An: [email protected]
>> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/w3af-users

Reply via email to