
Un fuzzer d'API REST guidé par la couverture, développé sur la base de LibAFL
TNO a développé WuppieFuzz, un fuzzer d'API REST guidé par la couverture, construit sur LibAFL, ciblant un large public d'utilisateurs finaux, avec un fort accent sur la facilité d'utilisation, l'explicabilité des failles découvertes et la modularité. WuppieFuzz prend en charge les trois modes de test (boîte noire, boîte grise et boîte blanche).
[!NOTE]
Pour un guide rapide et pas à pas, veuillez suivre le tutoriel !
WuppieFuzz a été présenté dans :
Si vous souhaitez citer WuppieFuzz dans un travail académique, veuillez utiliser la publication préférée listée dans CITATION.cff :
Rooijakkers, T., Nijsten, A., Daniele, C., Weitenberg, E., Groenewegen, R., & Melissen, A. (2026). WuppieFuzz: Coverage-Guided, Stateful REST API Fuzzing. In Proceedings of the 12th International Conference on Information Systems Security and Privacy (ICISSP), Volume 2, 221-231. SciTePress. https://doi.org/10.5220/0000217100004061
WuppieFuzz est sous licence Apache-2.0 ; voir LICENSE.
Les mentions de licence tierces sont listées dans THIRD_PARTY_NOTICES.
Pour une installation rapide de WuppieFuzz sur les systèmes d'exploitation populaires (MacOS,
Windows, Linux), voir releases ou utilisez brew install wuppiefuzz
Vous pouvez construire l'image Docker avec docker build . -t wuppiefuzz:local. Pour l'utiliser, vous devez monter un dossier contenant votre spécification OpenAPI. Lorsque vous fuzzuez un service que vous exécutez localement (pas dans Docker), vous devez spécifier le réseau de l'hôte :
docker run \
--network host \
-v ./fuzzing-folder:/fuzzing-folder \ # The folder will be populated with wuppiefuzz outputs
-w /fuzzing-folder \
wuppiefuzz:local fuzz --timeout 60 --report openapi.json
Pour construire le projet, vous devez installer les dépendances et outils suivants :
sudo apt install -y build-essential pkg-config cmake # General build tools
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh # Rust
Avant d'exécuter WuppieFuzz, vous devez démarrer votre application cible (instrumentée).
De plus, vous devez fournir à WuppieFuzz une spécification OpenAPI afin qu'il sache comment générer et muter ses requêtes. Pour obtenir de l'aide sur les arguments de ligne de commande, utilisez ce qui suit :
$ cargo run -- --help # shows help for required parameters and flags
Usage: wuppiefuzz [OPTIONS] [OPENAPI_SPEC.YAML]
...
Par exemple, pour exécuter WuppieFuzz contre une cible Java avec l'agent JaCoCo attaché, vous spécifiez son fichier OpenAPI (contenant l'URL sur laquelle la cible est exécutée dans la spécification de l'API). De plus, vous spécifiez que le format de couverture est JaCoCo, et indiquez le répertoire des classes comme suit :
cargo run -- fuzz openapi.yaml --coverage-format jacoco --jacoco-class-dir ../Targets/app/target/classes/
Si vous souhaitez utiliser un fichier de configuration à la place des arguments de
ligne de commande, ou en combinaison avec ceux-ci, vous pouvez utiliser le drapeau --config <CONFIG_FILE>. Si vous utilisez
des arguments de ligne de commande en combinaison avec un fichier de configuration, les arguments de ligne de commande
ont la priorité.
Le fichier de configuration doit être un fichier yaml et contenir une ligne pour chaque argument de ligne de commande que vous souhaitez spécifier, par exemple :
coverage_format: jacoco
output_format: human-readable
source_dir: "/swagger-petstore/src/main/java"
jacoco_class_dir: "/swagger-petstore/target"
timeout: 20
Un exemple de commande d'exécution pourrait dans ce cas être :
$ cargo run -- fuzz --config=config.yaml --report --coverage-host=localhost:6300 --timeout=10 ./openapi.yaml
Cette ligne combinerait les arguments de la ligne de commande et du fichier de
configuration. Comme le drapeau --timeout est spécifié dans les deux, le timeout spécifié dans
la ligne de commande (10 secondes) aura la priorité.
Dans le répertoire example_configs/ vous trouverez deux exemples de fichiers de configuration à
utiliser pour générer des rapports de couverture avec JaCoCo pour du code Java et pour générer
des rapports de couverture avec LCOV pour du code Python.
Lorsque vous exécutez WuppieFuzz avec le drapeau --report, un sous-répertoire est créé dans
reports/ avec un horodatage comme nom. Tous les rapports de couverture pris en charge sont
écrits dans ce sous-répertoire. Il existe deux types de rapports de couverture :
En plus de cela, une base de données est remplie avec toutes les informations de requêtes liées à votre campagne de fuzzing. Cette base de données peut être visualisée et explorée via le tableau de bord Grafana.
Pour plus d'informations sur chacun de ces éléments, voir les READMEs dans ces répertoires.
Par défaut, WuppieFuzz embarque ses dépendances C (OpenSSL, SQLite, Z3) afin qu'un
cargo build classique fonctionne immédiatement. Pour une compilation plus rapide pendant
le développement, vous pouvez désactiver toutes les dépendances embarquées et lier contre
des bibliothèques installées sur le système à la place.