/web-pentest

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 server-side? (Test by replaying the cookie post-logout.)
• Password reset — token format, expiration, single-use, host-header poisoning (`Host: evil.com` in the reset email link)
• OAuth flow — PKCE used? `state` parameter validated? `redirect_uri` strictly matched (not prefix-matched)?

Phase 4: Authorization (the highest-yield phase)

Goal: access things you shouldn't.

**Horizontal privilege escalation (IDOR / BOLA):**

• Sign in as user A. Get a resource that belongs to user A. Note the ID.
• Sign in as user B. Try to access user A's resource by ID — direct fetch, in the body of an update, as a foreign key in another operation.
• Watch for response codes — 200 (bad), 403 (good), 404 (good if all unauthorized requests return 404; bad if your own 404 looks different)
• Try every endpoint that takes an ID — `GET /users/:id`, `POST /users/:id/...`, `DELETE /users/:id`, `GET /api/users/:id/orders`, GraphQL `user(id: ...)`

**Vertical privilege escalation (BFLA):**

• Identify admin-only routes (from `/admin/*` exploration, from JS bundle strings, from Burp's site map)
• Hit them as a regular user. 403 (good), 200 (very bad)
• Check for verb tampering — `DELETE /admin/users/x` blocked, but `POST /admin/users/x/delete` works
• Mass assignment — registration endpoint that accepts `{ role: "admin" }` because it does `User.create(req.body)` without filtering

**Tenant isolation (multi-tenant SaaS):**

• Create org A with user U1. Create org B with user U2.
• As U1, try every URL that includes the org/tenant ID and swap it to org B's. Expect 403 / 404 on every one. A 200 is a tenancy break.

Phase 5: Session management

• Session token in URL? Anywhere logged → access logs leak it
• Concurrent sessions allowed? Should be configurable / loggable
• Token after password change — invalidated everywhere? (Test by changing password in browser 1 and replaying browser 2's cookie.)
• CSRF protection — synchronizer token, SameSite cookie, custom request header? Test by forging a req