Check the affected version, configuration, and exploit prerequisites.
Choose a bounded proof that avoids unnecessary changes.
Capture the request, response, identity, and observed effect.
Phase deliverable
A reproducible proof of a security boundary being crossed, or a documented negative result.
Document what you observed, the assumptions you tested, and what remains unverified.
Field method / Expanded guide
Work through the phase.
This guide uses a five-phase teaching model. PTES separates additional stages, and NIST uses a different lifecycle. The topics below adapt those ideas to the workflow here; they are not a claim that every framework uses these five names.
1. Verify applicability before executing a test
HOUSE LENS A door model associated with a faulty latch is only a lead; confirm that this house has that latch and that the weakness is reachable.
A version match or scanner alert needs validation against the actual environment.
Check the affected component, reachable code path, required identity, configuration, and expected observable result. Public exploit code may assume an operating system, architecture, or feature that the target does not have. Review side effects before using a module.
Create a control request or baseline first.
Prefer a proof using dedicated test records or a reversible action.
Define which result would falsify the hypothesis as well as which would support it.
2. Test horizontal and vertical authorization
HOUSE LENS Try the same room as two agreed guest identities: can one guest enter a room reserved for the other? Can a guest enter a keyholder-only room?
The important comparison is identity versus intended permission.
Horizontal authorization asks whether one peer user can access another user’s resource. Vertical authorization asks whether a lower-privilege user can invoke a restricted function. Use known objects and agreed accounts so you can establish the expected policy instead of guessing.
Confirm that user B owns the object and that sharing is disabled for the example.
Compare owner access, non-owner access, and unauthenticated access as separate cases.
A denial page returned with HTTP 200 is not successful unauthorized access.
3. Preserve the cause-and-effect chain
HOUSE LENS Change one condition in the entry test and observe the resulting access. A tool saying “open” is weaker than a reproducible crossing of the intended boundary.
Change one meaningful condition at a time so the result can be explained.
Retain the minimal request, response, and context needed to reproduce the issue. Where a result depends on application state, document how that state was created. Repeat the test against a fresh test object when practical; a cached or stale response can mislead the assessment.
Check response content and server-side effect, not status code alone.
Record whether a tool reported a candidate, completed a check, or actually demonstrated access.
Separate a failed exploit attempt from proof that a system is secure.
4. Bound impact and transition to the next phase
HOUSE LENS After entering the hallway, record where you are and what access you actually have before investigating the rest of the house.
Initial access provides a new viewpoint, not unlimited authorization.
If a test creates a session, document the resulting identity and access level before doing anything further. Determine which approved objectives can be assessed from that position. Some application findings need no host session; move directly to reporting when the evidence is sufficient.
Record test artifacts and their cleanup actions.
Use the smallest evidence sample that proves the finding.
Do not turn potential access to a dataset into a claim that all customer records were obtained.
5. Validate SQL injection through controlled differences
HOUSE LENS If a request is meant to be a label for a room, SQL injection is the application mistakenly treating part of that label as an instruction to its records system. The house picture is simplified; controlled response comparisons provide the real evidence.
The response should follow the tested condition rather than an arbitrary payload change.
For a suspected SQL injection, establish stable normal behavior first. Compare multiple logically true and false conditions, then check whether the difference follows the conditions across repetitions. Account for caching, changing data, errors, and timing noise. A quote-triggered error alone is not enough to conclude that arbitrary SQL can be executed.
Keep the parameter, request identity, and relevant application state constant.
Document the tested technique and actual observation; do not infer database extraction or OS access from detection.
For production systems, select the bounded test and request budget with the owner; “risk 1” is a tool setting, not a safety guarantee.
Tools / Practical reference
Commands, outputs, interpretation.
Use approved targets. These examples show representative behavior; output varies by environment. Angle-bracket values must be replaced. No command here guarantees a finding.
How to interpret it: If document 42 belongs to user B and user A has no permission, this response supports an access-control finding. Verify ownership and intended policy; HTTP 200 alone is insufficient. Replace the token locally and redact it from evidence.
How to interpret it: Search results depend on installed modules. Replace placeholders with a reviewed module. This example inspects metadata; it does not run an exploit or establish a session.
Compare owner and non-owner access to the same test object
Interpretation: Inspect saved files: the command writes responses rather than printing them. The secure example denies the peer. A 404 may also be valid. Unauthorized document content, after policy and ownership checks, supports a finding.
Inspect a specific module and its configurable options
Inspect a specific module and its configurable optionsCommand / authorized lab
msfconsole -q
search type:auxiliary http title
use auxiliary/scanner/http/title
info
show options
Expected output / illustrative
Module: HTTP HTML Title Tag Content Grabber
Options include RHOSTS, RPORT, SSL, TARGETURI
[exact options depend on installed version]
Interpretation: This example selects an HTTP information-gathering module and displays its options; it does not run an exploit. Module check/run actions must be reviewed separately; not every module has a check method.
GUI: Send an approved captured request to Repeater → change the test object ID → Send
CLI equivalent for a single request: curl -i https://app.example.test/api/documents/42 -H "Authorization: Bearer <LAB_TOKEN>"
Expected output / illustrative
Repeater displays the edited request and resulting response.
The endpoint, status, body and timing depend on the test.
Interpretation: Repeater is a GUI workflow, not a command-line program. Compare authenticated identities and known test objects; preserve the request that actually produced the result.
Check one input on an intentionally vulnerable lab
Possible vulnerable-lab summary:
Parameter: id (GET)
Type: boolean-based blind
[technique details and payload depend on DBMS]
A secure or unsupported case may report that the tested parameter is not injectable.
Interpretation: Run from a local sqlmap checkout against a deliberately vulnerable lab. -p selects the parameter; B limits the technique to boolean-based tests; delay spaces requests. No data-dump or OS-execution action is requested. Validate the reported behavior independently and record false-positive controls.
Interpretation / Common mistakes
Tool message versus demonstrated access
Tool message versus demonstrated access
Calling every HTTP 200 response an authorization bypass.
Treating a timeout as proof of time-based injection without controls.
Claiming data loss or a host session when the test showed neither.
Original guidance consulted for methodology and tool behavior. Commands and outputs on this page are illustrative lab examples, not output captured from these sources.
Use an agreed simulation to show that one entry point lets the assessor cross the outer boundary. Validate a particular weakness with a controlled test. This may be unauthorized application access rather than a shell on a host.
