
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, 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 pas à pas, veuillez consulter 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 avis de licences tierces sont répertoriés dans THIRD_PARTY_NOTICES.
Pour une installation rapide de WuppieFuzz sur les systèmes d'exploitation courants (MacOS,
Windows, Linux), voir les releases ou utilisez brew install wuppiefuzz
Pour compiler le projet, vous devez installer les dépendances et outils suivants :
sudo apt install build-essentialsudo apt install pkg-configcurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shAvant 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 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 s'exécute 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 complément de 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 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 dans ce cas pourrait ê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 ceux du fichier
de configuration. Comme le drapeau --timeout est spécifié dans les deux, le délai
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.
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 sur les 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, consultez les README dans ces répertoires.
Par défaut, WuppieFuzz intègre ses dépendances C (OpenSSL, SQLite, Z3) afin qu'une
compilation cargo build standard fonctionne directement. Pour une compilation plus
rapide pendant le développement, vous pouvez désactiver toutes les dépendances
intégrées et lier les bibliothèques installées sur le système à la place.
[!NOTE] La crate
z3nécessite Z3 4.15+, une version plus récente que celle fournie par la plupart des gestionnaires de paquets des distributions Linux. Installez Z3 via Homebrew (brew install z3) pour obtenir une version compatible.
Installez les bibliothèques suivantes sur votre système :
Debian/Ubuntu :
sudo apt install libssl-dev libsqlite3-dev
brew install z3 # apt's libz3-dev is too old; use Homebrew instead
Sous Linux, Homebrew 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
~/.bashrcou~/.zshrcpour les rendre permanentes.
Fedora (42+) :
sudo dnf install openssl-devel sqlite-devel z3-devel
macOS (Homebrew) :
brew install openssl sqlite z3
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 # build without vendored dependencies
cargo dev-run -- <args> # run without vendored dependencies
cargo dev-test # test without vendored dependencies
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