run-dvwa

name	run-dvwa
description	Run the full Clinkz pipeline against DVWA and report vulnerability coverage across the 14 categories.

Apply phase-work skill.

1. Verify DVWA is running at http://localhost:8080 (check via curl or docker compose ps). If not running: docker compose -f docker/docker-compose.yml up -d dvwa
   • The target is the modern ghcr.io/digininja/dvwa image (built via docker/Dockerfile.dvwa), which — unlike the frozen vulnerables/web-dvwa — ships the open_redirect / authbypass / cryptography modules. It needs an external MariaDB (the dvwa-db compose service, auto-started via depends_on) and runs at security=low by default (DEFAULT_SECURITY_LEVEL).
   • The clinkz-dvwa entrypoint (docker/dvwa-init.sh) auto-creates the DVWA tables on startup (GET setup.php for a CSRF token → POST create_db once Apache + DB are up), so a fresh container is login-ready with admin/password. The Dockerfile also makes the PHP session cookie host-only (DVWA otherwise scopes it to domain=localhost, a dotless host Python's cookie jar refuses to send back — which silently breaks the engagement authenticator). Without these, login silently fails and every crawl sees only login.php.
   • If you ever see login failing (modules 302 back to login.php), force a clean rebuild: docker compose -f docker/docker-compose.yml up -d --build --force-recreate dvwa.
2. The orchestrator handles clinkz-tools container readiness via its preflight. Invoke: python -m clinkz scan --target http://localhost:8080 --authorization <auth.json>
   • The authorization record is required — open_engagement is the first statement of OrchestratorAgent.run() and refuses without one, by design and with no flag to skip it. A bare --target run exits with "Refusing to start: this engagement has no authorization record." Write a small JSON file carrying authorizing_party, authorizing_role, authorizing_contact, authorization_reference, permitted_techniques (["*"]), and emergency_contact — you own the local container, so you are the authorizing party. Keep it OUT of the repo (outputs/ is local-only by policy; a scratch dir is fine).
   • P7 needs the tools image to actually carry Chromium. The oracle runs container-side in docker tool-mode, so a clinkz-tools image built before the Playwright layer confirms nothing and logs "no available tool provides 'client_side_execution'". Rebuild once: docker compose -f docker/docker-compose.yml build tools && docker compose -f docker/docker-compose.yml up -d --force-recreate tools.
3. Parse the JSON report from outputs/
4. Report coverage as X/14 with a breakdown table across: SQL Injection, XSS Reflected, XSS Stored, Command Injection, File Inclusion, File Upload, CSRF, Brute Force, Weak Session IDs, DOM XSS, JavaScript Attacks, Authorization Bypass, Open HTTP Redirect, CSP Bypass.
5. Include: total findings, by severity, engagement ID, runtime.
6. If coverage < target, briefly note which categories were missed and why (single-line each).
7. NoSQL Injection (_test_nosqli, a Tier-1 primitive beyond the 14 categories — see docs/ROADMAP.md) is N/A on DVWA (PHP/MySQL, no NoSQL backend): expect zero nosqli findings. The methodology emits only on a real NoSQL signal (operator match-set widening or a $where channel) and rejects SQL errors, so a nosqli finding here is a regression, not a catch.
8. XXE (_test_xxe, a Tier-1 primitive beyond the 14 categories — see docs/ROADMAP.md) is N/A on DVWA (no endpoint parses an XML request body; the upload handler rejects non-images without parsing XML): expect zero xxe findings. Phase-1 candidacy requires the endpoint to actually parse XML (entity expansion / XML parse-error / malformed-vs-well-formed divergence), so an xxe finding here is a regression, not a catch.
9. SSTI (_test_ssti, a Tier-1 primitive beyond the 14 categories — see docs/ROADMAP.md) is N/A on DVWA (no server-side template engine evaluates user input): expect zero ssti findings. Phase-1 candidacy requires a polyglot arithmetic probe to actually evaluate (the product rendered, the literal wrapper not reflected verbatim), so DVWA's literal reflection is correctly a non-finding — an ssti finding here is a regression, not a catch.
10. JWT attacks (_test_jwt, the first Tier-2 primitive beyond the 14 categories — see docs/ROADMAP.md) are N/A on DVWA (PHP session cookies, no JWT): expect zero jwt findings. DVWA holds no bearer JWT and its endpoints issue none, so phase-1 acquisition finds no candidate token and nothing emits — a jwt finding here is a regression, not a catch.
11. Open HTTP Redirect (_test_open_redirect) is APPLICABLE on DVWA and confirmed live. The redirect handler lives at /vulnerabilities/open_redirect/source/<level>.php?redirect= — the level is in the path (the index just links to the security-appropriate one), so the methodology confirms each level's ground-truth bypass: Low (any absolute off-site URL), Medium (protocol-relative //evil, absolute http(s):// blocked), High (substring-allowlist bypass — an attacker URL containing info.php, e.g. https://evil.example/?x=info.php; the token is recovered from the param's own ?redirect=info.php value), Impossible (numeric-ID only → justified non-finding). Confirmation is browser-faithful host resolution (the redirect must navigate off-site to the attacker host; a same-host path that merely contains the attacker string is a non-finding, never a phantom). All four levels are proven by the parametrized live smoke (tests/test_skills_dvwa/test_skills.py::test_open_redirect_against_dvwa[low|medium|high|impossible]). In a full run the crawler discovers source/low.php (the index links the low handler at security=low), so expect open-redirect to confirm at Low; if it shows empty, check the trace for open_redirect/source/low.php?redirect= reaching planning before reporting it as missed.
12. Authorization Bypass is present at /vulnerabilities/authbypass/ but is a flagged methodology gap, not currently confirmed. DVWA's authbypass is function-level access control — a low-priv user invoking the admin-only AJAX endpoints (get_user_data.php / change_user_details.php) that omit an authorization check — NOT an index-page ?id= object-reference IDOR. Clinkz authenticates as admin (no privilege boundary to cross) and _test_idor models object-reference IDOR, so it cannot confirm this module; the smoke test is an honest xfail documenting the gap. Report it as a justified non-finding (methodology gap), not a catch — confirming it needs a function-level-access-control methodology with a second low-priv session (follow-up).
13. Cryptography (/vulnerabilities/cryptography/) and API (/vulnerabilities/api/) ship in this image but are outside the 14-category scope — Clinkz has no methodology for them, so they are neither counted in X/14 nor a mis-mark; documented capability gaps (ROADMAP candidates). Likewise the Insecure CAPTCHA module is out of scope.

Do NOT fix issues found during the run. Measurement only unless the user asks for fixes.