Andres,
- Regarding the discovery method, actually a REST API es pretty unique,
maybe sending the "Accept apliccation/json" header and check for a positive
answer is a good place to start. Well coded APIs accept the OPTIONS method
to describe their behavior and their resources, vital info could be grabbed
from there. When an authenticated schema is implemented is not that easy.
Resources are very particular for each API, mapping them is not
easy.asnavigating a directory schema on a webserver, usage of that
resources are
very special in each case, you can face things like "curl -X GET
http://api.servercloud.com/servers"; and "curl -X GET
http://api.othercloud.com/?servers=* , of course someone is violating REST
standards but i see this all the time. But we have to face that now
everything is presented "as a service" to be consumed via an API . So i
think this is a very nice to have feature on w3af
Regards
Lean
On Tue, Nov 15, 2011 at 8:33 AM, Andres Riancho <andres.rian...@gmail.com>wrote:
> List,
>
> 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,
> --
> Andrés Riancho
> Director of Web Security at Rapid7 LLC
> Founder at Bonsai Information Security
> Project Leader at w3af
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> W3af-develop mailing list
> W3af-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/w3af-develop
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop
