Yelp / fuzz-lightyear

A pytest-inspired, DAST framework, capable of identifying vulnerabilities in a distributed, micro-service ecosystem through chaos engineering testing and stateful, Swagger fuzzing.
Other
205 stars 25 forks source link

Add exclusions decorator #9

Closed OiCMudkips closed 5 years ago

OiCMudkips commented 5 years ago

This adds two decorators fuzz_lightyear.exclusions.non_vulnerable_operations and fuzz_lightyear.exclusions.operations. The former specifies operations which should not be tested for vulnerability, and the latter specifies operations which should not be included in the fuzzing process at all.

This fixture borrows the same code-flow as the factory fixtures, which is that users use these decorators to decorate functions which are called by fuzz_lightyear at a later point.

Why specify endpoints with "operation_id" instead of "tag.operation_id"?

Swagger says that the operation_id must be unique in the spec, so this makes it easier for developers to specify whitelisted endpoints.

TODO

Actually do something with the operations we read in

Auto-close

Fixes #3

OiCMudkips commented 5 years ago

I like your distinction you made with non_vulnerable_operations and operations. I'm not sure how that intends to be used, but I'm curious to learn more.

With regards to only using {operation_id}, rather than {tag}.{operation_id}, I initially wanted to do this because it matches the use case of -t flag. The -t flag emulates the test failure output, and the test failure output prefixes it with the tag so that it's easier to find the endpoint with Swagger UI.

I think consistency is valuable here, so whatever we choose, we should apply to all these cases.

Let's support both in the whitelisting feature?

EDIT: I'll also note that it seems like tags are 100% optional in swagger specs - it just happens that at Yelp we make use of them.