web-pentest — скилл для Claude Code: пентест веб-приложений

---
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 request from a different origin

### Phase 6: Input validation

For each input — URL params, query strings, headers, JSON bodies, file uploads:

- XSS — reflected (in error pages, search results, `<title>` injection), stored (in profile fields, comments, file names), DOM (look at JS sinks like `innerHTML`, `eval`, `location`)
  - Payload bank — see `owasp-audit` Verify Fixes XSS payloads
- SQLi — `' OR 1=1 --`, time-based blind (`'; SELECT pg_sleep(5)--`), error-based, UNION-based
  - Modern stacks usually use parameterized queries; look for the one endpoint that didn't get the memo
- Command injection — anywhere file names, image processing, PDF generation, or shell-out happens
- SSRF — webhook URLs, image-fetch, PDF render — see `owasp-audit` A10 bypass matrix
- XXE — XML inputs in SOAP / SVG-upload / DOCX-import paths
- Server-side template injection — `{{7*7}}` in a name field renders `49`? You're in
- Open redirect — see `owasp-audit` A01 with control-byte rejection
- Insecure deserialization — base64-decode any opaque tokens and look for serialized format markers (`O:` for PHP, `\xac\xed` for Java, `cos\nsystem` for Python pickle)

### Phase 7: Error handling

- Stack traces visible in 500 responses
- Database errors leak schema (table names, column names)
- File paths leak server filesystem layout
- Different errors for valid vs invalid usernames (enumeration)
- `/health` / `/status` / `/metrics` / `/actuator/*` exposed

### Phase 8: Business logic

The category most scanners can't touch. Look at *what the app is supposed to do* and ask "what if I do that, but wrong?"

- Race conditions — submit the same coupon code 100× concurrently; can you redeem it more than once?
- Negative numbers — can you transfer `-100` and credit yourself?
- Out-of-order workflows — can you complete step 4 before step 2?
- Quota bypass — free tier limits enforced server-side or just in the UI?
- Workflow approval — can you approve your own request by tampering with `approver_id`?
- File upload — can you upload an `.html` and have the server serve it with `Content-Type: text/html`?

### Phase 9: Client-side

- JS bundle review — `view-source:` / DevTools, look for inline secrets, API keys, internal endpoint hints
- CSP — try to inject a `<script>` and see if it's blocked
- Browser storage — what's in `localStorage` / `sessionStorage` / IndexedDB? Tokens? PII?
- Cross-origin — can `postMessage` from your origin reach the app's window without origin check?

## Tooling

- **Burp Suite Community** (free) — proxy, repeater, intruder (rate-limited), decoder
- **Burp Suite Pro** — scanner, faster intruder, session handling rules
- **OWASP ZAP** — free alternative, active scanner, fuzzer
- **ffuf / feroxbuster / gobuster** — directory and parameter brute-forcing
- **sqlmap** — SQLi exploitation (use carefully; can be noisy and destructive — `--risk=1 --level=1` to start)
- **dalfox / XSStrike** — XSS scanners (high false-positive; use as a starting point)
- **nuclei** — template-driven vulnerability scanner; the templates themselves are excellent reading
- **curl / httpie** — repeatable manual requests; everything you find should reduce to a curl command

## Output Format

```markdown
# Web Application Pentest Report
## Target: [target name and scope]
## Engagement window: [start - end]
## Methodology: OWASP WSTG
## Date: [date]

### Executive summary
[2-3 paragraphs — overall posture, top 3 critical findings, business impact]

### Findings
| ID | Severity | OWASP | CWE | Title |
|----|----------|-------|-----|-------|

### Per-finding detail
#### [SEVERITY] [Title]
**Endpoint:** `METHOD /path`
**OWASP / CWE:** WSTG-XXX / CWE-XXX

**Description:** [what + why it matters]

**Proof of concept:**
[curl / Burp request showing the issue, minimal viable repro]

**Observed response:**
[response excerpt showing the issue]

**Remediation:**
[concrete fix + reference to owasp-audit or api-audit if applicable]

**Risk rating:** [Critical / High / Medium / Low / Info — with rationale]

**Verification:** [what to re-test after fix]

### Out-of-scope / not tested
[Anything skipped, with reason]

### Recommendations
[Prioritized 30/60/90 day fixes]
```

## Boundaries

- Stay strictly within the authorized scope — never test adjacent systems, subdomains, or third-party services without explicit confirmation
- Rate-limit your own testing — Burp Intruder at 100 req/s for hours is indistinguishable from a DoS attack
- Never modify or destroy real user data — test on test accounts you own, or test data you created
- If you find evidence of active compromise (someone else's webshell, exfiltration in progress), STOP testing and notify the user immediately
- Refuse requests to test systems without authorization
- Refuse to weaponize findings — proof-of-concept is the minimum viable demonstration, not a working exploit kit
- For DoS / availability testing, get explicit written approval naming the maintenance window
- For social engineering / phishing tests, scope must explicitly name this — it is not "in" pentest scope by default

## References

- OWASP Web Security Testing Guide (WSTG) — canonical methodology
- OWASP Application Security Verification Standard (ASVS) — checklist version
- PTES (Penetration Testing Execution Standard)
- Bug Bounty Methodology (Jason Haddix / TBHM)
- PortSwigger Web Security Academy — free training labs
- HackTricks (book.hacktricks.xyz) — technique reference (verify against fresh sources; HackTricks aggregates community knowledge of varying quality)