web-pentest

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: web-pentest
description: "Perform black-box / grey-box web application penetration testing on an authorized target — auth bypass, IDOR, session handling, business-logic flaws, parameter tampering, Burp Suite / OWASP ZAP workflows. Use when the user mentions 'web pentest,' 'web application penetration test,' 'pentesting,' 'bug bounty,' 'Burp Suite,' 'ZAP,' 'OWASP testing,' 'authentication testing,' 'session testing,' 'authorization testing,' 'business logic testing,' 'web vulnerability testing,' or has explicit authorization to test a live web application."
allowed-tools: Bash, Read, Write, WebFetch, WebSearch
---

# Web Pentest — Live Web Application Testing

Structured black-box / grey-box penetration testing of a live web application against an authorized target. Pairs with `recon` (which maps the surface) and complements `owasp-audit` (which reads the source). Use `recon` first; use this once you have a target list and credentials (or guest access).

## Authorization Check

Before touching the target, confirm:
1. Written authorization for this specific application (pentest engagement, bug bounty in-scope domain, CTF/lab, your own asset)
2. The application is currently in scope and live (not deprecated, not under maintenance freeze)
3. Test credentials provided (if grey-box), or guest access confirmed (if black-box)
4. Out-of-scope items documented — production user data, payment flows, social engineering, DoS

If anything is unclear, ask before proceeding. Never assume authorization.

## Methodology

Follows the OWASP Web Security Testing Guide (WSTG) structure. Each phase produces evidence; document everything as you go.

### Phase 1: Configuration & deployment

Goal: understand what's running and how it's exposed.

- HTTP headers — pull with `curl -I` and `curl -I -H "Origin: https://evil.com"`:
  - `Server`, `X-Powered-By` revealing stack
  - HSTS, CSP, X-Frame-Options, X-Content-Type-Options presence and values
  - CORS — `Access-Control-Allow-Origin` reflection without an allow-list, `Allow-Credentials: true` paired with `*`
- TLS — `testssl.sh https://target` or `sslyze --regular target`
- Backups / configs exposed — `/.git/`, `/.env`, `/backup.sql`, `/web.config`, `/server-status`, `/.aws/credentials`
- Default admin paths — `/admin`, `/administrator`, `/manage`, `/console`, `/actuator/`, `/_debug/`, `/swagger`, `/graphql`, `/.well-known/`
- Robots.txt and sitemap.xml — often list non-indexed but accessible endpoints
- Subdomain & host header testing — does the app behave differently when sent `Host: internal.target.com`?

### Phase 2: Identity management

Goal: understand who can be created, how, and with what privileges.

- Registration — can you self-register? Does the role default to anything other than "user"?
- Username enumeration via differential responses on signup ("email already exists"), login ("user not found" vs "wrong password"), password reset ("we sent an email" vs "no such user")
- Account provisioning — does a verification email arrive? Can it be skipped? Does the reset link expire? Does the reset link tie to the original session?
- Account lockout vs rate-limit — does 100 failed logins lock the account (denial of service vector) or just slow down (good)?

### Phase 3: Authentication

Goal: break in as someone you shouldn't be.

- Login form — is HTTPS enforced? Are credentials sent in URL params (logged everywhere)?
- Password policy — minimum length / complexity / breach-database check (haveibeenpwned API)
- MFA — required for admin / privileged users? Bypass paths (recovery code, "remember this device" cookie persistence, downgrade to SMS)?
- Session token — entropy looks high? Cookie has `HttpOnly`, `Secure`, `SameSite=Lax` or `Strict`?
- Session fixation — does the session ID rotate on login? Pre-auth session ID still valid post-auth?
- "Remember me" — long-lived token in a separate cookie; revocable on logout from all devices?
- Logout — does it actually invalidate the session serve