Map functions, roles and normal requests manually

Needs: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

Client commands / example output

# Baseline
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

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.

Verify → Retain method, route, input location, identity and expected normal behavior; do not infer vulnerability from an interesting parameter name.

If it fails → Expired sessions, CSRF failures and malformed requests can imitate access-control differences; reproduce a valid baseline first. More detail ↓

If → then

A request selects an object by ID/path and two authorized ownership contexts are available → Cross an object-ownership boundary
Needs: The server accepts a lower-privilege identity's request for an object it should not access
A download/path parameter or URL segment influences a local filename → Read files through directory traversal
Needs: Untrusted path reaches a filesystem read outside its intended directory; process identity can read the requested file
An upload/import/attachment function → Establish upload acceptance, storage and retrieval
Needs: A valid upload request and permitted account; the server accepts and stores controlled bytes
Controlled input appears in a server-rendered template, preview, email or report → Prove server-side template evaluation and identify its engine
Needs: The application evaluates attacker-controlled template syntax and the selected engine exposes a useful object or function
A working XML request reaches a server-side parser that accepts a controlled document or field → Use an XML parser's external-entity behavior for bounded file read
Needs: External entity or XInclude processing is enabled and the parser identity can read the selected file
A login or search accepts JSON/nested form properties and evidence suggests an operator-based document query → Test structured NoSQL operator injection with identity controls
Needs: The framework preserves an attacker-controlled operator object and the query uses it without rejecting its type
Source or request evidence shows controlled serialized PHP data reaches unsafe unserialize → Match PHP deserialization gadgets to installed dependencies
Needs: Required gadget classes and compatible dependency versions are loaded; transport preserves exact serialized bytes
Source or errors identify server-side Python YAML loading of controlled content → Validate unsafe YAML object construction
Needs: The application uses an unsafe PyYAML loader that permits the selected Python object constructor
A real CGI endpoint invokes Bash and component/patch evidence supports the vulnerable family → Test Shellshock only through a confirmed CGI-to-Bash chain
Needs: HTTP-derived environment data reaches an affected Bash process and the selected command is available
An application has unlinked paths, backups or administration endpoints → Discover directories and files with controlled response filtering
Needs: Correct base URL/session and a measured nonexistent-path response; bounded relevant wordlist

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Map functions, roles and normal requests manually

USE WHEN: Forms, downloads, exports, account functions or role-specific interfaces
STARTING ACCESS: A reachable HTTP application and recorded anonymous or authenticated request state
RESULT: An input/function/role map with concrete attack hypotheses

Recognize the clue

Browse the site's normal account, export, upload and download features while recording requests in the browser/proxy.

curl -sk -b cookies.txt -D response-headers.txt http://TARGET:PORT/PATH

SYNTHETIC EXAMPLE OUTPUT

Observed browser request:
GET /download?file=report.pdf
Cookie: SESSION_COOKIE

Means: The normal request exposes a file-selecting input discovered through functionality, not guessed from a payload list.

Confirm: Find the actual input semantics, account/role and normal response before file/read/authorization tests.

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.
Still inconclusive: Unknown ownership or an expired session prevents interpreting differences; re-establish the baseline.

Troubleshooting: Expired sessions, CSRF failures and malformed requests can imitate access-control differences; reproduce a valid baseline first.

For every visible function, capture one unchanged request in Burp Proxy history, send it to Repeater and record:

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.

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.

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.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗