
Un fuzzer de API REST guiado por cobertura desarrollado sobre LibAFL
TNO desarrolló WuppieFuzz, un fuzzer de API REST guiado por cobertura desarrollado sobre LibAFL, dirigido a un amplio público de usuarios finales, con un fuerte enfoque en la facilidad de uso, la explicabilidad de los fallos descubiertos y la modularidad. WuppieFuzz admite las tres modalidades de pruebas (caja negra, caja gris y caja blanca).
[!NOTE]
Para una guía rápida y práctica, sigue el tutorial.
WuppieFuzz ha aparecido en:
Si quieres citar WuppieFuzz en trabajos académicos, utiliza la publicación preferida indicada en 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 tiene licencia Apache-2.0; consulta LICENSE.
Los avisos de licencia de terceros se enumeran en THIRD_PARTY_NOTICES.
Para una instalación rápida de WuppieFuzz en los sistemas operativos más populares (MacOS, Windows, Linux), consulta releases o usa brew install wuppiefuzz
Para compilar el proyecto necesitas instalar las siguientes dependencias y herramientas
sudo apt install build-essentialsudo apt install pkg-configcurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shAntes de ejecutar WuppieFuzz, debes iniciar tu aplicación objetivo (instrumentada).
Además, debes proporcionar a WuppieFuzz una especificación OpenAPI para que sepa cómo generar y mutar sus solicitudes. Para obtener ayuda sobre los argumentos de la línea de comandos, usa lo siguiente:
$ cargo run -- --help # shows help for required parameters and flags
Usage: wuppiefuzz [OPTIONS] [OPENAPI_SPEC.YAML]
...
Por ejemplo, para ejecutar WuppieFuzz contra un objetivo Java con el agente JaCoCo adjunto, especifica su archivo OpenAPI (que contiene la URL en la que se ejecuta el objetivo dentro de la especificación de la API). Además, indica que el formato de cobertura es JaCoCo y proporciona el directorio de clases de la siguiente manera:
cargo run -- fuzz openapi.yaml --coverage-format jacoco --jacoco-class-dir ../Targets/app/target/classes/
Si quieres usar un archivo de configuración en lugar de los argumentos de línea de comandos, o en combinación con ellos, puedes usar la opción --config <CONFIG_FILE>. Si usas argumentos de línea de comandos junto con un archivo de configuración, los argumentos de línea de comandos tienen prioridad.
El archivo de configuración debe ser un archivo YAML y contener una línea por cada argumento de línea de comandos que quieras especificar, por ejemplo:
coverage_format: jacoco
output_format: human-readable
source_dir: "/swagger-petstore/src/main/java"
jacoco_class_dir: "/swagger-petstore/target"
timeout: 20
Un ejemplo de comando de ejecución en este caso podría ser:
$ cargo run -- fuzz --config=config.yaml --report --coverage-host=localhost:6300 --timeout=10 ./openapi.yaml
Esta línea combinaría los argumentos de la línea de comandos y los del archivo de configuración. Dado que la opción --timeout está especificada en ambos, el tiempo de espera indicado en la línea de comandos (10 segundos) tendrá prioridad.
En el directorio example_configs/ encontrarás dos archivos de configuración de ejemplo para generar informes de cobertura con JaCoCo para código Java y para generar informes de cobertura con LCOV para código Python.
Cuando ejecutas WuppieFuzz con la opción --report, se crea un subdirectorio dentro de reports/ cuyo nombre es una marca de tiempo. Todos los informes de cobertura compatibles se escriben en este subdirectorio. Hay dos tipos de informes de cobertura:
Además, se rellena una base de datos con toda la información de solicitudes relacionada con tu campaña de fuzzing. Esta base de datos se puede visualizar y explorar mediante el panel de Grafana.
Para obtener más información sobre cada uno de ellos, consulta los README en esos directorios.
De forma predeterminada, WuppieFuzz incluye sus dependencias C (OpenSSL, SQLite, Z3) para que un cargo build normal funcione directamente. Para una compilación más rápida durante el desarrollo, puedes deshabilitar todas las dependencias incluidas y enlazar contra las bibliotecas instaladas en el sistema.
[!NOTE] El crate
z3requiere Z3 4.15+, que es más reciente que la versión distribuida por la mayoría de los gestores de paquetes de las distribuciones Linux. Instala Z3 mediante Homebrew (brew install z3) para obtener una versión compatible.
Instala las siguientes bibliotecas en tu sistema:
Debian/Ubuntu:
sudo apt install libssl-dev libsqlite3-dev
brew install z3 # apt's libz3-dev is too old; use Homebrew instead
En Linux, Homebrew se instala en una ruta no estándar. Añade su directorio de bibliotecas a tu entorno para que el compilador y el enlazador en tiempo de ejecución puedan encontrar 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] Añade las líneas anteriores a tu
~/.bashrco~/.zshrcpara que sean permanentes.
Fedora (42+):
sudo dnf install openssl-devel sqlite-devel z3-devel
macOS (Homebrew):
brew install openssl sqlite z3
El repositorio incluye alias de cargo en .cargo/config.toml que compilan con --no-default-features, enlazando contra todas las bibliotecas del sistema:
cargo dev-build # build without vendored dependencies
cargo dev-run -- <args> # run without vendored dependencies
cargo dev-test # test without vendored dependencies
Ejecuta cargo doc --no-deps para generar documentación a partir de los comentarios del código fuente. La página principal de la documentación será target/doc/wuppiefuzz/index.html.