A pytest-inspired, DAST framework, capable of identifying vulnerabilities in a distributed, micro-service ecosystem through chaos engineering testing and stateful, Swagger fuzzing.
For our MVP, we've managed to get around the issue of "statefulness" through our fixture architecture. After all, instead of creating a resource through a REST API call, we do it in code instead. This simulates a stateful request, as the following diagram illustrates:
Original:
CREATE resource --> GET resource
fuzz-lightyear:
[ CREATE resource with fixture --> ] GET resource
Issue
What about handling requests where the resource is actually able to be created within the Swagger specification? We need to incorporate proper statefulness in this fuzzer.
Solution
It turns out, this wasn't as hard as expected, mainly because we were already storing the data in the ResponseSequence object. The hard bit is to figure out whether this catches all cases of stateful requests, and to get flask-restplus to corporate.
A note on caching fixture generated request variables:
The reason why we do this only to fixture-generated parameters (rather than all parameters), is because fixtures supplement the fuzzing approach by manually specifying how to create certain resources, which would otherwise have been done through a request-response cycle in a traditional CRUD application. This means that their output would have been returned in a response, and used in state-driven testing.
Background Context
For our MVP, we've managed to get around the issue of "statefulness" through our fixture architecture. After all, instead of creating a resource through a REST API call, we do it in code instead. This simulates a stateful request, as the following diagram illustrates:
Issue
What about handling requests where the resource is actually able to be created within the Swagger specification? We need to incorporate proper statefulness in this fuzzer.
Solution
It turns out, this wasn't as hard as expected, mainly because we were already storing the
datain theResponseSequenceobject. The hard bit is to figure out whether this catches all cases of stateful requests, and to getflask-restplusto corporate.A note on caching fixture generated request variables:
The reason why we do this only to fixture-generated parameters (rather than all parameters), is because fixtures supplement the fuzzing approach by manually specifying how to create certain resources, which would otherwise have been done through a request-response cycle in a traditional CRUD application. This means that their output would have been returned in a response, and used in state-driven testing.