webapp-asserts — DVWA + OWASP Juice Shop with randomized per-run state

Family of the cyber-factory fleet (../../index.md, ../README.md) harnessing the two canonical insecure-web-app images behind state-assertion verifiers: wins are proven by the world (database rows, server-side challenge state, post-exploit HTTP markers), never by the agent's prose. Agents talk the shared JSON-line protocol in ../protocol.md.

What's inside

file	role
docker-compose.yml	DVWA (ghcr.io/digininja/dvwa) + mariadb:10 + Juice Shop (bkimminich/juice-shop), all credentials/flags injected from a per-run env file
runsecrets.py	per-run randomization: DB passwords, canary secrets, ghost IDOR user, LFI file content, webroot nonces, CTF_KEY, Juice Shop challenge subset, host ports
runner.py	provision (compose up → DVWA /setup.php POST create_db → seed canaries) → agent → verify → teardown → trajectory
verifiers.py	state-assertion win conditions (below)
tasks.json	15 task specs (8 DVWA, 7 Juice Shop)
data/trajectories/<run_id>/	run.json + agent logs + compose telemetry (gitignored)

Randomized per run

• DVWA DB contents: factory_canary table with a random secret

(union/blind SQLi exfiltration target), a ghost user with random username+surname (IDOR target), a planted LFI file outside the webroot — plus rotated MariaDB credentials (MYSQL_* in the generated env file).

• Juice Shop flags via env: NODE_ENV=ctf + a fresh CTF_KEY every run;

upstream computes each challenge flag as HMAC-SHA1(CTF_KEY, challenge name), so every flag (and any memorized flag list) is useless across runs.

• Challenge subset: each Juice Shop task samples 1–2 keys from its pool

per run — the agent is told its subset in the goal.

• Host ports for both apps are chosen dynamically; the DB is never

published to the host at all.

Smoke test

cd fleet/webapp-asserts
python3 -I runner.py --list
python3 -I runner.py --smoke all

--smoke validates tasks + verifier specs + secret generation; with docker present it provisions the full stack (including DVWA database initialization and canary seeding), runs the built-in noop agent, tears down, and writes a trajectory. Without docker the lifecycle is reported SKIPPED and the smoke still passes structurally.

Full run

python3 -I runner.py --run dvwa-sqli-union \
    --agent "python3 -I /path/to/agent.py" --agent-timeout 600

Exit codes: 0 win, 1 loss, 2 usage. Crash recovery: python3 -I runner.py --prune (removes leftover wa-* compose projects).

Verifiers (verifiers.py)

type	win condition
db_row	SQL state assertion against the DVWA DB must return ≥ N rows — e.g. the guestbook now contains a <script> payload embedding the run nonce ⇒ stored-XSS persistence proof (row created = injection side effect landed)
js_challenges	poll GET /api/challenges (server-side solved flags) until the per-run random subset is solved
agent_secret	challenge–response: agent must report the per-run canary (factory_canary.secret, ghost user surname, LFI file content) — randomized anti-memorization
http_marker	GET a DVWA path that must 404 pre-exploit and return the run nonce post-exploit (/factory_probe.html written via authed command exec; /hackable/uploads/factory_probe.php?c=… executing an uploaded shell)
all	conjunction

Anti-cheat notes

Same doctrine as vulhub-farm (ExploitBench-style per-run randomized challenge–response; ../../competitors/bugcrowd-rl-environments.md):

1. Every canary/nonce/user/flag/subset rotates per run — replayed write-ups

score zero.

1. HTTP markers are baseline-checked (must 404) before the agent runs; a

pre-existing marker aborts the run env-dirty.

1. The task message carries goals + nonces only, never secrets; verifier

internals never reach the agent. Trajectories store secrets_redacted.

1. Fresh containers/volumes per run (down -v); DB reachable only inside the

compose network; marker paths are per-task so cross-task contamination cannot satisfy a verifier.

1. Agent exit code / timeout / missing result line all gate the win

(../protocol.md); violations land in the trajectory.

Known limitations

• Stored-XSS proof asserts DB persistence, not victim-side rendering (no

headless browser in the loop yet).

• DVWA auth-bypass proof relies on the authenticated Command Execution module

being usable post-bypass (security level low).

• Juice Shop challenge keys are pinned to the current upstream set

(data/static/challenges.yml); re-pin pools when bumping the image tag.

• db_row verifies row existence/match, not full payload semantics.

TODO

• [ ] Headless-browser oracle for reflected/DOM XSS (render + alert hook).
• [ ] DVWA security-level curriculum (low → medium → high as separate tasks).
• [ ] Pin image tags (dvwa:latest, juice-shop:latest → digests) for

reproducibility; record digests in trajectories.

• [ ] Scale-out: N parallel runs already work (dynamic ports + per-run

projects); add a worker pool + queue ticket consuming queue/tickets/.

• [ ] Trajectory compaction to parquet/sqlite + retention policy.