Closed OiCMudkips closed 5 years ago
I like your distinction you made with
non_vulnerable_operations
andoperations
. 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.
This adds two decorators
fuzz_lightyear.exclusions.non_vulnerable_operations
andfuzz_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