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 ^^
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 :
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 ^^
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 ;)
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 ?
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) ?
(excuse me for my poor english, french people speaking ^^)
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
