tno-s3/wuppiefuzzUn fuzzer per API REST guidato dalla copertura, sviluppato sulla base di LibAFL
TNO ha sviluppato WuppieFuzz, un fuzzer REST API guidato dalla copertura sviluppato su LibAFL, rivolto a un'ampia gamma di utenti finali, con una forte attenzione a facilità d'uso, spiegabilità delle vulnerabilità scoperte e modularità. WuppieFuzz supporta tutte e tre le modalità di testing (black box, grey box e white box).
[!NOTE]
Per una guida rapida e passo-passo, segui il tutorial!
WuppieFuzz è stato presentato in:
Se desideri citare WuppieFuzz in un lavoro accademico, utilizza la pubblicazione preferita elencata in :
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 è concesso in licenza sotto Apache-2.0; vedi LICENSE.
Le note sulle licenze di terze parti sono elencate in THIRD_PARTY_NOTICES.
Per un'installazione rapida di WuppieFuzz sui sistemi operativi più diffusi (MacOS,
Windows, Linux), vedi releases oppure usa brew install wuppiefuzz
Per compilare il progetto devi installare le seguenti dipendenze e strumenti:
sudo apt install build-essentialsudo apt install pkg-configcurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shPrima di eseguire WuppieFuzz, devi avviare la tua applicazione target (strumentata).
Inoltre, devi fornire a WuppieFuzz una specifica OpenAPI affinché sappia come generare e mutare le sue richieste. Per aiuto sugli argomenti della riga di comando, usa quanto segue:
$ cargo run -- --help # mostra l'aiuto per i parametri e i flag richiesti
Usage: wuppiefuzz [OPTIONS] [OPENAPI_SPEC.YAML]
...
Ad esempio, per eseguire WuppieFuzz contro un target Java con l'agente JaCoCo collegato, specifica il suo file OpenAPI (contenente l'URL su cui il target è in esecuzione nella specifica API). Inoltre, specifica che il formato di copertura è JaCoCo e fornisci la directory delle classi come segue:
cargo run -- fuzz openapi.yaml --coverage-format jacoco --jacoco-class-dir ../Targets/app/target/classes/
Se desideri utilizzare un file di configurazione al posto di/in combinazione con gli
argomenti della riga di comando, puoi usare il flag --config <CONFIG_FILE>. Nel caso in cui
usi gli argomenti della riga di comando in combinazione con un file di configurazione, gli
argomenti della riga di comando hanno precedenza.
Il file di configurazione deve essere un file yaml e contenere una riga per ogni argomento della riga di comando che desideri specificare, ad esempio:
coverage_format: jacoco
output_format: human-readable
source_dir: "/swagger-petstore/src/main/java"
jacoco_class_dir: "/swagger-petstore/target"
timeout: 20
Un comando di esecuzione di esempio in questo caso potrebbe essere:
$ cargo run -- fuzz --config=config.yaml --report --coverage-host=localhost:6300 --timeout=10 ./openapi.yaml
Questa riga combinerebbe gli argomenti della riga di comando e quelli del file
di configurazione. Poiché il flag --timeout è specificato in entrambi, il timeout
specificato nella riga di comando (10 secondi) avrà precedenza.
Nella directory example_configs/ troverai due file di configurazione di esempio da
usare per generare report di copertura con JaCoCo per codice Java e per generare
report di copertura con LCOV per codice Python.
Quando esegui WuppieFuzz con il flag --report, viene creata una sottodirectory all'interno
di reports/ con un timestamp come nome. Tutti i report di copertura supportati vengono
scritti in questa sottodirectory. Esistono due tipi di report di copertura:
Inoltre, un database viene popolato con tutte le informazioni sulle richieste relative alla tua campagna di fuzzing. Questo database può essere visualizzato ed esplorato tramite la dashboard Grafana.
Per maggiori informazioni su ciascuno di questi, vedi i README in queste directory.
Per impostazione predefinita, WuppieFuzz include le sue dipendenze C (OpenSSL, SQLite, Z3) così che
una normale cargo build funzioni senza problemi. Per una compilazione più rapida durante lo
sviluppo, puoi disabilitare tutte le dipendenze incluse e collegarti alle
librerie installate sul sistema.
[!NOTE] La crate
z3richiede Z3 4.15+, che è più recente della versione fornita dalla maggior parte dei gestori di pacchetti delle distribuzioni Linux. Installa Z3 tramite Homebrew (brew install z3) per ottenere una versione compatibile.
Installa le seguenti librerie sul tuo sistema:
Debian/Ubuntu:
sudo apt install libssl-dev libsqlite3-dev
brew install z3 # libz3-dev di apt è troppo vecchio; usa Homebrew invece
Su Linux, Homebrew installa in un percorso non standard. Aggiungi la sua directory delle librerie al tuo ambiente così che il compilatore e il linker runtime possano trovare 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] Aggiungi le righe sopra al tuo
~/.bashrco~/.zshrcper renderle permanenti.
Fedora (42+):
sudo dnf install openssl-devel sqlite-devel z3-devel
macOS (Homebrew):
brew install openssl sqlite z3
Il repository include alias cargo in .cargo/config.toml che compilano con
--no-default-features, collegandosi a tutte le librerie di sistema:
cargo dev-build # compila senza dipendenze incluse
cargo dev-run -- <args> # esegue senza dipendenze incluse
cargo dev-test # testa senza dipendenze incluse
cargo doc --no-deps per generare la documentazione dai commenti nel codice
sorgente. La pagina principale della documentazione sarà
target/doc/wuppiefuzz/index.html