Project name

[amuntner]

Adam,

Thanks for being interested in fuzzdb! The project is now located at https://github.com/fuzzdb-project/fuzzdb

It was never abandoned - the most recent updates to content were in July and the project page had been updated to indicate it would be moving to github soon.

You're welcome to continue your fork (though I'd prefer you'd call it something else to avoid confusion, especially since my name is also Adam). And/or you're also welcome to contribute to the fuzzdb repo! It would be easier than us copying files back and forth. I'm preparing some changes and will be doing some stuff to automate keeping what gets included with OWASP ZAP up to date.

[adamdecaf]

@amuntner Sounds good! I actually took the code as a chance to further improve my skills on how to prevent all sorts of exploits (often from fuzzy data) so the current state of it is a bit further away from the original fuzzdb. I'll look into forking from your github repo now!

[amuntner]

It's useful for all kinds of stuff. Trying to infer what code would be vulnerable to the attack patterns is a really good exercise. Right now it's still the way it was in google code but i have some time blocked off for it today so it should be changing a bit soon.

I was looking at

https://github.com/adamdecaf/fuzzdb/blob/master/resources/json_fuzz.txt

but I'm not sure how useful it would be in practice? Different lines are in different contexts, some being wrapped with {} others being arrays [], and others looking like they are supposed to be field names/values, some quoted, some unquoted, and each of those containing potentially malicious input, but the input itself presuming some kind of json format or injection point.

So if I'm understanding what you're trying to do and not missing something, the way I do this is to look at the json and pick the points to fuzz specifically, sometimes in more than one pass: first select what I want to run generic scanning against. Then set up specific tests depending on the names, values, functionality, etc. For example, maybe I want to try the list of common method names submitted as values for field name "action" or try command injection or directory traversal attacks against some file name field, or xss encoded in some necessarily weird way into some format-structured part of the value part of a name/value pair. And then try some manual tests like for parsing related issues: extra arrays, nesting stuff weirdly, etc.

[adamdecaf]

@amuntner Yea so that originally came from https://github.com/adamdecaf/vulnerabilities/issues/127, but I think it's useful as some things to plug into a json parser. You could take a line like eval("while(1);") or {"valueOf":"while(1);"} and run them through to make sure the parser isn't trying to evaluate the json blob.

However it looks like all of those lines are valid json according to the BNF diagram on the home page for json. So any parser should be able to handle those without blowing up. Wouldn't you want to see if a system breaks if you send it [...] instead of {...}?

[adamdecaf]

I'm excited to see what all you have in store upcoming for fuzzdb and I'm glad it's not abandoned! I did go ahead and set my own fork as well to contribute back to your repo.

[amuntner]

I thought it looked familiar :)

What I mean is that some are at the Object level, some are members, some are pairs, some are arrays, etc. The different test cases in the file being from different parts of the json structure couldn't all get fuzzed into the same place in a request.

For example If the parser is expecting a complex structure and you send it a single name/value pair with the value having a null byte, it won't help find a bug where the null byte has to be base 64 encoded inside some nested array member and after some piece of information that was gleaned from the previous server response. It would have to do something with the data it receives. If you select a whole json object to fuzz then the records that are wrapped in [] amd the ones wrapped in "" etc won't parse correctly.

[adamdecaf]

Oh yeah. Right now that file isn't very good. I'm going to spend some time this weekend trying to clean up those files. On Sep 11, 2015 11:15 AM, "Adam Muntner" notifications@github.com wrote:

I thought it looked familiar :)

What I mean is that some are at the Object level, some are members, some are pairs, some are arrays, etc. The different test cases in the file being from different parts of the json structure couldn't all get fuzzed into the same place in a request.

For example If the parser is expecting a complex structure and you send it a single name/value pair with the value having a null byte, it won't help find a bug where the null byte has to be base 64 encoded inside some nested array member and after some piece of information that was gleaned from the previous server response. It would have to do something with the data it receives. If you select a whole json object to fuzz then the records that are wrapped in [] amd the ones wrapped in "" etc won't parse correctly.

— Reply to this email directly or view it on GitHub https://github.com/adamdecaf/vulnerabilities/issues/137#issuecomment-139589065 .