WuppieFuzz v1.7.1

TNO a développé WuppieFuzz, un fuzzer d'API REST guidé par la couverture, développé sur la base de LibAFL, destiné à 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 à suivre, veuillez consulter le tutoriel !

Couverture médiatique

WuppieFuzz a été présenté dans :

Publication scientifique

Si vous souhaitez citer WuppieFuzz dans un travail académique, veuillez utiliser la publication privilégié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

Licence

WuppieFuzz est sous licence Apache-2.0 ; voir LICENSE.
Les avis de licence de tiers sont listés dans THIRD_PARTY_NOTICES.

Installation rapide

Pour une installation rapide de WuppieFuzz sur les systèmes d'exploitation courants (MacOS, Windows, Linux), voir releases ou utilisez brew install wuppiefuzz

Guide rapide

Prérequis pour le développement

Pour compiler le projet, vous devez installer les dépendances et outils suivants

build-essential sudo apt install build-essential
pkg-config sudo apt install pkg-config
Rust curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Exécution

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 la ligne de commande, utilisez la commande suivante :

$ cargo run -- --help # affiche l'aide pour les paramètres et options requis

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 s'exécute dans la spécification de l'API). De plus, vous spécifiez que le format de couverture est JaCoCo, et vous indiquez le répertoire des classes comme suit :

cargo run -- fuzz openapi.yaml --coverage-format jacoco --jacoco-class-dir ../Targets/app/target/classes/

Fichier de configuration

Si vous souhaitez utiliser un fichier de configuration à la place/en combinaison avec les arguments de la ligne de commande, vous pouvez utiliser l'option --config <CONFIG_FILE>. Si vous utilisez des arguments de ligne de commande en combinaison avec un fichier de configuration, les arguments de la ligne de commande ont 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

Une commande d'exécution d'exemple 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. Étant donné que l'option --timeout est spécifiée dans les deux, le délai d'expiration spécifié dans la ligne de commande (10 secondes) aura 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 le code Java et pour générer des rapports de couverture avec LCOV pour le code Python.

Rapports

Lorsque vous exécutez WuppieFuzz avec l'option --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 :

couverture des points de terminaison : elle peut toujours être générée car elle ne nécessite que la spécification OpenAPI.
couverture du code : actuellement uniquement prise en charge pour JaCoCo, mais nous visons à en prendre en charge davantage. La partie délicate est que cela nécessite un mappage de la couverture vers les fichiers sources, et une génération de rapports robuste qui l'utilise.

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.

Structure de ce dépôt

assets : logos, images, etc.
coverage_agents : code et instructions pour le suivi de couverture à appliquer sur diverses cibles
example_configs : exemples de fichiers de configuration pour configurer WuppieFuzz
src : code source de WuppieFuzz
tutorial : un tutoriel approfondi et de bas niveau sur la façon de fuzzer une cible spécifique et d'interpréter les résultats de fuzzing
dashboard : outils pour trier les résultats de fuzzing et les performances

Pour plus d'informations sur chacun de ces éléments, voir les README dans ces répertoires.

Compilation de développement

Par défaut, WuppieFuzz fournit ses dépendances C (OpenSSL, SQLite, Z3) afin qu'une compilation cargo build standard fonctionne immédiatement. Pour une compilation plus rapide pendant le développement, vous pouvez désactiver toutes les dépendances fournies et lier les bibliothèques installées sur le système à la place.

[!NOTE] La crate z3 nécessite Z3 4.15+, qui est plus récent que la version fournie par la plupart des gestionnaires de paquets des distributions Linux. Installez Z3 via Homebrew (brew install z3) pour obtenir une version compatible.

Dépendances système

Installez les bibliothèques suivantes sur votre système :

Debian/Ubuntu :

sudo apt install libssl-dev libsqlite3-dev
brew install z3  # le libz3-dev d'apt est trop ancien ; utilisez Homebrew à la place

Sur Linux, Homebrew s'installe dans un chemin non standard. Ajoutez son répertoire de bibliothèques à votre environnement afin que le compilateur et l'éditeur de liens d'exécution puissent trouver Z3 :

eval "$(brew shellenv)"
export LIBRARY_PATH="$(brew --prefix z3)/lib:$LIBRARY_PATH"
export LD_LIBRARY_PATH="$(brew --prefix z3)/lib:$LD_LIBRARY_PATH"

[!TIP] Ajoutez les lignes ci-dessus à votre ~/.bashrc ou ~/.zshrc pour les rendre permanentes.

Fedora (42+) :

sudo dnf install openssl-devel sqlite-devel z3-devel

macOS (Homebrew) :

brew install openssl sqlite z3

Alias Cargo

Le dépôt inclut des alias cargo dans .cargo/config.toml qui compilent avec --no-default-features, en liant toutes les bibliothèques système :

cargo dev-build          # compile sans dépendances fournies
cargo dev-run -- <args>  # exécute sans dépendances fournies
cargo dev-test           # teste sans dépendances fournies

Génération de la documentation

cargo doc --no-deps pour générer la documentation à partir des commentaires dans le code source. La page principale de la documentation sera target/doc/wuppiefuzz/index.html

Lire plus