Taras,
I don't mind :) You're more than welcome to create branches :)
Regards,
On Fri, Dec 2, 2011 at 12:33 PM, Taras <ox...@oxdef.info> wrote:
> Andres,
>
> If you don't mind I begin to develop "rewritten URLs" [0] support with
> fuzzURLParts and urlRules options inside http-settings. I've made a branch
> for it [0].
>
> [0] http://en.wikipedia.org/wiki/Rewrite_engine
> [1] https://w3af.svn.sourceforge.net/svnroot/w3af/branches/rewritten-urls/
>
> 16.11.2011 19:33, Taras пишет:
>>
>> Andres,
>>
>>>> Andres, when I have suggested this feature in w3af I didn't mean
>>>> *full* REST
>>>> specification support.
>>>>
>>>> Today a lot of web applications (especially based on frameworks like
>>>> Django
>>>> or in the old way by Apache mod_rewrite module) uses REST-like URLs
>>>> e.g.:
>>>>
>>>> http://example.com/foo/bar/123
>>>>
>>>> In this URL we (not scanner) can see such parts as:
>>>>
>>>> * foo - controller name
>>>> * bar - action name
>>>> * 123 - parameter value
>>>>
>>>> From classic web spider point of view it looks like directory
>>>> hierarchy - it
>>>> is incorrect behavior! All these parts we need to fuzz!
>>>
>>> Agreed, so we don't want to support REST, we want to support
>>> mod_rewrite. Would that appreciation be correct?
>>
>> I wouldn't use term mod_rewrite as the name of the whole feature because
>> mod_rewrite is simply one of REST URLs cases. In modern web applications
>> which are based on frameworks like Django *internal URL processing*
>> becomes more and more popular. mod_rewrite is web server based URL
>> processing.
>>
>>>> What I suggest to implement is rules for such URLs. It can be done as
>>>> http-settings
>>>> file option called "url-rules" (name is not important):
>>>>
>>>> /top/users/%s/view/%d/
>>>> /controller/action/%d/
>>>> ...
>>>>
>>>> %s and %d are special tokens which can be used by w3af to determine fuzz
>>>> points.
>>>
>>> I like the idea, but I would do it in a more configurable way.
>>> Right now we have the "fuzzFileName" setting in w3af, which
>>> enabled/disables what I explained in the initial email. In the future
>>> I would like to see the following options:
>>>
>>> * fuzzFileName (default: False)
>>> * fuzzDirectories (default: False)
>>> * url-rules (default: no filename with rules)
>>>
>>> With this, when a user wants to fuzz all the "directories" in all
>>> URLs he just enables "fuzzDirectories" and "fuzzFileName". If he wants
>>> to have more control over which parts of the URL are actually fuzzed,
>>> he can disable the previous ones and set the url-rules himself.
>>
>> Hmmm, interesting idea. But let's call this option something like
>> fuzzURLParts. fuzzDirectories can be misunderstood by user.
>>
>>> For the rules file, what I recommend is that we support parsing of
>>> mod_rewrite and django rules (if possible) so that a developer can
>>> simply copy/paste those rules into a file and point w3af into it.
>>
>> Agree, plus Nginx config
>>
>>> In your example you put something like %s and %d. Do we care if
>>> it's a string or a digit? Should the scanner change it's behavior
>>> based on that?
>>
>> I think it is not so important on the first iteration. We can consider
>> all such tokens as strings.
>>
>>
>>>
>>> Regards,
>>>
>>>>
>>>>> This email is just a conversation starter for defining how we're
>>>>> going to deal with REST urls.
>>>>>
>>>>> REST, as described in [0], has two important moving parts:
>>>>> 1- URLs that "look nice" (no parameters: /people/1/phones/23 )
>>>>> 2- Heavy usage of HTTP methods like GET, POST, DELETE, PUT.
>>>>>
>>>>> The first question that I would ask myself is... do we want to
>>>>> support 1 and 2? Only 1? What is really needed by our users?
>>>>>
>>>>> If we only want to implement #1, it should be easy enough, since
>>>>> we already have something similar (see: mutantFileName.py). This
>>>>> mutant, together with the fuzzer.py (more specifically
>>>>> _createFileNameMutants) will behave like this:
>>>>>
>>>>> - Original URL: http://host.tld/foo/spam-eggs.jsp
>>>>> - Input strings: [ '<script>alert(1)</script>', 'ping localhost']
>>>>> - Output URLs:
>>>>> * http://host.tld/foo/<script>alert(1)</script>-eggs.jsp
>>>>> * http://host.tld/foo/spam-<script>alert(1)</script>.jsp
>>>>> * http://host.tld/foo/ping%20localhost-eggs.jsp
>>>>> * http://host.tld/foo/spam-ping%20localhost.jsp
>>>>>
>>>>> As you can see, it will split the filename using any character
>>>>> that's not a letter and put the strings into those positions. If we
>>>>> change this from just the filename into the whole path, it should work
>>>>> and inject into each URL section.
>>>>>
>>>>> Please note that the current implementation only performs file
>>>>> name fuzzing if misc-settings fuzzFileName is enabled (which is off by
>>>>> default). Should we also think about this and potentially modify this
>>>>> to true?
>>>>>
>>>>> Regarding #2 , I don't see a reason for it not to work with
>>>>> w3af... but I could be mistaken. We should perform some tests to check
>>>>> if w3af parses and correctly sends requests associated with forms that
>>>>> use PUT, DELETE, etc. The meta-question here is... do we want w3af to
>>>>> send requests that will "DELETE" stuff?
>>>>>
>>>>> Ok... that's enough for a conversation starter :) What do you guys
>>>>> think?
>>>>>
>>>>> [0] http://microformats.org/wiki/rest/urls
>>>>>
>>>>> Regards,
>>>>
>>>>
>>>> --
>>>> Taras
>>>> http://oxdef.info
>>>>
>>>
>>>
>>>
>>
>>
>
>
> --
> Taras
> http://oxdef.info
>
--
Andrés Riancho
Director of Web Security at Rapid7 LLC
Founder at Bonsai Information Security
Project Leader at w3af
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop
