[OWASP-WEBSCARAB] Fuzzer

[Rogan Dawes]

Daniel Cuthbert wrote:

> (now lets get that fuzzer working :p )
> 

Here are my thoughts about the fuzzer:

In a generic way, we can consider any HTTP request to be roughly 
equivalent to a Java (or other preferred language) method call, with 
some (maybe none) parameters.

This is kind of like a WebService, but with very poorly defined 
semantics, parameter types and return types.

In general, I can think of the following things that distinguish a 
"method signature":

METHOD (GET, POST)
URL (base URL, in case there are PATH parameters /app.jsp/p1/p2/p3 )
PATH Parameters (see above for example)
FRAGMENT (app.php;phpsessionid=12345)
URL Parameters (?a=1&b=2)
Authentication (Basic, Digest, NTLM, Negotiate)
Cookies
Content-Type+Content (closely related to each other, so one category)

Depending on the amount of "insight" we have into the way the system 
works, we may be able to define some of these parameters in a more 
detailed way, e.g. type (String, Number, Date, Filename, etc)

We can get this information about a system in a couple of ways:

* By analysing the conversations that we see (via the different 
WebScarab plugins, e.g. Proxy, Manual Request, Spider, etc)

* By analysing WSDL for various exported WebServices.

* Maybe other ways. ;-)

Obviously, if we consider that a Cookie can be a parameter, things like 
images, javascript, css, etc, could be mistaken for an interesting "method".

Of course, we are primarily interested in responses that change. If we 
cannot influence what we get sent, it is not interesting to us. One way 
to filter constant content is to submit a "void" request. i.e. something 
without any parameters at all. If we get back the same content as we do 
for a parameterized request, we can consider the "method" to be a constant.

So, if we have a GET request for http://ww.example.org/1x1.gif, and 
there is a cookie of JSESSIONID that accompanies it, we might send a 
request without the cookie to see if the response changes in any way.

If the response content is the same as for a previous request WITH a 
parameter, we can assume that it is constant.

Alternatively, we can simply exclude certain resources by means of a 
regular expression applied to the url (\.{gif|jpg|css|js}$) or to the 
response Content-Type.

Ultimately what we will have is a list of method signatures, varying 
according to the list of parameters that we have seen.

Now, we want to see how each method (identified by its signature) 
behaves under attack.

For each signature, we want to be able to vary the value that is 
submitted for various parameters. We also want to be able to control 
which parameters are fuzzed, and the source of the fuzz data.

We also want to be able to control the way that the parameters are 
fuzzed. Do we simply set each parameter to have the same fuzz string? Or 
do we want to step through the fuzz strings in a per-parameters manner?

So, we have a list of parameters, comprising

LOCATION
NAME (optional, could be null)
TYPE

We want to control:

Default value
Whether we fuzz it at all
Source of Fuzz data (if any)
Precendence (order in which we increment the fuzz string)

If we fuzz all the parameters together in lockstep (i.e. change them all 
at the same time), the various fuzz sources need to have the same number 
of fuzz strings. Alternatively, if we specify a precedence, any fuzz 
sources at the same precendence must have the same number of fuzz strings.

The idea of the precedence works as follows:

Say we have the following fuzz strings "x", "y", "z", and the following 
parameters (P=precedence, D=default value)

A (P=1, D="a"), B (P=2, D="b") and C (P=3, D="c")

Then our fuzzer would submit

A=a&B=b&C=c
A=x&B=b&C=c
A=y&B=b&C=c
A=z&B=b&C=c

A=a&B=x&C=c
A=x&B=x&C=c
A=y&B=x&C=c
A=z&B=x&C=c

A=a&B=y&C=c
A=x&B=y&C=c
A=y&B=y&C=c
A=z&B=y&C=c

A=a&B=z&C=c
A=x&B=z&C=c
A=y&B=z&C=c
A=z&B=z&C=c

A=a&B=b&C=x
A=x&B=b&C=x
A=y&B=b&C=x
A=z&B=b&C=x

etc until we have been through all the permutations

However, if we have parameters A (P=1, D="a") and B (P=1, D="b"), and 
set the fuzz strings for A to "P", "Q", "R", and for B to "S", "T", "U", 
we would submit:

A=a&B=b
A=P&B=S
A=Q&B=T
A=R&B=U

and it would stop there.

Finally, in order to deal with various content types, we would allow a 
Content-Type-specific "formatter" to put the parameters into a 
type-dependent format. This approach allows us to cater for normal 
forms, multipart forms, SOAP messages, etc.

An initial implementation would probably submit all the conversations to 
the framework for processing and audit trail keeping. Later, we might 
decide to filter the responses for "interesting" strings, such as 
exceptions, SQL (or other) error messages, etc. Finally, we might want 
to be able to pause/stop the fuzzing under certain circumstances (e.g. 
we recognise an already-logged in session) and resume from where we left 
off.

This basically forms a generalised "brute-force" plugin that we can use 
to brute force login forms, existence of files and directories, etc.

So, at the end of this really LONG mail, this is what I'm planning to 
try to implement (when I have time).

Comments? Suggestions? Does anyone think that I am missing something? 
Going about this the wrong way?

Rogan