tno-s3/wuppiefuzzEin coverage-gesteuerter REST-API-Fuzzer, entwickelt auf Basis von LibAFL
WuppieFuzz wurde von TNO entwickelt, ein abdeckungsgesteuerter REST-API-Fuzzer auf Basis von LibAFL, der sich an ein breites Publikum von Endanwendern richtet und einen starken Fokus auf Benutzerfreundlichkeit, Erklärbarkeit der entdeckten Schwachstellen und Modularität legt. WuppieFuzz unterstützt alle drei Test-Settings (Blackbox, Greybox und Whitebox).
[!NOTE]
Für eine schnelle Schritt-für-Schritt-Anleitung folgen Sie bitte dem Tutorial!
WuppieFuzz wurde vorgestellt in:
Wenn Sie WuppieFuzz in einer wissenschaftlichen Arbeit zitieren möchten, verwenden Sie bitte die bevorzugte Veröffentlichung, die in CITATION.cff aufgeführt ist:
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 ist unter Apache-2.0 lizenziert; siehe LICENSE.
Hinweise zu Lizenzen Dritter finden Sie in THIRD_PARTY_NOTICES.
Für eine schnelle Installation von WuppieFuzz auf gängigen Betriebssystemen (macOS, Windows, Linux) siehe Releases oder verwenden Sie brew install wuppiefuzz
Um das Projekt zu bauen, müssen Sie die folgenden Abhängigkeiten und Werkzeuge installieren:
sudo apt install build-essentialsudo apt install pkg-configcurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shBevor Sie WuppieFuzz ausführen, müssen Sie Ihre (instrumentierte) Zielanwendung starten.
Zusätzlich müssen Sie WuppieFuzz eine OpenAPI-Spezifikation zur Verfügung stellen, damit es weiß, wie es seine Requests generieren und mutieren kann. Hilfe zu den Befehlszeilenargumenten erhalten Sie mit dem folgenden Befehl:
$ cargo run -- --help # shows help for required parameters and flags
Usage: wuppiefuzz [OPTIONS] [OPENAPI_SPEC.YAML]
...
Um WuppieFuzz beispielsweise gegen ein Java-Ziel mit angehängtem JaCoCo-Agenten auszuführen, geben Sie dessen OpenAPI-Datei an (die die URL enthält, auf der das Ziel in der API-Spezifikation läuft). Zusätzlich geben Sie an, dass das Coverage-Format JaCoCo ist, und übergeben das Klassenverzeichnis wie folgt:
cargo run -- fuzz openapi.yaml --coverage-format jacoco --jacoco-class-dir ../Targets/app/target/classes/
Wenn Sie anstelle von Befehlszeilenargumenten oder in Kombination mit diesen eine Konfigurationsdatei verwenden möchten, können Sie das Flag --config <CONFIG_FILE> nutzen. Falls Sie Befehlszeilenargumente in Kombination mit einer Konfigurationsdatei verwenden, haben die Befehlszeilenargumente Vorrang.
Die Konfigurationsdatei sollte eine YAML-Datei sein und für jedes Befehlszeilenargument, das Sie angeben möchten, eine Zeile enthalten, zum Beispiel:
coverage_format: jacoco
output_format: human-readable
source_dir: "/swagger-petstore/src/main/java"
jacoco_class_dir: "/swagger-petstore/target"
timeout: 20
Ein Beispiel für einen Ausführungsbefehl könnte in diesem Fall sein:
$ cargo run -- fuzz --config=config.yaml --report --coverage-host=localhost:6300 --timeout=10 ./openapi.yaml
Dieser Befehl kombiniert die Argumente von der Befehlszeile und aus der Konfigurationsdatei. Da das Flag --timeout in beiden angegeben ist, hat der in der Befehlszeile angegebene Timeout (10 Sekunden) Vorrang.
Im Verzeichnis example_configs/ finden Sie zwei Beispiel-Konfigurationsdateien: eine zur Erzeugung von Coverage-Berichten mit JaCoCo für Java-Code und eine zur Erzeugung von Coverage-Berichten mit LCOV für Python-Code.
Wenn Sie WuppieFuzz mit dem Flag --report ausführen, wird ein Unterverzeichnis in reports/ mit einem Zeitstempel als Namen erstellt. Alle unterstützten Coverage-Berichte werden in dieses Unterverzeichnis geschrieben. Es gibt zwei Arten von Coverage-Berichten:
Darüber hinaus wird eine Datenbank mit allen Request-Informationen Ihrer Fuzzing-Kampagne gefüllt. Diese Datenbank kann über das Grafana-Dashboard visualisiert und untersucht werden.
Weitere Informationen zu jedem dieser Punkte finden Sie in den README-Dateien in diesen Verzeichnissen.
Standardmäßig bindet WuppieFuzz seine C-Abhängigkeiten (OpenSSL, SQLite, Z3) ein, sodass ein reguläres cargo build sofort funktioniert. Für schnellere Kompilierung während der Entwicklung können Sie alle eingebundenen Abhängigkeiten deaktivieren und stattdessen gegen systemweit installierte Bibliotheken linken.
[!NOTE] Die
z3-Crate erfordert Z3 4.15+, eine neuere Version als die, die von den meisten Paketverwaltern der Linux-Distributionen bereitgestellt wird. Installieren Sie Z3 über Homebrew (brew install z3), um eine kompatible Version zu erhalten.
Installieren Sie die folgenden Bibliotheken auf Ihrem System:
Debian/Ubuntu:
sudo apt install libssl-dev libsqlite3-dev
brew install z3 # apt's libz3-dev is too old; use Homebrew instead
Unter Linux installiert Homebrew in einen nicht standardmäßigen Pfad. Fügen Sie dessen Bibliotheksverzeichnis zu Ihrer Umgebung hinzu, damit Compiler und Laufzeitlinker Z3 finden können:
eval "$(brew shellenv)"
export LIBRARY_PATH="$(brew --prefix z3)/lib:$LIBRARY_PATH"
export LD_LIBRARY_PATH="$(brew --prefix z3)/lib:$LD_LIBRARY_PATH"
[!TIP] Fügen Sie die obigen Zeilen zu Ihrer
~/.bashrcoder~/.zshrchinzu, um sie dauerhaft zu machen.
Fedora (42+):
sudo dnf install openssl-devel sqlite-devel z3-devel
macOS (Homebrew):
brew install openssl sqlite z3
Das Repository enthält Cargo-Aliase in .cargo/config.toml, die mit --no-default-features bauen und gegen alle Systembibliotheken linken:
cargo dev-build # build without vendored dependencies
cargo dev-run -- <args> # run without vendored dependencies
cargo dev-test # test without vendored dependencies
Mit cargo doc --no-deps wird die Dokumentation aus Kommentaren im Quellcode erzeugt. Die Hauptseite der Dokumentation befindet sich unter target/doc/wuppiefuzz/index.html.