web-pentest

Name: web-pentest
Author: briiirussell

320stars36forks

How to install web-pentest?

briiirussell/cybersecurity-skills/web-pentest

$npx -y skills add briiirussell/cybersecurity-skills --skill web-pentest

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Web Pentest — Live Web Application Testing
2
3	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).
4
5	## Authorization Check
6
7	Before touching the target, confirm:
8	1. Written authorization for this specific application (pentest engagement, bug bounty in-scope domain, CTF/lab, your own asset)
9	2. The application is currently in scope and live (not deprecated, not under maintenance freeze)
10	3. Test credentials provided (if grey-box), or guest access confirmed (if black-box)
11	4. Out-of-scope items documented — production user data, payment flows, social engineering, DoS
12
13	If anything is unclear, ask before proceeding. Never assume authorization.
14
15	## Methodology
16
17	Follows the OWASP Web Security Testing Guide (WSTG) structure. Each phase produces evidence; document everything as you go.
18
19	### Phase 1: Configuration & deployment
20
21	Goal: understand what's running and how it's exposed.
22
23	- HTTP headers — pull with `curl -I` and `curl -I -H "Origin: https://evil.com"`:
24	- `Server`, `X-Powered-By` revealing stack
25	- HSTS, CSP, X-Frame-Options, X-Content-Type-Options presence and values
26	- CORS — `Access-Control-Allow-Origin` reflection without an allow-list, `Allow-Credentials: true` paired with `*`
27	- TLS — `testssl.sh https://target` or `sslyze --regular target`
28	- Backups / configs exposed — `/.git/`, `/.env`, `/backup.sql`, `/web.config`, `/server-status`, `/.aws/credentials`
29	- Default admin paths — `/admin`, `/administrator`, `/manage`, `/console`, `/actuator/`, `/_debug/`, `/swagger`, `/graphql`, `/.well-known/`
30	- Robots.txt and sitemap.xml — often list non-indexed but accessible endpoints
31	- Subdomain & host header testing — does the app behave differently when sent `Host: internal.target.com`?
32
33	### Phase 2: Identity management
34
35	Goal: understand who can be created, how, and with what privileges.
36
37	- Registration — can you self-register? Does the role default to anything other than "user"?
38	- 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")
39	- 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?
40	- Account lockout vs rate-limit — does 100 failed logins lock the account (denial of service vector) or just slow down (good)?
41
42	### Phase 3: Authentication
43
44	Goal: break in as someone you shouldn't be.
45
46	- Login form — is HTTPS enforced? Are credentials sent in URL params (logged everywhere)?
47	- Password policy — minimum length / complexity / breach-database check (haveibeenpwned API)
48	- MFA — required for admin / privileged users? Bypass paths (recovery code, "remember this device" cookie persistence, downgrade to SMS)?
49	- Session token — entropy looks high? Cookie has `HttpOnly`, `Secure`, `SameSite=Lax` or `Strict`?
50	- Session fixation — does the session ID rotate on login? Pre-auth session ID still valid post-auth?
51	- "Remember me" — long-lived token in a separate cookie; revocable on logout from all devices?
52	- Logout — does it actually invalidate the session server-side? (Test by replaying the cookie post-logout.)
53	- Password reset — token format, expiration, single-use, host-header poisoning (`Host: evil.com` in the reset email link)
54	- OAuth flow — PKCE used? `state` parameter validated? `redirect_uri` strictly matched (not prefix-matched)?
55
56	### Phase 4: Authorization (the highest-yield phase)
57
58	Goal: access things you shouldn't.
59
60	Horizontal privilege escalation (IDOR / BOLA):
61	- Sign in as user A. Get a resource that belongs to user A. Note the ID.
62	- 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.
63	- Watch for response codes — 200 (bad), 403 (good), 404 (good if all unauthorized requests return 404; bad if your own 404 looks different)
64	- Try every endpoint that takes an ID — `GET /users/:id`, `POST /users/:id/...`, `DELETE /users/:id`, `GET /api/users/:id/orders`, GraphQL `user(id: ...)`
65
66	Vertical privilege escalation (BFLA):
67	- Identify admin-only ro

People who liked this also viewed

6 picks

Type

web-pentest

320stars36forks

View on GitHub

How to install web-pentest?

briiirussell/cybersecurity-skills/web-pentest

$npx -y skills add briiirussell/cybersecurity-skills --skill web-pentest

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Web Pentest — Live Web Application Testing
2
3	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).
4
5	## Authorization Check
6
7	Before touching the target, confirm:
8	1. Written authorization for this specific application (pentest engagement, bug bounty in-scope domain, CTF/lab, your own asset)
9	2. The application is currently in scope and live (not deprecated, not under maintenance freeze)
10	3. Test credentials provided (if grey-box), or guest access confirmed (if black-box)
11	4. Out-of-scope items documented — production user data, payment flows, social engineering, DoS
12
13	If anything is unclear, ask before proceeding. Never assume authorization.
14
15	## Methodology
16
17	Follows the OWASP Web Security Testing Guide (WSTG) structure. Each phase produces evidence; document everything as you go.
18
19	### Phase 1: Configuration & deployment
20
21	Goal: understand what's running and how it's exposed.
22
23	- HTTP headers — pull with `curl -I` and `curl -I -H "Origin: https://evil.com"`:
24	- `Server`, `X-Powered-By` revealing stack
25	- HSTS, CSP, X-Frame-Options, X-Content-Type-Options presence and values
26	- CORS — `Access-Control-Allow-Origin` reflection without an allow-list, `Allow-Credentials: true` paired with `*`
27	- TLS — `testssl.sh https://target` or `sslyze --regular target`
28	- Backups / configs exposed — `/.git/`, `/.env`, `/backup.sql`, `/web.config`, `/server-status`, `/.aws/credentials`
29	- Default admin paths — `/admin`, `/administrator`, `/manage`, `/console`, `/actuator/`, `/_debug/`, `/swagger`, `/graphql`, `/.well-known/`
30	- Robots.txt and sitemap.xml — often list non-indexed but accessible endpoints
31	- Subdomain & host header testing — does the app behave differently when sent `Host: internal.target.com`?
32
33	### Phase 2: Identity management
34
35	Goal: understand who can be created, how, and with what privileges.
36
37	- Registration — can you self-register? Does the role default to anything other than "user"?
38	- 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")
39	- 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?
40	- Account lockout vs rate-limit — does 100 failed logins lock the account (denial of service vector) or just slow down (good)?
41
42	### Phase 3: Authentication
43
44	Goal: break in as someone you shouldn't be.
45
46	- Login form — is HTTPS enforced? Are credentials sent in URL params (logged everywhere)?
47	- Password policy — minimum length / complexity / breach-database check (haveibeenpwned API)
48	- MFA — required for admin / privileged users? Bypass paths (recovery code, "remember this device" cookie persistence, downgrade to SMS)?
49	- Session token — entropy looks high? Cookie has `HttpOnly`, `Secure`, `SameSite=Lax` or `Strict`?
50	- Session fixation — does the session ID rotate on login? Pre-auth session ID still valid post-auth?
51	- "Remember me" — long-lived token in a separate cookie; revocable on logout from all devices?
52	- Logout — does it actually invalidate the session server-side? (Test by replaying the cookie post-logout.)
53	- Password reset — token format, expiration, single-use, host-header poisoning (`Host: evil.com` in the reset email link)
54	- OAuth flow — PKCE used? `state` parameter validated? `redirect_uri` strictly matched (not prefix-matched)?
55
56	### Phase 4: Authorization (the highest-yield phase)
57
58	Goal: access things you shouldn't.
59
60	Horizontal privilege escalation (IDOR / BOLA):
61	- Sign in as user A. Get a resource that belongs to user A. Note the ID.
62	- 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.
63	- Watch for response codes — 200 (bad), 403 (good), 404 (good if all unauthorized requests return 404; bad if your own 404 looks different)
64	- Try every endpoint that takes an ID — `GET /users/:id`, `POST /users/:id/...`, `DELETE /users/:id`, `GET /api/users/:id/orders`, GraphQL `user(id: ...)`
65
66	Vertical privilege escalation (BFLA):
67	- Identify admin-only ro

People who liked this also viewed

6 picks

Type