timewasted / fuzzy-wuzzy Goto Github PK

It is currently possible to supply multiple fuzzers to a parameter, and each of them will operate independently of the other. It should be possible to have multiple fuzzers work in conjunction with each other as well.

For example, assume that a fuzzer named strings exists, which feeds a list of strings to a given parameter. Assume that a fuzzer named urlencode also exists, which URL encodes a value passed to a parameter. Being able to chain the two together to automatically URL encode the list of strings would be great.

It's easy to see how one fuzzer that generates a value can easily interact with another fuzzer that modifies the value. But what happens with multiple fuzzers that each generate a value? Assume two increment fuzzers, one starting at 0 and stopping at 3, 1 step at a time. Do the two concatenate the values, producing 00, 11, 22, and 33? What if the first one stops at 3, but the second one continues to 5? What is the output there?

What I'm 99% certain I want to do:

• Allow chaining an arbitrary number of fuzzers to produce a single output value.

What I'm not sure about:

• How will multiple "generator" fuzzers generally interact with each other? Are the values concatenated together? I'm leaning towards "yes".
• What if multiple fuzzers generate a different amount of values, such as the two increment fuzzers example above? The shorter fuzzer could either stop outputting values, reset and start over, send the last value, or something else? I'm currently leaning towards "stop outputting values", but what if you chain a value and increment fuzzer? It would make sense to have the value fuzzer run for the duration of the increment fuzzer so that you could generate, for example, value1, value2, etc.

An HTTP request fuzzer isn't too terribly useful if the responses to the generated requests are ignored. So, I need to figure out the most useful way to handle them.

What I'm 99% certain I want to do:

• Parse the request into useful bits. "Useful bits" includes at least the status code, content length, and response body. Possibly also parse out the headers as well?
• Store the request, as well as the response in an SQLite database. While a different data store may technically be a better option, SQLite is nearly universally available, and is a minor dependency when it's not available.

What I'm not sure about:

• Looking for something specific in the response. In the case of a reflected XSS, you'd be looking for a specific string in the response. I'm pretty sure that I want to do this, but I'm just not certain about the details.

There are probably more issues that I haven't yet thought of, but this is a good start.