Fuzz testování REST API
Loading...
Date
Authors
ORCID
Advisor
Referee
Mark
B
Journal Title
Journal ISSN
Volume Title
Publisher
Vysoké učení technické v Brně. Fakulta informačních technologií
Abstract
Táto práca sa zaoberá fuzz testovaním REST API. Po prezentovaní prehľadu techník používaných pri fuzz testovaní a posúdení aktuálnych nástrojov a výskumu zameraného na REST API fuzz testovanie, sme pristúpili k návrhu a implementácii nášho REST API fuzzeru. Základom nášho riešenia je odvodzovanie závislostí z OpenAPI formátu popisu REST API, umožňujúce stavové testovanie aplikácie. Náš fuzzer minimalizuje počet po sebe nasledujúcich 404 odpovedí od aplikácie a testuje aplikáciu viac do hĺbky. Problém prehľadávania dostupných stavov aplikácie je riešený pomocou usporiadania závislostí tak, aby sa maximalizovala pravdepodobnosť získania potrebných vstupných dát pre povinné parametre, v kombinácii s rozhodovaním, ktoré povinné parametre môžu využívať aj náhodne generované hodnoty. Implementácia je rozšírením Schemathesis projektu, ktorý generuje vstupy za pomoci Hypothesis knižnice. Implementovaný fuzzer je použitý na testovanie Red Hat Insights aplikácie, kde našiel 32 chýb, z čoho jednu chybu je možné reprodukovať len za pomoci stavového testovania.
This thesis is dealing with fuzz testing of REST API. After presenting state-of-the-art of fuzzing and assessing the current research regarding REST API fuzz testing, we design and implement our REST API fuzzer. The proposed fuzzer infers dependencies of API calls defined in an OpenAPI specification and makes the fuzzing stateful. One of the features is minimization of the number of successive 404 responses while maintaining exploration of a deeper state space of a tested application. To solve the exploration vs. exploitation problem, we used the ordering of dependencies maximizing the probability of obtaining a needed input values and determining of fuzzability of a required parameters. The implementation is an enhancement of the Schemathesis project that is using the Hypothesis library to randomly generate inputs. Our fuzzer is evaluated against the Red Hat Insights application, finding 32 bugs. Amid them, one bug is reproducible only by a stateful set of steps.
This thesis is dealing with fuzz testing of REST API. After presenting state-of-the-art of fuzzing and assessing the current research regarding REST API fuzz testing, we design and implement our REST API fuzzer. The proposed fuzzer infers dependencies of API calls defined in an OpenAPI specification and makes the fuzzing stateful. One of the features is minimization of the number of successive 404 responses while maintaining exploration of a deeper state space of a tested application. To solve the exploration vs. exploitation problem, we used the ordering of dependencies maximizing the probability of obtaining a needed input values and determining of fuzzability of a required parameters. The implementation is an enhancement of the Schemathesis project that is using the Hypothesis library to randomly generate inputs. Our fuzzer is evaluated against the Red Hat Insights application, finding 32 bugs. Amid them, one bug is reproducible only by a stateful set of steps.
Description
Keywords
fuzz testovanie, fuzzing, fuzzer, REST API, testovanie, generovanie testov, získavanie závislostí, stavové testovanie, Hypothesis, JSON Schema, OpenAPI, Swagger, Schemathesis, fuzz testing, fuzzing, fuzzer, REST API, testing, test generation, inferring dependencies, stateful testing, property based testing, Hypothesis, JSON Schema, OpenAPI, Swagger, Schemathesis
Citation
SEGEDY, P. Fuzz testování REST API [online]. Brno: Vysoké učení technické v Brně. Fakulta informačních technologií. 2020.
Document type
Document version
Date of access to the full text
Language of document
en
Study field
Bezpečnost informačních technologií
Comittee
prof. Ing. Martin Drahanský, Ph.D. (předseda)
doc. Ing. Jan Kořenek, Ph.D. (místopředseda)
Ing. Matěj Grégr, Ph.D. (člen)
doc. Mgr. Lukáš Holík, Ph.D. (člen)
Mgr. Kamil Malinka, Ph.D. (člen)
Ing. Libor Polčák, Ph.D. (člen)
Date of acceptance
2020-07-14
Defence
Student nejprve prezentoval výsledky, kterých dosáhl v rámci své práce. Komise se poté seznámila s hodnocením vedoucího a posudkem oponenta práce. Student následně odpověděl na otázku oponenta a na další otázky přítomných. Komise se na základě posudku oponenta, hodnocení vedoucího, přednesené prezentace a odpovědí studenta na položené otázky rozhodla práci hodnotit stupněm B. Otázky u obhajoby: Proč v případě neúspěšného tetovacího případu nejprve zvýšíte hodnotu "confidence" o 5 a následně ještě vynásobíte číslem 2, zatímco v případě úspěšného testovacího případu naopak pouze vydělíte 2 (viz listing 5.5 na straně 42)? Co znamená zkratka REST? K čemu byl použit nástroj Schemathesis?
Result of defence
práce byla úspěšně obhájena
Document licence
Standardní licenční smlouva - přístup k plnému textu bez omezení