Worst part is they may be technically right

@buherator heh, thats how it started...

@mumblegrepper Is it though? I remember that "pipe /dev/random to unix tools" paper as the original sin (which is random + open ended)?

@buherator for me testsuites such as protos and known mischievous inputs were always a part of that toolset. The fuzzer i published in 2002 tested a set of strings first that were more likely to generate issues before going random. Which IMO made sense without a coverage feedback loop.

@mumblegrepper *tucks sleeve* fine, let's do some taxonomy!

I don't think feedback is relevant, the first fuzzers didn't use that.

I see two techniques often mixed up with "classical" fuzzing:

1) Trying identifiers, e.g. IDOR, URL paths, subdomains, etc. My argument here is since our inputs never trigger "new control-flows" this is not fuzzing. (It's tricky how we define control-flow in this case, but I think you get the point).

2) Vuln scanning with magic strings. Now you are right to point out that magic strings are definitely part of fuzzing (e.g. 0, -1, INT_MAX), and this is where the lines get blurry. My current working definition here is that fuzzing starts somewhere when you are physically limited in trying all reasonable inputs (note that no real filesystem will require a trillion ../'s to detect a path traversal) and systematic algorithms (e.g. adding one more backslash) aren't effective, so you might as well start gambling.

WDYT?

@buherator I would call the first example enummeration or brute forcing. But I guess in my mind fuzzing is still mostly associated with memory corruption bugs.

I think a key point for me with fuzzing or automated dynamic testing was always the reproducibility. That's maybe why I never liked isic that much. When input is random you need another feedback loop to catch the crash and log the associated seed to be able to properly analyze.

Maybe all definitions for fuzzing have to be fuzzy ;-)

@mumblegrepper Just to be clear by "feedback" I meant "coverage feedback", reflecting on your post. You'll definitely need something to catch unexpected behavior and correlate it with your inputs but that's true for simple enumeration too.

100% agree on fuzzy definitions :)