Payload generation from response data

[Gby56]

This is more of an idea/solution proposition, I have explored it with a POC. Most of the time, openapi fuzzing will randomize data from the spec and end up making a lot of requests that won't drill into the actual implementation because of access control or non-existing ids. (403 and 404)

My idea for this is a recursive crawler on the api, by taking a look at the responses from "easy" paths that return some data, and inferring the data with the required parameters for other paths. By reusing the data you ensure that objects will actually exist, and you can check for IDOR easily.

It's a bit complex but I think storing a catalog of known good parameters can speed up the process of exploring the API. Whenever you fuzz a new path, look at the parameters and see if you have known ones that should work, check if you get 200 and then mutate that parameter. Otherwise it feels a bit like brute forcing a lot of uuids and ids in paths.

The only alternative I know of is proxy-based fuzzing which doesn't have a lot of tools afaik. Some can fuzz lower level protocols but for HTTP I don't remember seeing a lot (maybe burp has a fancy plugin, I know that Autorize can check IDOR because it replays good requests and mutates that)

[Gby56]

Just remembered that restler does that https://github.com/microsoft/restler-fuzzer

[KissPeter]

Hi, Thanks for the idea. The primary goal of Apifuzzer was to focus on the input validation of API implementations. This would be anothet step. The focus currently is to widen the supported API standardrs like for Graph API, but not deepen it. Regardless any PR is welcome