- Description
- Who is this fuzzer for
- What this fuzzer is not
- Requirements
- Building and Running in Docker
- Tests
- CLI Interface
- Restrictions
POST JSON Fuzzer is a lightweight WEB tool that can fuzz POST requests. It tries to find as many unexpected responses from the service as possible.
POST JSON Fuzzer makes API check for bugs, and you can define test scripts yourself in a clear and concise way, using a small Fuzzy objects which could be embedded directly into the JSON body of the request. Each test suite will thus be concise and declarative. It will be obvious which parameters are being tested, and how. I can write your own data generators, mutators, datasets - it won't be hard!
Minimal example that reflects the essence:
If you want to fuzz this small json
{
"id": 31,
"price": 109.95,
"uuid": "0926db52-bd5a-40c3-b333-07fd5e55a515",
}where uuid should always be unique, then you need to create a .deck file with the following content
(called fuzzing profile)
(Here we will fuzz "id" and it's value and "price" value, not key "price" itself.
At the same time, the uuid will be generated automatically each time):
{
Fuzzy(
default_value="id",
data_set=("client_id", "id_"),
suspicious_responses=[403, 200],
test_methods=tm.TAKE_CURR_AND_OTHERS_BY_DEF | tm.MISS_IT,
enabled=True,
description="This is an ID of a special object, it is forbidden to send together with client_id and id_",
): Fuzzy(
default_value=31,
data_set=(
-1, 0, 1, 1000, 100000, 100001,
*data_sets['default'],
*add_from_file('ext/fuzzbundles/numeric.txt'),
),
suspicious_responses=[403, 200],
test_methods=tm.PAIR_WISE | tm.MISS_IT,
),
"price": Fuzzy(
default_value=109.95,
data_set=(
-1, 0, 1, 1000, 100000, 100001,
*data_sets['default'],
*add_from_file('ext/fuzzbundles/numeric.txt'),
),
suspicious_responses=[403, 200],
test_methods=tm.PAIR_WISE | tm.MISS_IT,
enabled=True,
),
"uuid": Fuzzy(
default_value=None,
suspicious_responses=[],
data_set=(
Repeater(get_new_uuid),
),
test_methods=tm.GENERATE_IT,
enabled=True,
),
}Pass this file to the program, specifying the path to it in the console, and run Post-fuzzer.
It will create all json bodies for you according to the fuzzing profile specified in the *.desk file and send them
(synchronously or asynchronously, as you wish) to the service under test.
Understanding Parameters:
- default_value - this is the value that will be substituted into each json if this parameter has a default value during fuzzing process.
- data_set (tuple) - set of elements for fuzzing this parameter.
You can (and almost always should) unpack sheets via *.
Example: *data_sets['default'] - test_method - this parameter determines how this fuzzy will participate in the formation of a set of json bodies. If "pair_wise" is set for it, then each value of this fuzzy will participate in pair-wise combinations along with other fuzzies that have the same value of this parameter. And if the parameter has a value of "take_curr_and_others_by_def", then it will participate in fuzzing separately, and all other fuzzies will take on the default value.
- suspicious_responses - a list of response options from the server that look suspicious with the given data_set. For example, if instead of an id that changes from 1 to 100, we set 150 and received a response of 200 OK, the response will be considered suspicious.
- enabled - you may enable or disable any Fuzzy you want. If False, then it will not participate in the fuzzing process, instead it will have a default value in its place in each json document. Default value is True
- description - a line comment in case you want to leave it. Doesn't affect anything other than a general understanding of the fuzzing profile.
Feel free to ask questions if something seems unclear.
POST JSON Fuzzer is suitable in everyday work:
- for a developer who needs API checks for the slightest changes in the code (for example, 2K checks in ~ 2 minutes). Unit tests have already been written, but additional system or integration testing is needed
- for a QA engineer or a test engineer to automate those API checks that are done by hand. At the same time, solutions like Postman or Burp Suite are not suitable, or they don’t like it (with all due respect to these wonderful products), or their functionality is redundant for urgent tasks. At the same time, you would like to see a declarative description of the test suite in a concise form
- if you have your own opinion on how to test the API, and do not want to use fuzzers, which are more complicated and may not find the issue. You want to write your own fuzzing scenarios for each JSON parameter (add datasets, mutations, random data in the right places, etc.)
- if you need somke tests in the pipeline
- if you need an additional fuzzer that is easier to adjust for spot checks
POST JSON Fuzzer does not look for vulnerabilities, but tries to break the service and show under what conditions it turned out to be possible. If you find a vulnerability in your API using this fuzzer, remember that before that you found a bug, and only then a vulnerability. For this tool, this is the key idea.
- aiohttp~=3.8.1
- asyncio~=3.4.3
- allpairspy~=2.5.0
- pyradamsa~=0.1.1
- pytest~=7.1.1
- texttable~=1.6.4
- tqdm~=4.64.0
- black~=22.3.0
- requests~=2.27.1
- urllib3~=1.26.9
- numpy~=1.23.1
docker build --tag post_json_fuzzer:0.0.9 .
docker run -v /tmp/decks:/decks -v /tmp/results:/results --rm --name post_json_fuzzer.container post_json_fuzzer:0.0.9 -url="https://YOUR_ENDPOINT" -H "X-HEADER-UUID=HEADER-UUID" "X-API-Secret=API-Secret" -file "decks/my_json_fuzzing_profile.deck"To run basic tests go to tests/ dir and run:
pytest .usage: postjsonfuzzer.py [-h] -url URL -file PATH_TO_DECK_FILE
[--headers [HEADERS [HEADERS ...]]]Authentication: Works with secret tokens only (within headers), there is no other authentication scenarios yet.