# Restler + Flask: RESTFUL API Fuzzing with Entrypoint into Flask

## Team Members:
- Chiao Lu
- UID: 204848946
- email: [e-mail]
- Boyan Ding
- UID: 205331471
- email: [e-mail]
- Jiaxin Ge
- UID: 905526210
- email: [e-mail]
- Yuyue Wang
- UID: 205728527
- email: [e-mail]

## Problem Definition
From Microsoft [RESTler Git Repo](https://github.com/microsoft/restler-fuzzer):
> RESTler is the first stateful REST API fuzzing tool for automatically testing cloud services through their REST APIs and finding security and reliability bugs in these services.

One critical limitation of RESTler is that the backend (e.g. Express.js or Flask) is treated as a blackbox, and error can only be observed with HTTP status code (e.g. 500 for Internal Server Error). As a result,
1. Warnings triggered in the backend is not known to RESTler.
2. Error type (e.g. `DivisionByZeroError` or `FileNotFoundError`) is not known to RESTler as it only receives `500: Internal Server Error`.
3. If no response received, why? Is the backend still running?

We would like to investigate the possibility providing an entrypoint into the backend for RESTler, so that RESTler can open the blackbox of the REST API server being tested (like what AFL does).

## Related Work

Restler is the first statful REST API fuzzer that analyzes the API specification of a cloud service and generates sequences of requests that automatically test the service through its API.

It was first proposed by [Atlidakis et al.](https://patricegodefroid.github.io/public_psfiles/icse2019.pdf) (ICSE 2019) which emphasized two critical test sequences generation rules: inferring producer-consumer dependencies among request types to generate valid test inputs (e.g. request A must be sent before request B) and analyzing dynamic feedback from previous test responses to prune the large search space of possible request sequences.

Restler successfully found 28 bugs in GitLan and several bugs in each of the Azure and Office365 cloud services; However, it has several limitations as well. First, it can only find bugs defined as unexpected HTTP status code. Secondly, it could only discover vulnerabilitiles that are visible through HTTP status code. In order to improve Restler, a few more researches were conducted.

In 2020, Restler was extended with active property checkers that automatically test and detect violations of security rules by [Atlidakis et al.](https://patricegodefroid.github.io/public_psfiles/icst2020.pdf) (ICST 2020). In this paper, Restler was enabled to catch bugs in the cloud service that allow attackers to violate security rules including Use-after-free rule, Resource-leak rule, Resource-hierarchy rule and User-namespace rule.

[Godefroid et al.](https://patricegodefroid.github.io/public_psfiles/fse2020.pdf) (FSE 2020) futher extended Restler to find data-processing bugs in cloud service. They enhenced Resterler by intelligently generating data payloads so that it can reach and test deeper service states.

[Godefroid et al.](https://patricegodefroid.github.io/public_psfiles/issta2020.pdf) (ISSTA 2020) also employed differential testing via Restler in order to prevent breaking changes of APIs. That is, they compared the behavior of different versions on the same inputs against each other, and find regressions in the observed differences.

## Benchmarks and Target Subject Applications
### Subject Programs
- Handcrafted simple Flask server

### Benchmark
Show that our improved method can also capture issues not visible to original RESTler
- warnings
- details of the error (e.g. `500` return code is caused by `DynamicTypeError`)

## Potential Work
RESTler currently uses BFS-Fast, can we try different searching algorithm?
- A*
- Genetic algorithm
- ...