Andres, > What worries me is that you're only counting the number of URLs. > Are we sure that all the filtered URLs were indeed variants of a > previously found one AND that we already had X variants in the list > and the filtered one was the X+1? Something else... which discovery > plugins are you enabling in your scan? If only webSpider, it worries > me to see that the plugin might not be filtering enough.
[discovery.webSpider] onlyForward = False followRegex = .* ignoreRegex = [discovery.allowedMethods] >> About proper place for filtering. Imho, there are 2 place (with option like >> 'filterFuzzableRequests') for it: >> >> 1. in core in mentioned place as calling w3afCore._filterFRequests() >> 2. in base discovery plugin as method like 'baseDiscoveryPlugin.addToResult' >> + calling from w3afCore someDiscoveryPlugin.getResult().The point is >> filtering should not be only in webSpider but in all discovery plugins >> depended of filterFuzzableRequests option and they should return to the core >> already filtered result. > > I would do it in w3afCore and let the plugins run without > restrictions for now. If you want to work on this and test it, please > go ahead :) The only requirement I have is that you test it > EXTENSIVELY and add the proper w3af test script and html files in > testEnv. Ok, I will do it in new separate branch. I think it is important because currently w3af makes a lot of job which takes a lot of time and resources. Good examples are: 1. audit same requests many times 2. send a lot of requests to detect e.g. xss We can really reduce scan time with saving good result. Currently I have 3 things that I really don't like in w3af: 1. a lot of exceptions (especially unicode ones). For a week I try to scan one web app without exceptions... 2. long time to scan typical web app 3. a lot of dependencies :) > Regards, > >> >> >> 15.02.2012 17:20, Andres Riancho пишет: >>> >>> Taras, >>> >>> On Wed, Feb 15, 2012 at 10:05 AM, Taras<ox...@oxdef.info> wrote: >>>> >>>> Hi, all! >>>> >>>> There is code in w3afCore._realStart() [0] to filter such requests as: >>>> - http://host.tld/?id=3739286 >>>> - http://host.tld/?id=3739285 >>>> >>>> The question is why this code is commented out in the trunk? >>> >>> >>> According to [0] it looks like it is an incomplete work on my >>> side. The webSpider plugin is doing some work on identifying variants >>> (which works well by the way) but that is not being done in the core. >>> I think it's not something we need to worry too much about at this >>> point, but that could change if you've found bugs and issues with it >>> :) Also, we should think twice before changing anything in the core, >>> it might break many things! >>> >>> [0] https://sourceforge.net/apps/trac/w3af/changeset/3388 >>> >>>> [0] >>>> >>>> http://w3af.svn.sourceforge.net/viewvc/w3af/trunk/core/controllers/w3afCore.py?view=markup >>>> >>>> -- >>>> Taras >>>> http://oxdef.info >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Virtualization& Cloud Management Using Capacity Planning >>>> >>>> Cloud computing makes use of virtualization - but cloud computing >>>> also focuses on allowing computing to be delivered as a service. >>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>> _______________________________________________ >>>> W3af-develop mailing list >>>> W3af-develop@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/w3af-develop >>> >>> >>> >>> >> >> >> -- >> Taras >> http://oxdef.info > > > -- Taras http://oxdef.info ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop