[fuzzing] OWASP Fuzzing page
fthiery at gmail.com
Wed Dec 13 04:13:19 CST 2006
On 12/13/06, Jerome Athias <jerome.athias at free.fr> wrote:
> Salut Florent,
> could you let me know first what is the main goal of your page(s)? (it
> will help people here to give you feedbacks or guidelines)
> is it to give just an overview of fuzzing? (if so well it does)
That was the point indeed
is it intended to be exhaustive? (if so well it still needs a lot of
... I may extend it, but i don't really know where to start regarding
protocol fuzzing; it would be nice to list all the fuzzer forms (proxy-like,
static-list, ...) but i only have a little experience in file format
fuzzing. Any help of categorizing would be appreciated (one needs to have a
good overall overview to do this, IMHO).
what i think could be interesting, thinking only about:
> 1) protocols (implementation) fuzzing : is to try to correlate the
> various approaches, by example, you will have a fuzzer (ie: FtpFuzz)
> that will use a list of commands and a list of queries (fuzzing vectors,
> ie: long strings and format specificators), will it allways be updated
> (available list of commands/exhaustivity)? will the list of commands
> will be static or dynamic (ie: retrieving the list of available commands
> for a specified service with the HELP command)?, will it be
> exhaustive/standardized/reusable?, will the parameters will allways be
> correct/reliable? ...
> another fuzzer (ie: taof) will first acts as a proxy to collect the
> (some) commands and the parameters, it's for me a different approach
> a bench between various fuzzers could be nice (speed/reliability/easy to
> modify-extend ...)
> a list/reference of commands for "each" protocols could be interesting
There's a fuzzing vectors list already, available here
linked in the article. Feel free to enrich it. For now, there are fuzz
vector generation methodology guidelines, and XSS, BFO, FSE, int, SQL,
LDAP, Xpath and XML samples.
(ie: check in BackTrack)
> 2) file fuzzing: for me, there are less public filefuzzing tools than
> protocols ones
> let think about why? (more formats/softs, less standardization, closed
> sources/specifications...? and in another corner maybe harder to
> identify/exploit a vuln - it will extend the discussion to live
> debugging/deadlisting methods/tools...)
... Plus maybe because a file format tool is either "dead-simple" (and
generic), or totally file-format-adapted, -> complicated. Ever looked into
AAC format? That's a horrible thing to look at. I guess the main problem is
that's there only was little effort into developing a generic file parser.
Which is changing: http://hachoir.org provides a generic parsing interface
(python), and i'm pretty sure it will change the face of file format fuzzing
:) I'm gonna go into it sooner or later.
> So finally, maybe you should try to extend the discussion corner or the
> technical corner...
I guess the main article is supposed to keep "general". But nothing prevents
me (us?) from adding specialized articles. The thing is, i don't know enough
yet to do this; have ideas but they are not mature enough.
Thanks for the answear, compatriote \o/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fuzzing