--- name: webvuln description: Web vulnerability hunting playbook. Use after recon, when you have specific hosts/endpoints to test for IDOR/BAC, injection, auth flaws, SSRF, and known CVEs. Emphasizes real PoC + concrete impact. allowed-tools: - shell - http - web_search - web_fetch - file_write --- # Web vuln hunting playbook You are testing specific endpoints the user has handed you (or that came out of the `recon` skill). Every finding must come with a real PoC and a concrete impact statement — no theoretical bugs. Default to curl and the built-in `http` tool. Do not pull in heavy scanners (nuclei, sqlmap, ffuf, etc.) unless the user explicitly asks for them or you have manually confirmed a bug and need a scanner only to characterize the bug class. Execution rule: substitute real target values before running commands. Never write literal placeholders such as ``, ``, or `` to files. If a value is unknown, ask once or derive it from `/target`. ## 1. Triage the target Fetch the landing page with the `http` tool or curl. Note: - Framework / language signals (cookies, headers, error pages) - Authentication scheme (cookie, Bearer, basic) - API style (REST / GraphQL / gRPC) - Anything that suggests a known CVE family (versioned banner, vendor product name) If you spot a versioned product, immediately `web_search " CVE"` and `web_fetch` the top advisory. Reproduce the CVE manually with curl before reporting. ## 2. Known-CVE pass (manual, curl-driven) For each suspected CVE pulled from the advisory, craft the curl that proves it — single request when possible: ``` TARGET="https://app.example.com" # replace with the scoped target before running curl -ksS -X POST "$TARGET/vulnerable-path" \ -H 'Content-Type: application/json' \ -d '{"replace":"with-real-poc-body"}' \ -w "\nHTTP %{http_code} size=%{size_download} time=%{time_total}\n" ``` If the advisory describes a recognizable pattern (template injection, deserialization, etc.) and the user has explicitly authorized broader scanning, then — and only then — reach for `nuclei` against the single host. Otherwise stay manual. ## 3. Auth + access control (IDOR / BAC) - Identify any numeric or UUID identifiers in the URL path or query (`/api/users/12345`, `/orders/?id=...`). - With user-provided session A, fetch a resource you own. - Swap the identifier to another user's value (or use a second session from the user) and replay with curl or the `http` tool. - A 200 with foreign data = IDOR. Capture the curl one-liner and the response excerpt into `findings/idor-.txt`. Example IDOR sweep with two sessions: ``` TARGET="https://app.example.com" # replace with the scoped target before running for id in $(seq 1 50); do body=$(curl -ksS -H "Cookie: $SESSION_B" "$TARGET/api/users/$id" | jq -r '.email // empty') [ -n "$body" ] && echo "$id $body" done ``` ## 4. Injection surfaces (curl-first) For each parameter (query, body, header, cookie): - Inject simple probes (`'`, `"`, ``, `${7*7}`, `{{7*7}}`) with curl or the `http` tool. - 500s / reflected payloads / arithmetic evaluation → escalate to a targeted PoC. Quick reflected-XSS probe with curl: ``` TARGET="https://app.example.com" # replace with the scoped target before running for p in q s search query keyword; do curl -ksS "$TARGET/?$p=pf$(date +%s)