Web Application Penetration Testing

A phased pentesting workflow for running web applications. Adapted from Shannon's pipeline (Keygraph, AGPL — concepts only, no code borrowed), built around three rules:

1. Every confirmed finding requires evidence. Report unverified candidates and blocked checks separately.
2. Bounded scope — every active request goes against a target the operator pre-declared. Off-scope hosts are refused.
3. A blocked test is not a clean bill of health. Stay within approved methods; do not expand exploitation to force a finding.

This skill is for authorized testing only — applications you own or have explicit written authorization to test. It complements, but does not replace, professional penetration testing.

🛑 STOP — do these three things before ANY scan

Do not skim past this. If you skip any of these, stop.

1. Get authorization in writing. Ask the user to confirm they own or are authorized to test the exact target URL, and wait for an explicit "authorized" reply. No reply → no active scanning.
2. Write the scope allowlist. Put every in-scope hostname/CIDR in ./pentest-engagement/scope.txt. Anything not listed is off-limits.
3. Only send payloads to in-scope hosts, and never destructive ones without asking. Read-only curl of a public page is fine; sending a payload, following an off-scope redirect, or probing cloud metadata is not.

Before using recon, record Authorization status: authorized in authorization.md only after the user's acknowledgement. Recon writes a unique evidence subdirectory and preserves prior scans. The wrapper skips whatweb because automatic redirects are not scope-enforced. A browser must enforce the allowlist on every request, including subresources and redirects, or browser recon is blocked. The shared QA driver alone does not provide that control. Hostname/CIDR checks do not prove DNS rebinding resistance; require an enforcing network boundary for that threat.

The full rules are below. These three are the ones that keep the engagement legal.

⚠️ Hard Guardrails — Read Before Every Engagement

Violating any of these invalidates the engagement and may be illegal.

1. Authorization gate. Before the first active scan in a session, you MUST confirm with the user, in writing, that they own or have written authorization to test the target. Record the acknowledgement in ./pentest-engagement/authorization.md (see templates/authorization.md). No acknowledgement → no active scanning. Reading public pages with curl is fine; sending payloads is not.
2. Scope allowlist. Maintain ./pentest-engagement/scope.txt — one hostname or CIDR per line. Every nmap, curl, whatweb, browser navigation, or payload-bearing request MUST be against an entry in scope. If a target redirects you off-scope (3xx to a different host, a link in HTML), STOP and confirm with the user before following.
3. No production systems without paper. If the user hasn't told you "yes, prod is in scope and I have written sign-off," assume not. Default targets are staging, local docker, dedicated test instances.
4. Cloud metadata is off by default. Do not probe 169.254.169.254, metadata.google.internal, 100.100.100.200, [fd00:ec2::254], or equivalent unless the engagement explicitly includes SSRF-to-metadata as a goal AND the target is one you control.
5. Destructive payloads need approval. SQLi payloads that DROP/DELETE, filesystem-write SSTI, command injection with rm/shutdown/mkfs, anything that mutates beyond a single test row → ASK FIRST.
6. Sensitive-data handling. This skill produces sessions full of SQLi/XSS/RCE payloads, captured credentials, JWT tokens. Some harnesses compress or replay older conversation context — anything sensitive written into chat can get replayed through that summarization step. Mitigation:
   • Redact captured tokens/credentials to the LAST 6 CHARS before mentioning them in any message. Full values go to ./pentest-engagement/evidence/ files, never into chat history.
   • Prefer writing raw payloads/responses to evidence files and referencing the file path in chat, rather than pasting the full request/response inline.
7. Rate limit yourself. Default 200ms between active requests against any single host. scripts/recon-scan.sh enforces this for recon. Don't bypass it without operator approval.
8. Authority of the report. This skill produces a security assessment, not a "PASS." Even a clean run is "no exploitable issues FOUND in scope X within time T using methods Y" — not "the application is secure." Mirror that language in the report.

Phase 0: Engagement Setup

Paths & shell state (READ THIS FIRST)

Each shell command may run in a fresh shell, so shell variables do not carry over between calls. This skill handles that as follows:

• The engagement directory is a fixed relative path: ./pentest-engagement. The working directory (the target project's root) is stable between calls, so that same relative path always resolves to the same place. Every path in this skill is written ./pentest-engagement/.... Do not cd into it — that would break the relative paths. (If you want to keep a history, rename the directory after the engagement finishes.)

• Two absolute paths must be pasted literally into commands (they live outside the target project, so no relative path or git rev-parse finds them — git rev-parse would return the target project's root):

  • SKILLDIR = this web-pentest skill's own directory (holds scripts/, references/, templates/).
  • DGF = the sibling dogfood skill's browser driver.

  Find both once, note them, and substitute the literal absolute paths wherever a command sets SKILLDIR= or DGF=:

  for d in "$HOME/.pi/agent/skills/web-pentest" "$HOME/.agents/skills/web-pentest" ".pi/skills/web-pentest" ".agents/skills/web-pentest" ./web-pentest ./web-pentest; do
    [ -f "$d/scripts/recon-scan.sh" ] && printf 'SKILLDIR=%s\n' "$(cd "$d" && pwd)" && break
  done
  for d in "$HOME/.pi/agent/skills/dogfood" "$HOME/.agents/skills/dogfood" ".pi/skills/dogfood" ".agents/skills/dogfood" ./dogfood; do
    [ -f "$d/scripts/browser-driver.mjs" ] && printf 'DGF=%s/scripts/browser-driver.mjs\n' "$(cd "$d" && pwd)" && break
  done

  If the DGF line doesn't print, install the sibling dogfood skill first (see dogfood/SKILL.md). Prose references below like "read <SKILLDIR>/references/vuln-taxonomy.md" mean: open that file (Read tool) using the SKILLDIR path you just found.

Create the engagement directory:

mkdir -p ./pentest-engagement/{evidence,findings,reports}

1. Ask the user (verbatim), in chat — wait for the reply before scanning:

   "Confirm: (a) the target URL is [X], (b) you own this application or have written authorization to test it, and (c) the engagement may run for up to [N] hours starting now. Reply 'authorized' to proceed."

2. Wait for explicit authorized response. Any other answer means STOP.
3. Record authorization to ./pentest-engagement/authorization.md using the template in templates/authorization.md. Include:
   • Target URL(s) and IP(s)
   • Authorization basis (ownership / written authz from $name)
   • Engagement window
   • Out-of-scope items (production, third-party services, etc.)
   • Operator name (the user driving this session)
4. Build ./pentest-engagement/scope.txt:

   localhost
   127.0.0.1
   staging.example.com
   192.168.1.0/24    # internal lab only, with operator OK

5. Read references/scope-enforcement.md before issuing the first active request — that doc has the host-extraction rules you apply to every command/URL before it goes out.

Phase 1: Pre-Recon (Code Analysis, optional)

Skip if no source access (black-box engagement).

If you have read access to the application source:

1. Map the architecture — framework, routing, middleware stack
2. Inventory sinks — every execute(, os.system(, eval(, template render, file read/write, redirect target
3. Map auth — session cookie vs JWT, OAuth flows, password reset, privileged endpoints
4. Identify trust boundaries — what's authenticated, what's not, what comes from request input
5. Backward taint from each sink to a request source. Early-terminate when proper sanitization is found (parameterized queries, allowlists, shlex.quote, well-known escapers).

Output: ./pentest-engagement/evidence/pre-recon.md — architecture map, sink inventory, suspected vulnerable code paths.

This is OFFLINE work. No traffic to the target.

Phase 2: Recon (Live, Read-Only)

Maps the attack surface. All requests are GETs of public pages, no payloads yet. Still scope-bounded.

1. Verify scope. Resolve every target hostname → IP. Confirm IPs are in scope (avoids the "DNS points somewhere unexpected" trap).
2. Network surface + tech fingerprint + robots/sitemap — use the bundled wrapper, which enforces scope and rate limits automatically. Set SKILLDIR to the real path (from "Paths & shell state"):

   SKILLDIR="/absolute/.../web-pentest"
   bash "$SKILLDIR/scripts/recon-scan.sh" ./pentest-engagement https://staging.example.com

   This writes nmap.txt, whatweb.txt, headers.txt, and robots.txt/sitemap.xml/.well-known probes into ./pentest-engagement/evidence/.
3. Endpoint discovery via browser is conditional. Verify that the available browser/network boundary enforces scope on every request, including redirects and subresources. The bundled dogfood driver does not enforce that boundary. If enforcement is unavailable, mark browser recon blocked and use scoped non-redirecting HTTP observations. Do not present checking only the navigation URL as complete scope enforcement.
4. Auth surface: Identify login, registration, password reset, session cookie names, token formats. Do NOT send credentials yet — just observe.
5. Correlate with pre-recon (if you have source). For each ./pentest-engagement/evidence/pre-recon.md finding, mark whether the live surface confirms it's reachable.

Output: ./pentest-engagement/evidence/recon.md — endpoints, technologies, auth model, input vectors.

Phase 3: Vulnerability Analysis

For each vulnerability class below, work through it directly. If your harness supports subagent delegation, you may instead dispatch a focused subagent per class (useful when several classes apply — they can run in parallel); if it doesn't, just do each class as its own focused pass. Give each subagent (or pass) the engagement directory path (./pentest-engagement) so it can read ./pentest-engagement/evidence/recon.md (+ ./pentest-engagement/evidence/pre-recon.md if present) itself, rather than inlining that content into the prompt. Each produces ./pentest-engagement/findings/<class>-queue.json using templates/exploitation-queue.json.

Each queue entry has: id, vuln class, source (file:line if known), endpoint, parameter, slot type, suspected defense, verdict (identified / partial / confirmed / critical), witness payload, confidence (0-1), notes.

The analysis phase doesn't send malicious payloads yet — it stages them. The exploitation phase actually fires them.

Phase 4: Exploitation (Proof-Based, Conditional)

Only proceed per class where the analysis queue has actionable entries (identified or partial) — one class at a time (or via parallel subagents if your harness supports delegation).

For each candidate:

1. Pre-send check — host in scope? auth gate satisfied? payload approved if destructive?
2. Send the witness payload — minimal proof. SQLi: ' AND 1=1-- then ' AND 1=2--. XSS: a benign marker like <svg/onload=console.log("PENTEST-XSS")>. Never alert(1) in stored XSS — it'll fire for other users in shared environments.
3. Verify the witness fires — for blind injection, use a sleep probe (SLEEP(5)) and time the response. For SSRF, use a tester-controlled callback host you own (NOT a public service like webhook.site for sensitive engagements — exfil paths).
4. Promote level:
   • L1 Identified — pattern matched, no behavior change
   • L2 Partial — sink reached, but defense in place
   • L3 Confirmed — payload changed app behavior in observable way
   • L4 Critical — data extracted, code executed, access escalated
5. Bypass exhaustion before classifying as FP. For each candidate that blocks: try at least the bypass set in references/bypass-techniques.md for that class. Only after the set is exhausted may you write verdict: false_positive.
6. Record evidence for every L3/L4:
   • Full request (method, URL, headers, body)
   • Response (status, headers, relevant body excerpt)
   • Reproducer command (curl one-liner)
   • Impact statement

Output: ./pentest-engagement/findings/exploitation-evidence.md

Redact in evidence files:

• Any captured credentials/tokens → last 6 chars only in chat; full value to ./pentest-engagement/findings/secrets-vault.md (gitignore this).
• Other users' PII → redact.
• Your test credentials → fine to keep.

Phase 5: Reporting

Generate the final report using templates/pentest-report.md. Sections:

1. Executive summary
2. Engagement scope (from ./pentest-engagement/scope.txt)
3. Authorization (from ./pentest-engagement/authorization.md)
4. Findings (L3/L4 only — proof-required). Per finding:
   • Title, severity (CVSS 3.1), CWE
   • Affected endpoint(s)
   • Proof (request + response excerpt)
   • Reproduction steps
   • Impact
   • Remediation
5. Not-exploited candidates (L1/L2 with notes on what blocked them)
6. Out-of-scope observations
7. Methodology / tools used
8. Limitations and what was NOT tested

Severity policy: CVSS only for L3/L4. L1/L2 are "candidates pending verification" — don't assign CVSS to unverified findings.

Close only browser processes and contexts owned by this engagement, if any.

When to Stop

• The user revokes authorization.
• A candidate finding clearly impacts production data and you don't have approval for destructive testing — STOP and ask.
• The target starts returning 503/429 storms — back off, reconvene with the operator.
• You discover something outside the contracted scope (e.g. an exposed customer database while testing an unrelated endpoint). STOP, document, report to the operator. Do not pivot without explicit approval — that pivot is what makes pentesting illegal.

What This Skill Does NOT Cover

• Network-layer pentesting beyond port scanning (no Metasploit, Cobalt Strike, AD attacks, network protocol fuzzing).
• Reverse engineering / binary analysis.
• Active social engineering / phishing.
• Anything against systems the operator hasn't pre-authorized.

If the engagement needs any of these, escalate to a professional pentester. This skill complements professional pentesting; it does not replace it.

Further Reading

• references/scope-enforcement.md — how to bound every active request
• references/vuln-taxonomy.md — slot types, render contexts, OWASP map
• references/exploitation-techniques.md — per-class payload patterns
• references/bypass-techniques.md — common WAF/filter bypasses
• templates/authorization.md — engagement authorization template
• templates/pentest-report.md — final report template
• templates/exploitation-queue.json — per-class finding queue schema
• scripts/recon-scan.sh — rate-limited scoped nmap/headers wrapper; whatweb is skipped