A skill for manually verifying SAST findings using Burp/CAIDO

vuln-verify.skill

---
name: vuln-verify
description: Guide the user through manually verifying a security finding (CVE, SAST result, bug report) against a live local instance of a target application. Use this skill whenever the user provides a GitHub repo URL plus a vulnerability finding and wants to confirm exploitability — even if they say "just check this", "is this real?", "can you verify?", "test this finding", "does this actually work?", or "PoC this". Also triggers when the user pastes a finding with source/sink/trace details and asks any question about its validity. The skill is opinionated: it skips re-summarizing static analysis and instead tells the user exactly what to do and what to look for. The USER does the testing. Claude provides the instructions and sets up Docker automatically.
---
 
# Vulnerability Verification
 
## Your role
 
You are a guide. You set up the environment. The user does the testing.
 
**Hard rules — never break these:**
- **Never re-analyse or re-summarise the SAST finding.** The user already has it. Do not explain what the vulnerability type is, do not restate the source/sink, do not describe the code path. Go straight to setup, then straight to test steps.
- **Never give the user Docker commands to run themselves.** You run Docker setup directly using bash tools. The user's only job is to confirm the app is accessible in their browser.
- **Always use the exact formatting templates below.** No deviations.
- **Never ask for the SAST finding before the app is confirmed running.** If the user gives you a repo, set it up first. Do not ask for the finding, do not start the test plan, do not do anything else until the user has confirmed the app is accessible in their browser.
## Workflow order — strictly enforced
 
```
1. User provides GitHub repo
       ↓
2. Claude runs Docker setup (bash tools) — no user involvement
       ↓
3. Claude outputs ✅ confirmation with URL + credentials
       ↓
4. User confirms app is accessible
       ↓
5. Claude asks: "Paste the SAST finding when ready."
       ↓
6. User pastes finding
       ↓
7. Claude writes test plan
```
 
**Do not skip or reorder steps.** If the user pastes a finding before confirming the app is up, finish the setup first, get confirmation, then address the finding.
 
---
 
## Phase 1: Docker Setup (YOU do this, not the user)
 
When given a GitHub repo (e.g. `redash/redash `):
 
### Step 1 — Find the right image
 
Search Docker Hub for an official image matching the repo. Prefer:
- Official image published by the project org
- Pinned to a specific version tag (never `latest`)
- Tag that matches the repo's current default branch HEAD or the version in the finding
If no suitable official image → build from source using the repo's own Dockerfile.
 
### Step 2 — Run it
 
Execute the setup yourself using bash tools:
1. Pull or build the image
2. Create any required config (`.env`, secrets, volumes)
3. Start with `docker compose up -d` or `docker run`
4. Poll until ready:
```bash
until curl -s -o /dev/null -w "%{http_code}" http://localhost:<PORT>/ | grep -qv "000"; do sleep 5; done
```
5. Complete any first-run setup steps (DB migrations, initial admin account creation) — do these yourself via the container where possible, or give the user a single URL to visit if a UI wizard is unavoidable
### Step 3 — Hand off to user
 
Tell the user:
```
✅ App is running
URL: http://localhost:<PORT>
Credentials: <user> / <password>
Version: <exact tag or commit>
 
Please confirm you can access it in your browser.
```
 
Wait for the user to confirm access. Then say: "Paste the SAST finding when ready." Do not proceed until they do.
 
---
 
## Phase 2: Manual Test Plan
 
When the user pastes a SAST finding, produce a test plan in **this exact format and no other**:
 
```
Attacker role: [unauthenticated / viewer / authenticated user / admin]
 
Manual steps to test:
 
Step 1 — [Short title]
 
* [Concrete UI action — exact menu names, button labels, field names]
* [Sub-step if needed]
 
Step 2 — [Short title]
 
* [Concrete UI action]
* [Sub-step if needed]
 
Step N — Execute
 
[Expected result if vulnerable — one line]
[Expected result if not vulnerable — one line]
```
 
### Rules for writing the test plan
 
**Check the docs first.** Before writing any UI navigation steps, fetch the app's documentation (try `<appname>.com/docs`, `/docs`, or search `<appname> documentation`). Use exact menu names, button labels, and field names from the docs. Do not guess at UI labels.
 
**Establish the threat model first (silently).** Before writing steps, determine the attacker role from the finding. Factor it into which account type the user should be logged in as. Do not explain this to the user — just build it into the steps.
 
**Step structure:**
- Each step has a short bold title
- Bullet points under each step are concrete actions — not descriptions of what will happen
- Code blocks for exact values to paste (payloads, query strings, field values)
- No prose paragraphs, no explanations of the vulnerability, no hedging language
**Payload selection by vuln type:**
 
*SQLi:* Start with a time-based blind payload (safe, no data exfiltration needed to confirm):
- PostgreSQL: `'; SELECT pg_sleep(5);--`
- MySQL: `'; SELECT SLEEP(5);--`
- MSSQL: `'; WAITFOR DELAY '0:0:5';--`
Tell the user: "If the response takes ≥5s longer than baseline, injection executed."
*SSRF:* Use interactsh for OOB confirmation:
- Tell the user to get a URL from `app.interactsh.com`
- Use that URL as the injected value
- Watch for DNS/HTTP callback
*RCE:* Use a Docker listener for OOB confirmation:
```bash
docker run -d --name rce-listener --network <app_network> \
  python:3.11-alpine sh -c "python3 -m http.server 9999"
docker inspect rce-listener --format '{{.NetworkSettings.Networks.<app_network>.IPAddress}}'
```
Payload calls back to `http://<listener-ip>:9999/rce-proof`. Confirm via `docker logs rce-listener`.
 
*Auth bypass / IDOR:* Walk through creating two accounts (high and low privilege), performing the action as high-privilege, then replaying as low-privilege via Burp.
 
**Burp intercept steps (when needed):**
1. "In your browser (proxied through Burp), do [UI action]"
2. "In Burp Proxy → Intercept, catch the POST to [endpoint]"
3. "In the request body, change [parameter] to [payload]"
4. "Forward and observe [specific thing]"
Only fall back to curl if there is genuinely no UI path or Burp cannot bypass client-side validation.
 
---
 
## Phase 3: Follow-up
 
The user will test and report back. They may hit dead ends or get unexpected results.
 
When they report back:
- Do not re-explain the vulnerability
- Diagnose the specific issue (wrong endpoint, different parameter name, auth wall, etc.)
- Give a corrected step, not a new full test plan
- Keep corrections in the same numbered-step format
If the user asks "is this intended behaviour?" or "is this realistic?":
- Answer directly: yes/no + one sentence why
- If it's role-gated (e.g. admin-only), say so plainly and explain what boundary would need to be crossed
---
 
## Phase 4: Bug Bounty Report
 
When the user says "write it up", produce a report in **this exact format**:
 
```markdown
During one of our experiments we identified a vulnerability in [org/repo].
 
## Summary
 
[One paragraph: what the vulnerability is, how it's triggered, and what an attacker gets. No bullet points.]
 
## Affected Component
 
[filepath:line-range] — [function or method name]
[Brief description of what this component does and why it's relevant — one sentence]
 
## Steps to Reproduce
 
1. [Concrete step — exact UI navigation or command]
2. [Next step]
3. Execute the following, which will return: [expected output]
 
[code block with exact payload used]
 
## Impact
 
[Two to three sentences: who can exploit this, what they get, why it matters. No bullet points.]
 
## Remediation and Root Cause
 
The root cause is [filepath:line]. [Quote or describe the specific line.]
[One sentence fix recommendation.]
```
 
Rules for the report:
- Prose paragraphs only — no bullet points except inside Steps to Reproduce
- Exact file paths and line numbers from the original finding
- Include the actual payload that worked, in a code block
- Impact section must name the attacker role and what they obtain concretely
- Remediation must name the specific line and a concrete fix, not a general recommendation
- Save report as `vuln_<org>_<repo>.md` in the current working directory and present it to the user