Laurent,
Please read comments inline,
On Tue, Jan 3, 2012 at 7:51 AM, <laurent.gu...@algosecure.fr> wrote:
> Hi,
>
> I'm a new w3af user (using and testing it for 1 month) and I'd like to
> congratulate you for the work you already achieved :
> * different phases (discovery, audit, exploit...) separated (clever)
> * a plugin system
> * possibility to use profiles and scripts
> * spiderman !
> * written in python ^^
:P
> When scanning a sample RESTful application vulnerable to XSS, I noticed that
> w3af (svn) does not handle nor find vulnerabilities (XSS, SQLi) on RESTful
> URLs.
> So I started to look at the code to see how could this be achieved (discovery
> phase, audit phase...), but when looking at the mailing I saw that you were
> already working on it ;)
>
> Your idea to use fuzzing on url parts to do some "brute force" is very
> clever, but I spotted a little problem inside this "URL parts fuzzing" code
> (svn) that make it fail in my tests : it always return double-encoded
> mutants, that make :
> 1. the detection of allowed special chars in XSS audit plugin fail (receive
> single-encoded special chars instead of non-encoded special chars), causing
> reflected XSS detection be aborted
> 2. the detection of reflected/stored XSS fail because payload that is
> returned in result page is single-encoded and can't be executed by the browser
>
> I made a quick and dirty patch that make the _createUrlPartsMutants() method
> (fuzzer.py) return 2 versions of each mutant : one single-encoded, and one
> double-encoded :
That's smart, I like the idea, not all web applications handle
URLs the same.
> core/data/fuzzer/fuzzer.py
> 549c549
> < m.setDoubleEncoding(True)
> ---
>> m.setDoubleEncoding(False)
> 550a551,562
>>
>> # Same URLs but with different types of encoding!
>> m2 = m.copy()
>> m3 = m.copy()
>> # for mod_rewrite
>> m2.setSafeEncodeChars('/')
>> if m2.getURL() != m.getURL():
>> res.append(m2)
>> # double encoding
>> m3.setDoubleEncoding(True)
>> res.append(m3)
>
> This patch made the URL parts fuzzing code work fine for me, and now w3af
> detect XSS vulnerabilities on my RESTful webapp ^^
And it will also work for so many other web applications.
After applying the patch (manually) this is what I get:
"""
m.setDoubleEncoding(False)
# Same URLs but with different types of encoding!
m2 = m.copy()
m3 = m.copy()
# for mod_rewrite
m2.setSafeEncodeChars('/')
if m2.getURL() != m.getURL():
res.append(m2)
# double encoding
m3.setDoubleEncoding(True)
res.append(m3)
res.append(m)
"""
Which is a bit confusing for me:
* if m2.getURL() != m.getURL(): Why do we need this?
* res.append(m) , do we really need that?
If you work on this patch a little bit and make some changes,
please send the ".patch" file in the next email so that I can "patch
-p0 < laurent.patch" and apply it automagically.
> That patch makes also w3af detect now 62% of sample XSS vulnerabilities on
> the wavsep 1.3 vulnrerable framework (http://code.google.com/p/wavsep/),
> instead of initially 27% before (remark : all the other vulnerabilities could
> be detected
> by adding more XSS injection patterns in w3af ;)
Interesting, which XSS injection patterns?
> I don't yet understand the whole application, but I wonder if management of
> single and double-encoding could be done in another way, to make it more
> generic for all mutant generation methods and for all audit plugins : perhaps
> not by
> returning 2 versions of each mutant URL, but by returning only 1 mutant URL
> for each test, and test it firstly single-encoded then double-encoded if
> single-encoded fails ?
Are you only talking about XSS here or all web vulnerabilities?
Any way, in most cases (99,9%) when w3af sends something to the remote
web application it does NOT get what it expects (an error). So the
idea of sending first single-encoded and then double-encoded if the
first test fails is almost the same as sending both; because you won't
be sending less requests (except from the case where the vulnerability
was actually found).
> Another thing : when using URL parts fuzzing code to detect vulnerabilities
> in RESTful URLs, w3af returns several identical vulnerabilities for the same
> "true" URL (what is logic, each fuzzed URL that works report 1 separate
> vulnerability
> because it's a completely different URL). I didn't looked at it at the
> moment, but I think it could perhaps be interresting to do some aggregation
> of found vulnerabilities to make w3af return only 1 vulnerability for each
> "true" URL, specifying all
> variations that have worked (fuzzed URLs) ?
That's a good idea. We're doing that in the _has_no_bug() method,
but it doesn't work with fuzzed URLs because that method compares the
URL to avoid reporting two very similar vulnerabilities. Maybe that
function requires a little bit of attention to help us in this case!
> (excuse me for my poor english, french people speaking ^^)
Actually, your English was pretty good !
Thanks for your very interesting comments :)
> Regards,
>
> Laurent
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> W3af-develop mailing list
> W3af-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/w3af-develop
--
Andrés Riancho
Director of Web Security at Rapid7 LLC
Founder at Bonsai Information Security
Project Leader at w3af
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop
