restler-fuzzer
bachelor-thesis | restler-fuzzer | |
---|---|---|
2 | 15 | |
1 | 2,470 | |
- | 1.4% | |
0.0 | 7.3 | |
over 2 years ago | 5 days ago | |
TeX | Python | |
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
bachelor-thesis
-
Show HN: OpenAPI fuzzer – fuzzing APIs based on OpenAPI specification
Yes, we looked into it. There is a chapter in my thesis[0] about RESTler and comparison with OpenAPI fuzzer. The main difference between those two fuzzer is that RESTler is a statefull fuzzer and OpenAPI fuzzer is a stateless fuzzer.
Thanks to being statefull, RESTler is able to analyze a dependencies between a requests. For example, it will not call and endpoint to get user details before calling endpoint to create a user. This should make it more efficient because it does not waste requests to calling endpoint that will return 404.
On the other hand, fuzzing is all about trying to supply unexpected input to the software. Therefore, OpenAPI fuzzer makes those requests, since it may cause some undefined behavior when we try to get user before creating one.
So while RESTler tries to check some invariant (for example if deleted user cannot be accessed) OpenAPI fuzzer tries to cause the service to crash by invalid input. RESTler is usually not able to crash the service by providing invalid input, because it needs to keep the fuzzing dictionary small (bigger dictionary would make the dependency finding slow). So I think, they complements each other nicely.
Another difference it in reporting error. RESTler considers only status code 500 as an error. However, OpenAPI specification states all possible status codes that we can get from an endpoint. OpenAPI fuzzer utilizes this and reports every time it receives and unexpected status code.
0: https://github.com/matusf/bachelor-thesis/releases/download/...
restler-fuzzer
- Protegendo APIs da Esquerda para a Direita (e em td no meio do caminho) [Tradução +/- Comentada]
-
Machine Learning Helps Fuzzing Find Hardware Bugs
It is popular in domains where it’s effective but it’s not as useful when it’s hard to know if an output is correct. I know several tools which fuzz mobile app UIs to see if you can cause crashes or irrecoverable states with random inputs because those are easy to detect, but beyond that you start needing to have more traditional QA approaches to say whether the resulting state is correct.
One area which is very interesting is the use of OpenAPI schemas to help with APIs since you can use the schemas to guide generation and validation. It’s non-trivial to do with authentication but I found this project of interest:
https://github.com/microsoft/restler-fuzzer
- RESTler is a stateful REST API fuzzing tool
- RESTler: Stateful REST API fuzzing tool
- GitHub - microsoft/restler-fuzzer: RESTler is the first stateful REST API fuzzing tool for automatically testing cloud services
- RESTler API fuzzing is now on Github (finally ?
-
Show HN: OpenAPI fuzzer – fuzzing APIs based on OpenAPI specification
There's another one here by Microsoft - this is cool though! great to see more Rust tools.
https://github.com/microsoft/restler-fuzzer
- Web app Fuzzing
-
I need some help building an API from github
once you install git, just do git clone https://github.com/microsoft/restler-fuzzer
What are some alternatives?
openapi-fuzzer - Black-box fuzzer that fuzzes APIs based on OpenAPI specification. Find bugs for free!
cats - CATS is a REST API Fuzzer and negative testing tool for OpenAPI endpoints. CATS automatically generates, runs and reports tests with minimum configuration and no coding effort. Tests are self-healing and do not require maintenance.
openapiv3 - Rust Open API v3 Structs and Enums for easy deserialization with serde