clickswave/vuln_appsExécute une flotte d'applications web/API volontairement vulnérables dans des stacks Docker isolées pour des tests de pénétration locaux et la validation des résultats de scanners à l'aide de catalogues de vulnérabilités de vérité terrain.
Une flotte d'applications volontairement vulnérables pour servir de cibles aux outils de sécurité (crossfyre, Burp, ZAP, nuclei, etc.). Ce dossier ne contient aucun code source d'application, uniquement des définitions squelettes et un petit gestionnaire. Chaque application tourne dans sa propre pile de conteneurs isolés, donc rien n'entre en conflit.
Tout ici est volontairement vulnérable. Test local uniquement. N'exposez pas ces applications sur Internet ou sur un réseau non fiable. Tous les ports sont liés à
127.0.0.1.
docker compose up démarre un conteneur : vuln_apps_manager (le plan de contrôle). Il ne démarre aucune application vulnérable par lui-même.apps/<name>/ (un manifeste app.yml + un compose.yml) et est exécutée par le gestionnaire comme .docker compose séparé127.0.0.1. Les bases de données et les niveaux internes ne sont jamais liés à l'hôte. Le service web de chaque application rejoint également un réseau partagé vuln-net, afin qu'un scanner exécuté dans un conteneur puisse les atteindre par nom (par ex. http://dvwa) sans aucun port hôte.cd vuln_apps
./vam start --all # ONE command: builds the manager, starts every light app,
# and runs each app's first-time setup automatically
./vam status # what's running + URLs
./vam stop --all # stop everything
Cette unique commande ./vam start --all exécute également la configuration ponctuelle dont chaque application a besoin (création de la base de DVWA, installation de bWAPP, seed de VAmPI), de sorte que chaque application est utilisable dès qu'elle indique running – sans cliquer manuellement sur /setup.php ou /install.php.
Vous voulez que le gestionnaire reste actif comme moniteur d'état en direct ? Lancez docker compose up -d d'abord, puis utilisez ./vam ... comme ci-dessus.
./vam <cmd> n'est qu'un wrapper. Exactement la même chose sans lui :
docker compose run --rm vuln_apps_manager start --all
docker compose run --rm vuln_apps_manager status
| Commande | Ce qu'elle fait |
|---|---|
./vam list | liste toutes les applications, leur état et leur URL |
./vam start <app...> | --all [--heavy] | démarre la ou les applications. --all ignore les applications lourdes sauf avec --heavy |
./vam stop <app...> | --all | arrête la ou les applications |
./vam restart <app...> | --all | redémarre la ou les applications |
./vam status | tableau d'état de la flotte |
./vam logs <app> [-f] | suit les journaux d'une application |
./vam pull <app...> | --all | pré-télécharge les images |
./vam ports | carte des ports hôte + vérification des conflits |
./vam doctor | vérifications de cohérence de l'environnement et des ports |
Exemples : ./vam start juice-shop dvwa, ./vam start crapi --heavy, ./vam logs webgoat -f.
Toutes les URL sont http://127.0.0.1:<port> (boucle locale uniquement).
| Application | Port | Pile | Notes |
|---|---|---|---|
| juice-shop | 7001 | Node / Angular | SPA moderne + REST |
| dvwa | 7002 | PHP / MariaDB | base auto-créée au démarrage ; identifiants admin/password |
| webgoat | 7003 | Java | + WebWolf sur 7004 (récepteur OOB) |
| vampi | 7005 | Python / Flask | OWASP API Top 10 |
| dvga | 7006 | Python / GraphQL | /graphql |
| bwapp | 7007 | PHP | auto-installé au démarrage ; identifiants bee/bug |
| log4shell | 7009 | Java / Spring | RCE aveugle -> OAST |
| crapi | 7010 | Node/Java/Python | lourd ; mailhog sur 7011 |
| faultline | 8088 | SvelteKit/Rust/PG/Redis | récupéré depuis GitHub (voir ci-dessous) |
Bloc de ports hôte réservé : 7001-7099. ./vam ports affiche la carte en direct et signale tout conflit.
Déposez un dossier sous apps/ :
apps/<name>/
app.yml # name, description, category, stack, url
compose.yml # the container(s): image, ports (127.0.0.1 only), any DB
setup.sh # optional: one-time init run after start (see below)
Règles qui maintiennent la flotte propre :
127.0.0.1:<port 70xx libre>.[vuln-net] uniquement. N'ajoutez PAS de réseau par projet – cela préserve le pool d'adresses Docker (trop de réseaux et Docker échoue avec « all predefined address pools have been fully subnetted »).[default, vuln-net] et la base de données sur [default] uniquement (privé, sans liaison hôte). Donnez à chaque application son propre service de base de données et son propre volume (ne les partagez pas). Déclarez vuln-net comme external: true.apps/<name>/setup.sh. Le gestionnaire l'exécute après start, depuis l'intérieur du conteneur du gestionnaire (qui est sur vuln-net et dispose de curl), afin qu'il puisse atteindre l'application par nom de service, par ex. curl http://<service>/install.php.C'est tout. Le gestionnaire le détecte automatiquement (./vam list).
Pour une application dont le code source vit dans un dépôt git (comme faultline), omettez compose.yml et mettez plutôt repo: (l'URL de clonage) et compose: (le chemin compose dans ce dépôt) dans app.yml. Le gestionnaire le clone dans apps/<name>/src/ (gitignoré) au premier démarrage, donc aucun code source n'est vendu ici.
vulns/ contient un « corrigé » par application (à quelles vulnérabilités chaque cible est censée être exposée), afin que vous puissiez confronter les résultats d'un scanner à la vérité terrain. Voir vulns/README.md. Des catalogues locaux détaillés existent pour faultline et crapi ; les applications upstream pointent vers leurs propres corrigés de référence.
crAPI exécute Postgres + Mongo + trois niveaux d'application (~2 Go), donc --all l'ignore. Démarrez-le explicitement : ./vam start crapi --heavy. Le premier démarrage est lent ; l'OTP d'inscription et les e-mails de réinitialisation arrivent dans mailhog sur http://127.0.0.1:7011.
faultline est la cible full-stack de Clickswave. Son code source n'est pas vendu ici ; le gestionnaire le clone depuis github.com/clickswave/faultline au premier démarrage :
./vam start faultline # clones the repo into apps/faultline/src/, then builds + runs it
Le premier démarrage le compile (Rust ; lent). Mettez à jour le checkout plus tard avec ./vam pull faultline. Ouvrez ensuite http://127.0.0.1:8088. Identifiants de démo : [email protected] / password, [email protected] / admin.
docker compose down arrête uniquement le gestionnaire. Arrêtez d'abord les applications avec ./vam stop --all (ce sont des projets séparés).