2.1 Map useful web behavior
Strategy map | Master Notes | Operational index | Cheatsheets
Build the request and role map before selecting a weakness. Distinguish scheme, virtual host, route, method, parameter, object and identity; the same path can expose different behavior in another context.
Speedrun blocks: 3. Documented methods: 6.
Examples are hypothetical study material. Apply commands only to an assigned scope during the later practice phase. A method is enabled by its prerequisites; its presence here does not establish a vulnerability or practical mastery.
2.1.1 First pass: tools and findings
Use the branch matching the current host, identity and observed result. Tool output supplies leads; the linked procedure verifies and uses the exact condition.
2.1.1.1 Capture a real request before fuzzing
Use the browser/proxy to capture the real method, host, cookie and input; curl is the replay baseline.
curl -skD headers.txt -o body.html http://TARGET:PORT/
curl -skI https://TARGET:PORT/
- If Redirect to a different hostname: Resolve and replay that hostname before testing paths. → Discover virtual hosts and hostname-selected applications.
- If A login, upload or object endpoint: Capture its normal authenticated request and available roles. → Map parameters, API methods, objects and writable properties.
- Otherwise: Every request reaches the wrong/default site: fix the host/scheme/session first. → Establish scheme, host, redirects and request state.
2.1.1.2 Discover paths with Gobuster or the documented ffuf variant
First request a missing path to learn the false-positive body/status/length. Keep the correct host and session.
gobuster dir -u http://TARGET:PORT/ -w /usr/share/wordlists/dirb/common.txt -t 10 -o gobuster-root.txt
- If A backup, config, source or repository path: Read its content; a 200 response alone does not establish an artifact. → Inspect source, backups, configuration and repository artifacts.
- If A new application function: Map its parameters and authorization boundary. → Map parameters, API methods, objects and writable properties.
- Otherwise: All candidates look identical: repair the response controls rather than collecting more false positives. → Discover directories and files with controlled response filtering.
2.1.1.3 Enumerate hostname-selected sites
Use this when DNS, certificates, redirects or page content suggest another hostname.
gobuster vhost -u http://DOMAIN:PORT/ --append-domain -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -o vhosts.txt
- If A host has a distinct response: Browse it with the correct Host header and repeat function/path mapping. → Map functions, roles and normal requests manually.
- Otherwise: No distinct host: return to real application functions and exposed scripts. → Map functions, roles and normal requests manually.
2.1.2 Discovery workflow
Start with a reachable URL. A suspicious parameter, hidden administration path or accepted account is not assumed.
Follow these observations into a method; the detailed recognition routes below show synthetic output and the checks still needed.
- Record scheme, hostname, redirects and session state: Establish scheme, host, redirects and request state.
- Browse real functions and capture their requests; inspect source/scripts and exposed artifacts: Map functions, roles and normal requests manually; Inspect source, backups, configuration and repository artifacts.
- Use missing-path/host controls before content or virtual-host discovery: Discover directories and files with controlled response filtering; Discover virtual hosts and hostname-selected applications.
- Map methods, input locations, object ownership and roles before selecting a weakness: Map parameters, API methods, objects and writable properties.
Decision rule: an observed clue opens a candidate. Choose it only after the missing conditions are verified; a failed check rules out that context, while unavailable evidence stays inconclusive.
2.1.3 Method families
- Application identity and hosts: Establish scheme, host, redirects and request state, Discover virtual hosts and hostname-selected applications.
- Functions, artifacts and content: Map functions, roles and normal requests manually, Inspect source, backups, configuration and repository artifacts, Discover directories and files with controlled response filtering.
- Inputs, objects and APIs: Map parameters, API methods, objects and writable properties.
2.1.4 Choose a method
| Method | Recognition clue | Required access | Enabling conditions | Resulting capability |
|---|---|---|---|---|
| Establish scheme, host, redirects and request state | An HTTP endpoint, redirect or hostname-dependent response | A reachable HTTP application and recorded anonymous or authenticated request state | Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons | A reproducible application identity and baseline request |
| Discover virtual hosts and hostname-selected applications | DNS names, redirects, certificate names or a default virtual-host response | A reachable HTTP application and recorded anonymous or authenticated request state | A destination listener, relevant domain candidates and controlled Host/SNI routing | Additional verified applications on the same address |
| Map functions, roles and normal requests manually | Forms, downloads, exports, account functions or role-specific interfaces | A reachable HTTP application and recorded anonymous or authenticated request state | A normal request baseline and the relevant account/role; authorized accounts for role comparisons | An input/function/role map with concrete attack hypotheses |
| Inspect source, backups, configuration and repository artifacts | JavaScript endpoints, backup names, exposed configuration or Git metadata | A reachable HTTP application and recorded anonymous or authenticated request state | Readable application artifact or a complete recoverable repository; preserve the public-source scope | Hidden functionality, version clues or typed credential artifacts |
| Discover directories and files with controlled response filtering | An application has unlinked paths, backups or administration endpoints | A reachable HTTP application and recorded anonymous or authenticated request state | Correct base URL/session and a measured nonexistent-path response; bounded relevant wordlist | Verified candidate routes and files |
| Map parameters, API methods, objects and writable properties | An API/schema, numeric object IDs, hidden fields or different HTTP methods | A reachable HTTP application and recorded anonymous or authenticated request state | A valid request and explicit role/object ownership; exact input format and content type | A parameter/object/method inventory and testable authorization or injection hypothesis |
2.1.5 Establish scheme, host, redirects and request state
Blocks: 3. Operational procedure | Quick sheet
2.1.5.1 Purpose and result
A reproducible application identity and baseline request.
2.1.5.2 Recognition clues
An HTTP endpoint, redirect or hostname-dependent response.
2.1.5.2.1 Find the clue from your starting access
Where to investigate: Request the assigned HTTP endpoint without following redirects blindly; inspect location, cookies and alternate scheme/hostname behavior.
Discovery action — reference example:
Access/context: A reachable HTTP application and recorded anonymous or authenticated request state
Conditions, effects and verification
Requires: Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons
Action class: HTTP requests; selected authenticated application actions can change application state.
Stop/verify: Record final URL, host, status, redirects, cookies and authentication context before comparing payload results.
Failure/next check: A redirect loop or generic default page may indicate a wrong host or missing session rather than a nonexistent application.
curl -skD headers.txt -o body.html http://TARGET:PORT/
curl -skI https://TARGET:PORT/
Illustrative evidence — synthetic, abbreviated:
The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.
HTTP/1.1 302 Found
Location: https://HOSTNAME/
Set-Cookie: SESSION_COOKIE
Recognize this detail: The hostname/scheme redirect identifies the application request context to reproduce.
Still missing before method selection: Confirm the hostname routes to the assigned address and preserve its TLS/Host/session state.
| Outcome after checking | Example and next decision |
|---|---|
| Enabled after validation | The correct named request reaches a distinct application: map its functions. |
| Ruled out in this context | The candidate name produces only the default missing-host response: discard that virtual-host inference. |
| Inconclusive | Redirect loops can mean missing cookies/host routing; repair the normal request before testing vulnerabilities. |
If you do not yet have this clue: start with this topic's discovery workflow.
2.1.5.3 Prerequisites
Starting access: A reachable HTTP application and recorded anonymous or authenticated request state. Required conditions: Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons.
2.1.5.4 Discover and verify prerequisites
curl -skD headers.txt -o body.html http://TARGET:PORT/
curl -skI https://TARGET:PORT/
2.1.5.5 Why it works
TLS SNI, Host, redirects and cookies can select different applications. A response from the IP URL does not describe every hostname served by that listener.
2.1.5.6 Execute and choose variants
curl -skL -D headers.txt -o body.html http://TARGET:PORT/
curl -sk -o /dev/null -w 'code=%{http_code} bytes=%{size_download} type=%{content_type} redirect=%{redirect_url}\n' http://TARGET:PORT/
Decisive output: record the scheme, hostname/
Hostheader, port, redirects, page title, certificate names, server/framework clues and whether the view is anonymous or authenticated.
2.1.5.6.1 Variant — explicit virtual-host candidate
curl -sk -H 'Host: CANDIDATE.DOMAIN' http://TARGET:PORT/
Compare it with a random hostname. A different status alone is weak evidence; compare body, length, title and redirects.
2.1.5.6.2 Variant — preserve cookies and follow redirects
curl -skL -c cookies.txt -b cookies.txt http://TARGET:PORT/PATH
Use a separate cookie jar per identity. Do not mix anonymous, ordinary-user and administrator evidence.
2.1.5.6.3 Variant — replay through Burp Community
curl -sk -x http://127.0.0.1:8080 http://TARGET:PORT/PATH
Confirm the proxy listener is active on 127.0.0.1:8080. Use -k only for the controlled lab because it disables destination-certificate verification.
2.1.5.7 Worked example — hypothetical
Observation: the IP URL redirects to a hostname. Test: send the correct Host/SNI while routing to the assigned address. Illustrative output: a distinct application login appears. Interpretation: map that application separately.
2.1.5.8 Verify the result
Record final URL, host, status, redirects, cookies and authentication context before comparing payload results.
2.1.5.9 Failure and fallback
A redirect loop or generic default page may indicate a wrong host or missing session rather than a nonexistent application.
2.1.5.10 Continue from the interpreted result
| Observed result | Check before proceeding | Next numbered section |
|---|---|---|
| DNS names, redirects, certificate names or a default virtual-host response | A destination listener, relevant domain candidates and controlled Host/SNI routing | §2.1.6 — Discover virtual hosts and hostname-selected applications |
| Forms, downloads, exports, account functions or role-specific interfaces | A normal request baseline and the relevant account/role; authorized accounts for role comparisons | §2.1.7 — Map functions, roles and normal requests manually |
| JavaScript endpoints, backup names, exposed configuration or Git metadata | Readable application artifact or a complete recoverable repository; preserve the public-source scope | §2.1.8 — Inspect source, backups, configuration and repository artifacts |
2.1.6 Discover virtual hosts and hostname-selected applications
Blocks: 3. Operational procedure | Quick sheet
2.1.6.1 Purpose and result
Additional verified applications on the same address.
2.1.6.2 Recognition clues
DNS names, redirects, certificate names or a default virtual-host response.
2.1.6.2.1 Find the clue from your starting access
Where to investigate: Collect hostnames from redirects, certificates, DNS and source; compare named requests against an invalid-host control.
Discovery action — reference example:
Access/context: A reachable HTTP application and recorded anonymous or authenticated request state
Conditions, effects and verification
Requires: A destination listener, relevant domain candidates and controlled Host/SNI routing
Action class: HTTP requests; selected authenticated application actions can change application state.
Stop/verify: Compare candidate and nonexistent-host responses, including content and redirects; resolve to the intended scoped address.
Failure/next check: A default response for every host or an SNI mismatch makes the result inconclusive; do not treat every guessed hostname as a real application.
curl -sk --resolve HOSTNAME:PORT:TARGET https://HOSTNAME:PORT/
Illustrative evidence — synthetic, abbreviated:
The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.
Host HOSTNAME: application login page
Host INVALID_HOST: default server page
Recognize this detail: A reproducible hostname-selected application is a new mapping target on the same address.
Still missing before method selection: Send a random Host header as a negative control, compare the candidate's real response, then browse it with the correct hostname. A different status caused only by redirects or a default site is not a confirmed vhost.
| Outcome after checking | Example and next decision |
|---|---|
| Enabled after validation | The named application has distinct verified behavior: give it its own session/function map. |
| Ruled out in this context | All candidate hosts receive the same default body: discard the claimed distinct application. |
| Inconclusive | TLS routing or local DNS is wrong: fix that context before deciding a vhost is absent. |
If you do not yet have this clue: start with Establish scheme, host, redirects and request state.
2.1.6.3 Prerequisites
Starting access: A reachable HTTP application and recorded anonymous or authenticated request state. Required conditions: A destination listener, relevant domain candidates and controlled Host/SNI routing.
2.1.6.4 Discover and verify prerequisites
curl -sk --resolve HOSTNAME:PORT:TARGET https://HOSTNAME:PORT/
2.1.6.5 Why it works
Virtual-host routing uses the requested hostname. DNS resolution, HTTP Host and TLS SNI must be aligned when the server selects behavior at more than one layer.
2.1.6.6 Execute and choose variants
gobuster vhost -u http://DOMAIN:PORT/ --append-domain -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -o vhosts.txt
Alternative with automatic calibration:
ffuf -w WORDLIST -u http://TARGET:PORT/ -H 'Host: FUZZ.DOMAIN' -ac -o ffuf-vhosts.json
Failure cue: uniform status/length may be the default vhost. Compare each candidate with a random host header before adding it to the application map.
2.1.6.7 Worked example — hypothetical
Observation: a certificate suggests an internal application name. Test: resolve it to the assigned address while preserving SNI. Illustrative output: a separate administration interface. Interpretation: give it its own request and credential map.
2.1.6.8 Verify the result
Compare candidate and nonexistent-host responses, including content and redirects; resolve to the intended scoped address.
2.1.6.9 Failure and fallback
A default response for every host or an SNI mismatch makes the result inconclusive; do not treat every guessed hostname as a real application.
2.1.6.10 Continue from the interpreted result
| Observed result | Check before proceeding | Next numbered section |
|---|---|---|
| An HTTP endpoint, redirect or hostname-dependent response | Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons | §2.1.5 — Establish scheme, host, redirects and request state |
| Forms, downloads, exports, account functions or role-specific interfaces | A normal request baseline and the relevant account/role; authorized accounts for role comparisons | §2.1.7 — Map functions, roles and normal requests manually |
| A DNS server, domain name or host aliases | Reachable DNS transport and relevant authoritative zone; AXFR requires an allowed TCP zone transfer | §1.2.11 — Expand names through DNS records and zone transfers |
2.1.7 Map functions, roles and normal requests manually
Blocks: 3. Operational procedure | Quick sheet
2.1.7.1 Purpose and result
An input/function/role map with concrete attack hypotheses.
2.1.7.2 Recognition clues
Forms, downloads, exports, account functions or role-specific interfaces.
2.1.7.2.1 Find the clue from your starting access
Where to investigate: Browse the site's normal account, export, upload and download features while recording requests in the browser/proxy.
Discovery action — reference example:
Access/context: A reachable HTTP application and recorded anonymous or authenticated request state
Conditions, effects and verification
Requires: A normal request baseline and the relevant account/role; authorized accounts for role comparisons
Action class: HTTP requests; selected authenticated application actions can change application state.
Stop/verify: Retain method, route, input location, identity and expected normal behavior; do not infer vulnerability from an interesting parameter name.
Failure/next check: Expired sessions, CSRF failures and malformed requests can imitate access-control differences; reproduce a valid baseline first.
curl -sk -b cookies.txt -D response-headers.txt http://TARGET:PORT/PATH
Illustrative evidence — synthetic, abbreviated:
The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.
Observed browser request:
GET /download?file=report.pdf
Cookie: SESSION_COOKIE
Recognize this detail: The normal request exposes a file-selecting input discovered through functionality, not guessed from a payload list.
Still missing before method selection: Find the actual input semantics, account/role and normal response before file/read/authorization tests.
| Outcome after checking | Example and next decision |
|---|---|
| Enabled after validation | Controlled comparisons prove a useful primitive: choose its method and remaining checks. |
| Ruled out in this context | The parameter only selects an allowlisted public report: discard unrestricted-path inference. |
| Inconclusive | Unknown ownership or an expired session prevents interpreting differences; re-establish the baseline. |
If you do not yet have this clue: start with Establish scheme, host, redirects and request state.
2.1.7.3 Prerequisites
Starting access: A reachable HTTP application and recorded anonymous or authenticated request state. Required conditions: A normal request baseline and the relevant account/role; authorized accounts for role comparisons.
2.1.7.4 Discover and verify prerequisites
curl -sk -b cookies.txt -D response-headers.txt http://TARGET:PORT/PATH
2.1.7.5 Why it works
The same functionality can expose different trust boundaries through object IDs, methods and roles. Changing one property while preserving request state makes differences interpretable.
2.1.7.6 Execute and choose variants
For every visible function, capture one unchanged request in Burp Proxy history, send it to Repeater and record:
METHOD PATH | CONTENT-TYPE | ACCESS CONTEXT/ROLE
INPUT LOCATION + NAME | BASELINE VALUE
STATUS | LENGTH/HASH | REDIRECT | MARKER/ERROR/TIME
OBJECT/FUNCTION SELECTED | NEXT ONE-VARIABLE TEST
Check login/registration/reset, profiles/objects, search/filter/pagination, download/export/preview, upload/import, administration and every JavaScript API call.
Next: a browser-side restriction is not server authorization. Replay the raw request and change one field, object reference, method or access-context element at a time.
2.1.7.7 Worked example — hypothetical
Observation: a report download accepts a numeric ID. Test: compare objects owned by two authorized study accounts. Illustrative output: a lower role receives another account's report. Interpretation: proceed to an object-authorization method.
2.1.7.8 Verify the result
Retain method, route, input location, identity and expected normal behavior; do not infer vulnerability from an interesting parameter name.
2.1.7.9 Failure and fallback
Expired sessions, CSRF failures and malformed requests can imitate access-control differences; reproduce a valid baseline first.
2.1.7.10 Continue from the interpreted result
| Observed result | Check before proceeding | Next numbered section |
|---|---|---|
| A request selects an object by ID/path and two authorized ownership contexts are available | The server accepts a lower-privilege identity's request for an object it should not access | §2.2.18 — Cross an object-ownership boundary |
| A download/path parameter or URL segment influences a local filename | Untrusted path reaches a filesystem read outside its intended directory; process identity can read the requested file | §2.2.5 — Read files through directory traversal |
| An upload/import/attachment function | A valid upload request and permitted account; the server accepts and stores controlled bytes | §2.2.8 — Establish upload acceptance, storage and retrieval |
| Controlled input appears in a server-rendered template, preview, email or report | The application evaluates attacker-controlled template syntax and the selected engine exposes a useful object or function | §2.2.24 — Prove server-side template evaluation and identify its engine |
| A working XML request reaches a server-side parser that accepts a controlled document or field | External entity or XInclude processing is enabled and the parser identity can read the selected file | §2.2.25 — Use an XML parser's external-entity behavior for bounded file read |
| A login or search accepts JSON/nested form properties and evidence suggests an operator-based document query | The framework preserves an attacker-controlled operator object and the query uses it without rejecting its type | §2.2.26 — Test structured NoSQL operator injection with identity controls |
| Source or request evidence shows controlled serialized PHP data reaches unsafe unserialize | Required gadget classes and compatible dependency versions are loaded; transport preserves exact serialized bytes | §2.2.27 — Match PHP deserialization gadgets to installed dependencies |
| Source or errors identify server-side Python YAML loading of controlled content | The application uses an unsafe PyYAML loader that permits the selected Python object constructor | §2.2.28 — Validate unsafe YAML object construction |
| A real CGI endpoint invokes Bash and component/patch evidence supports the vulnerable family | HTTP-derived environment data reaches an affected Bash process and the selected command is available | §2.2.29 — Test Shellshock only through a confirmed CGI-to-Bash chain |
| An application has unlinked paths, backups or administration endpoints | Correct base URL/session and a measured nonexistent-path response; bounded relevant wordlist | §2.1.9 — Discover directories and files with controlled response filtering |
2.1.8 Inspect source, backups, configuration and repository artifacts
Blocks: 3. Operational procedure | Operational procedure | Operational procedure | Quick sheet
2.1.8.1 Purpose and result
Hidden functionality, version clues or typed credential artifacts.
2.1.8.2 Recognition clues
JavaScript endpoints, backup names, exposed configuration or Git metadata.
2.1.8.2.1 Find the clue from your starting access
Where to investigate: Inspect linked JavaScript/source, robots/sitemaps, relevant backups and a bounded Git metadata check from the mapped web application.
Discovery action — reference example:
Access/context: A reachable HTTP application and recorded anonymous or authenticated request state
Conditions, effects and verification
Requires: Readable application artifact or a complete recoverable repository; preserve the public-source scope
Action class: HTTP requests; selected authenticated application actions can change application state.
Stop/verify: Confirm actual file/history content and distinguish a historical secret from a usable current credential.
Failure/next check: A 200 soft-404 or incomplete object database is not a recovered repository. Compare known-missing paths and record missing history.
curl -sk http://TARGET:PORT/robots.txt
curl -sk http://TARGET:PORT/.git/HEAD
Illustrative evidence — synthetic, abbreviated:
The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.
robots.txt: Disallow: /INTERNAL_PATH/
.git/HEAD: ref: refs/heads/main
Recognize this detail: The path and Git reference are investigation leads; neither proves a working secret or complete repository.
Still missing before method selection: Compare missing-path controls, retrieve actual permitted artifacts and verify recovered history/account context.
| Outcome after checking | Example and next decision |
|---|---|
| Enabled after validation | Relevant source/history is recoverable and exposes a typed artifact: inspect it through the credential workflow. |
| Ruled out in this context | The same body is returned for arbitrary missing paths: reject the apparent metadata exposure. |
| Inconclusive | HEAD without objects leaves repository recovery incomplete; document available content instead of inventing history. |
If you do not yet have this clue: start with Establish scheme, host, redirects and request state.
2.1.8.3 Prerequisites
Starting access: A reachable HTTP application and recorded anonymous or authenticated request state. Required conditions: Readable application artifact or a complete recoverable repository; preserve the public-source scope.
2.1.8.4 Discover and verify prerequisites
curl -sk http://TARGET:PORT/robots.txt
curl -sk http://TARGET:PORT/.git/HEAD
2.1.8.5 Why it works
Client code and repository history can preserve endpoints and removed secrets. An exposed Git HEAD proves metadata exposure; repository completeness and secret validity require separate checks.
2.1.8.6 Execute and choose variants
curl -sk http://TARGET:PORT/robots.txt
curl -sk http://TARGET:PORT/sitemap.xml
curl -sk http://TARGET:PORT/.git/HEAD
curl -sk http://TARGET:PORT/openapi.json
curl -sk http://TARGET:PORT/swagger.json
Also inspect HTML comments, hidden inputs, form actions, linked JavaScript, route strings, source-map references, cookies and response headers.
Decisive output: a path, parameter, API schema, object identifier, component or secret-bearing artifact that creates a specific next request. Source disclosure is not command execution.
curl -ski http://TARGET:PORT/.git/HEAD
curl -ski http://TARGET:PORT/.git/config
A readable
HEAD/configsupports exposed repository metadata. A403, redirect or generic template is not proof. Preserve the correct host header/base path.
If authorized, recover into a new local directory with a purpose-built tool and inspect locally:
git-dumper http://TARGET:PORT/.git/ repo-output
git -C repo-output status
git -C repo-output log --oneline --all --decorate
git -C repo-output log -p --all
git-dumper is an optional third-party helper; install on demand in an isolated environment only when the exposure has been confirmed. Manual object recovery is possible but slower.
rg -ni 'password|passwd|token|secret|api[_-]?key|private[_-]?key' repo-output
git -C repo-output log --all -S'password' --oneline
git -C repo-output log --all -G'pass(word)?|secret|token' --oneline
Inspect candidate commits without dumping all history:
git -C repo-output show COMMIT -- PATH
git -C repo-output diff COMMIT^ COMMIT -- PATH
Validate freshness, identity and compatible use. Removed historical values are often rotated or environment-specific.
2.1.8.7 Worked example — hypothetical
Observation: Git metadata is exposed. Test: recover only available objects and inspect history. Illustrative output: a removed database connection string. Interpretation: classify the account and validate current database access.
2.1.8.8 Verify the result
Confirm actual file/history content and distinguish a historical secret from a usable current credential.
2.1.8.9 Failure and fallback
A 200 soft-404 or incomplete object database is not a recovered repository. Compare known-missing paths and record missing history.
2.1.8.10 Continue from the interpreted result
| Observed result | Check before proceeding | Next numbered section |
|---|---|---|
| A secret-like value, key file, stored hash, challenge response or ticket | Artifact provenance and format; possible local/domain/application identity and compatible protocol | §3.1.5 — Classify the artifact and its identity context |
| A product/version clue, advisory or component-specific public PoC | Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect | §4.1.5 — Match a public exploit to the actual component and configuration |
| An API/schema, numeric object IDs, hidden fields or different HTTP methods | A valid request and explicit role/object ownership; exact input format and content type | §2.1.10 — Map parameters, API methods, objects and writable properties |
2.1.9 Discover directories and files with controlled response filtering
Blocks: 3. Operational procedure | Quick sheet
2.1.9.1 Purpose and result
Verified candidate routes and files.
2.1.9.2 Recognition clues
An application has unlinked paths, backups or administration endpoints.
2.1.9.2.1 Find the clue from your starting access
Where to investigate: Establish the application's missing-path response, then run a bounded content search with the existing session/host context.
Discovery action — reference example:
Access/context: A reachable HTTP application and recorded anonymous or authenticated request state
Conditions, effects and verification
Requires: Correct base URL/session and a measured nonexistent-path response; bounded relevant wordlist
Action class: HTTP requests; selected authenticated application actions can change application state.
Stop/verify: Open candidates and record their actual behavior; status/length alone is only a selection clue.
Failure/next check: Aggressive filters can hide genuine routes and rate limiting can fabricate differences; validate the baseline and reduce the request rate.
curl -sk -D - http://TARGET:PORT/KNOWN_MISSING_PATH
Illustrative evidence — synthetic, abbreviated:
The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.
Missing control: status=200, body=DEFAULT_ERROR
Candidate /EXPORT_PATH/: status=200, body=EXPORT_FORM
Recognize this detail: The candidate's actual function differs from the soft-404 control despite equal status codes.
Still missing before method selection: Request a known-missing path under the same host/session and compare status, body and length. Open each distinct Gobuster/ffuf result; a uniform login page or soft-404 is a filter problem, not a directory finding.
| Outcome after checking | Example and next decision |
|---|---|
| Enabled after validation | Independent retrieval confirms an actual function: add its request to the behavior map. |
| Ruled out in this context | The candidate matches the wildcard error body: remove it from the useful queue. |
| Inconclusive | Rate limiting or session expiry distorts response size; restore stable controls before filtering. |
If you do not yet have this clue: start with Establish scheme, host, redirects and request state.
2.1.9.3 Prerequisites
Starting access: A reachable HTTP application and recorded anonymous or authenticated request state. Required conditions: Correct base URL/session and a measured nonexistent-path response; bounded relevant wordlist.
2.1.9.4 Discover and verify prerequisites
curl -sk -D - http://TARGET:PORT/KNOWN_MISSING_PATH
2.1.9.5 Why it works
Discovery enumerates names; wildcard responses, redirects and soft-404 pages can make every guess appear valid. Confirm candidates through independent retrieval and behavior.
2.1.9.6 Execute and choose variants
Request a random nonexistent path first and record its status, length and body marker.
gobuster dir -u http://TARGET:PORT/ -w /usr/share/wordlists/dirb/common.txt -t 10 -o gobuster-root.txt
Decisive output: manually verified routes including useful
200, redirect,401,403and405responses.
2.1.9.6.1 Variant — technology-aware extensions
gobuster dir -u http://TARGET:PORT/ -w WORDLIST -x php,txt,bak,old,zip -t 10 -o gobuster-ext.txt
Choose extensions from observed stack evidence; do not spray every extension.
2.1.9.6.2 Variant — authenticated discovery
gobuster dir -u http://TARGET:PORT/ -w WORDLIST -c 'SESSION=VALUE' -H 'Authorization: Bearer TOKEN' -t 10 -o gobuster-auth.txt
Use only the cookie or header that applies. An expired session can turn every result into the same login redirect.
2.1.9.6.3 Variant — filter a confirmed wildcard body length
gobuster dir -u http://TARGET:PORT/ -w WORDLIST --exclude-length NOISE_LENGTH -t 10 -o gobuster-filtered.txt
Filtering without first confirming the noise response can hide a real path.
2.1.9.7 Worked example — hypothetical
Observation: every path returns 200. Test: compare the missing-path body/length before filtering. Illustrative output: one candidate has a distinct export response. Interpretation: inspect that function manually.
2.1.9.8 Verify the result
Open candidates and record their actual behavior; status/length alone is only a selection clue.
2.1.9.9 Failure and fallback
Aggressive filters can hide genuine routes and rate limiting can fabricate differences; validate the baseline and reduce the request rate.
2.1.9.10 Continue from the interpreted result
| Observed result | Check before proceeding | Next numbered section |
|---|---|---|
| Forms, downloads, exports, account functions or role-specific interfaces | A normal request baseline and the relevant account/role; authorized accounts for role comparisons | §2.1.7 — Map functions, roles and normal requests manually |
| JavaScript endpoints, backup names, exposed configuration or Git metadata | Readable application artifact or a complete recoverable repository; preserve the public-source scope | §2.1.8 — Inspect source, backups, configuration and repository artifacts |
| An upload/import/attachment function | A valid upload request and permitted account; the server accepts and stores controlled bytes | §2.2.8 — Establish upload acceptance, storage and retrieval |
2.1.10 Map parameters, API methods, objects and writable properties
Blocks: 3. Operational procedure | Operational procedure | Quick sheet
2.1.10.1 Purpose and result
A parameter/object/method inventory and testable authorization or injection hypothesis.
2.1.10.2 Recognition clues
An API/schema, numeric object IDs, hidden fields or different HTTP methods.
2.1.10.2.1 Find the clue from your starting access
Where to investigate: Capture a valid API request, inspect its schema/client code and compare allowed methods and controlled object/role contexts.
Discovery action — reference example:
Access/context: A reachable HTTP application and recorded anonymous or authenticated request state
Conditions, effects and verification
Requires: A valid request and explicit role/object ownership; exact input format and content type
Action class: HTTP requests; selected authenticated application actions can change application state.
Stop/verify: Prove which input is consumed and whether state changes persist in an independent read.
Failure/next check: HTTP 400/415 may indicate encoding/schema rather than security enforcement. Keep a valid request before changing permissions-related properties.
curl -sk -i -b cookies.txt http://TARGET:PORT/api/PATH
Illustrative evidence — synthetic, abbreviated:
The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.
Object fields: id, ownerId, role
Observed request: PATCH /api/profile
Body: {"displayName":"VALUE"}
Recognize this detail: The actual object, method and writable input are known; returned owner/role fields are only candidate security boundaries.
Still missing before method selection: Determine field binding, ownership, persistence and server authorization with controlled accounts.
| Outcome after checking | Example and next decision |
|---|---|
| Enabled after validation | A protected field/action changes under a lower role and is independently verified: select its authorization method. |
| Ruled out in this context | The server ignores the sensitive field and privileges remain unchanged: reject that assignment hypothesis. |
| Inconclusive | Malformed JSON or wrong content type makes a failed request inconclusive; reproduce the valid update first. |
If you do not yet have this clue: start with Establish scheme, host, redirects and request state.
2.1.10.3 Prerequisites
Starting access: A reachable HTTP application and recorded anonymous or authenticated request state. Required conditions: A valid request and explicit role/object ownership; exact input format and content type.
2.1.10.4 Discover and verify prerequisites
curl -sk -i -b cookies.txt http://TARGET:PORT/api/PATH
2.1.10.5 Why it works
APIs enforce security at route, object and property boundaries. A valid JSON body can be accepted while a sensitive field is ignored; test its persisted effect separately.
2.1.10.6 Execute and choose variants
GET parameter names:
ffuf -w /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt -u 'http://TARGET:PORT/PATH?FUZZ=test' -ac -o params-get.json
POST form parameter names:
ffuf -w WORDLIST -u http://TARGET:PORT/PATH -X POST -H 'Content-Type: application/x-www-form-urlencoded' -d 'known=value&FUZZ=test' -ac -o params-post.json
Object values with an authenticated API:
ffuf -w NUMBERS -u 'http://TARGET:PORT/api/objects/FUZZ' -H 'Authorization: Bearer TOKEN' -mc all -fc 404 -o object-values.json
Decisive output: a manually reproduced parameter or value that changes application behavior. Tool outliers are candidates, not confirmed access-control flaws.
2.1.10.6.1 ffuf — preserve a captured authenticated request
Save a working raw request from the proxy as request.txt, retain its Host/cookie/body, and put FUZZ at the single parameter name/value or path being tested. Replay it once manually first. The request file does not specify TLS: choose the transport explicitly.
2.1.10.6.2 HTTPS request, including its original method and session headers
# HTTPS request, including its original method and session headers
ffuf -request request.txt -request-proto https -w WORDLIST -mc all -ac -t 10 -o request-https.json2.1.10.6.3 Plain HTTP request: otherwise ffuf defaults to HTTPS
# Plain HTTP request: otherwise ffuf defaults to HTTPS
ffuf -request request.txt -request-proto http -w WORDLIST -mc all -ac -t 10 -o request-http.json
Read: compare an outlier's status/length/body with a known missing value, then replay that exact request. A login redirect for every value → refresh the session before continuing. A one-time CSRF token → repair token handling; the saved-request flag does not refresh it automatically.
curl -ski http://TARGET:PORT/api/v1/PATH
curl -ski -X OPTIONS http://TARGET:PORT/api/v1/PATH
curl -ski -X POST -H 'Content-Type: application/json' -d '{"username":"TEST_USER","password":"TEST_PASSWORD"}' http://TARGET:PORT/api/v1/login
Interpretation:
405can establish that a route exists but rejects the method. Validation errors can reveal required fields. A token establishes only the authorization demonstrated by a later request.
Build a matrix across anonymous, user A, user B and administrator contexts where available:
PATH | METHOD | IDENTITY/ROLE | OBJECT/PROPERTY | RESULT | NEXT
2.1.10.7 Worked example — hypothetical
Observation: an API response includes a role property. Test: compare documented writable fields and a controlled update. Illustrative output: the field is ignored and privilege is unchanged. Interpretation: that mass-assignment hypothesis is disproven; investigate other boundaries.
2.1.10.8 Verify the result
Prove which input is consumed and whether state changes persist in an independent read.
2.1.10.9 Failure and fallback
HTTP 400/415 may indicate encoding/schema rather than security enforcement. Keep a valid request before changing permissions-related properties.
2.1.10.10 Continue from the interpreted result
| Observed result | Check before proceeding | Next numbered section |
|---|---|---|
| API objects expose role, ownership or security-sensitive properties | The server binds an untrusted property to a persistent security-relevant field without checking permission | §2.2.20 — Modify a protected property through excessive writable fields |
| A request selects an object by ID/path and two authorized ownership contexts are available | The server accepts a lower-privilege identity's request for an object it should not access | §2.2.18 — Cross an object-ownership boundary |
| An input appears in a command-like operation or causes shell-dependent behavior | Input reaches command execution with an exploitable parsing boundary; process identity/runtime can perform the selected proof | §2.2.11 — Prove visible or blind operating-system command injection |
| Database errors or controlled true/false response differences | Input reaches a SQL query; a valid request and stable response baseline exist | §2.2.12 — Establish SQL query influence and DBMS context |
| Untrusted input reaches an executable HTML/JavaScript context | Payload reaches a browser execution sink; any useful privileged action additionally needs a victim context, same-origin access and a valid request state | §2.2.21 — Execute browser code and validate a useful same-origin action |
| URL import, preview, webhook or fetch behavior | The application server performs a controllable request; destination/protocol policy and its network position permit the selected resource | §2.2.23 — Use server-side requests to inspect reachable internal behavior |
2.1.11 Sources and shared concepts
Supplied PEN-200 Ch 8 pp201–244. OWASP Web Security Testing Guide.
Commands and their adjacent variant conditions are synchronized extracts of the linked operational procedures. Those procedures own complete execution details; this guide owns method selection, explanations and worked reasoning. Tool availability on the learner's Kali or a target must be checked in that environment.