[fuzzing] OWASP Fuzzing page

[Florent THIERY]

Salut :)

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
> work/researches)


... 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
http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectorsand
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/

Florent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.whitestar.linuxbox.org/pipermail/fuzzing/attachments/20061213/ca7bf258/attachment.htm