I think the real conclusion here is... No substantial security issues were discovered. There are a few things github could change to better follow security best practices to help avoid future bugs.
It's a fine line, if Github wanted to I'm sure they could write up a convincing cease and desist. I think they spoke up about it because your article gives the impression that this sort of thing (fuzzing APIs) is okay, which I wouldn't exactly say is positive.
True. This is why I run it only for one path. I also run it against Kubernetes API and some of the payloads resulted in timeouts which I submitted to the security team.
The cats tool looks interesting I'm curious how it handles fuzzing id columns, which would need a reference to another resource to actually test them.
I would like a tool which can take insertion order of the api and start inserting things at random based on a spec to test it.
Currently, there is some support for resource correlation. Especially when fuzzing DELETE, it will identify a successful POST based on conventions and use that as an identifier. Also checking that DELETEd resources are not available anymore.
Say i have an order record, it needs company and product.
The fuzzer should be smart enough to first generate company and product then use them to create orders. Similarly the fuzzer should be able to build a whole graph of the api data model and be able to execute actions on it in a particular order testing all the actions
> The InvalidValuesInEnumsFieldsFuzzer will send invalid values in enum fields. It expects a validation error in return. The GitHub API does not seem to reject invalid values, but rather convert them to a default value and respond successfully to the request. This is in contradiction with the OWASP recommendation around strong input validation and data type enforcing.
Doing this is incredibly good practice for compatibility, because otherwise you can never add or remove enum values because older clients will break on the unknown values. I also fail to see how it violates the recommendation, invalid data doesn't enter the system.
Imagine all webservers and browsers would need to be updated for every new HTTP header or status code is specified or web pages don't work anymore...
As long as an API rejects invalid values if they are not part of an agreed list (but not enum), the same logic should apply for fields explicitly marked as enums.
HTTP headers are not meant to be a limited set. As for the HTTP methods, it's a clear recommendation from OWASP to explicitly reject methods not supported by your API. It's like converting everything not known to POST...
GitHub performs fuzzing as part of their testing, so I'm not surprised there aren't any significant findings. I am surprised this is on hackernews two years later though.
Would any of these errors be present if they used GraphQL instead of REST? Obviously the ones with headers can still happen, but it looks like everything else is related to schema enforcement
I know, I'm wondering if switching to something like GraphQL or tRPC would solve many of these issues, which seem to be around violating the OpenAPI contract
