web-pentest skill

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:

pre-declared. Off-scope hosts are refused.

1. No exploit, no report — every finding requires reproducible evidence.
2. Bounded scope — every active request goes against a target the operator

is not a clean bill of health until you've tried the bypass set.

1. Bypass exhaustion before false-positive dismissal — a "blocked" payload

⚠️ Hard Guardrails — Read Before Every Engagement

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

MUST confirm with the user, in writing, that they own or have written authorization to test the target. Record the acknowledgement in engagement/authorization.md (see template). No acknowledgement → no active scanning. Reading public pages with curl is fine; sending payloads is not.

1. Authorization gate. Before the first active scan in a session, you

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.

1. Scope allowlist. Maintain engagement/scope.txt — one hostname or

"yes, prod is in scope and I have written sign-off," assume not. Default targets are staging, local docker, dedicated test instances.

1. No production systems without paper. If the user hasn't told you

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. The agent's browser tool can reach these from inside your own infrastructure — don't.

1. Cloud metadata is off by default. Do not probe 169.254.169.254,

filesystem-write SSTI, command injection with rm/shutdown/mkfs, anything that mutates beyond a single test row → ASK FIRST. The approval.py system catches some; don't rely on it alone.

1. Destructive payloads need approval. SQLi payloads that DROP/DELETE,

sessions full of SQLi/XSS/RCE payloads, captured credentials, JWT tokens. Hermes' compression and title-generation paths replay history through the auxiliary client (often the main model). Anything sensitive you write to the conversation can leave the box on the next compress. Mitigation:

1. Aux-client leakage risk (Hermes-specific). This skill produces

them in any message. Full values go to engagement/evidence/ files, never into chat history.

• Redact captured tokens/credentials to the LAST 6 CHARS before logging

in ~/.hermes/config.yaml for the session.

• If the engagement is sensitive, set auxiliary.title_generation.enabled: false

any single host. The recon-scan.sh script enforces this. Don't bypass it without operator approval.

1. Rate limit yourself. Default 200ms between active requests against

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.

1. Authority of the report. This skill produces a security

Phase 0: Engagement Setup

Before any scanning happens, create the engagement directory and authorization acknowledgement.

ENGAGEMENT=engagement-$(date +%Y%m%d-%H%M%S)
mkdir -p "$ENGAGEMENT"/{evidence,findings,reports}
cd "$ENGAGEMENT"

1. Ask the user (verbatim):

"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."

1. Wait for explicit authorized response. Any other answer means STOP.

template in templates/authorization.md. Include:

1. Record authorization to engagement/authorization.md using the

• 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)

1. Build scope.txt:

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

active request — that doc has the host-extraction rules you apply to every command/URL before it goes out.

1. Read references/scope-enforcement.md before issuing the first

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

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

If you have read access to the application source:

template render, file read/write, redirect target

1. Map the architecture — framework, routing, middleware stack
2. Inventory sinks — every execute(, os.system(, eval(,

privileged endpoints

1. Map auth — session cookie vs JWT, OAuth flows, password reset,

what comes from request.*

1. Identify trust boundaries — what's authenticated, what's not,

when proper sanitization is found (parameterized queries, allowlists, shlex.quote, well-known escapers).

1. Backward taint from each sink to a request source. Early-terminate

Output: 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.

in scope (avoids the "DNS points somewhere unexpected" trap).