14.3 LFI/RFI, Web Shells, API Abuse, JWT, and Session Hijacking

The rest of PT0-003 4.5 is file-backed execution, API and token abuse, and session attacks: local file inclusion (LFI), remote file inclusion (RFI), web shells, arbitrary code execution (ACE), API abuse, JSON Web Token (JWT) manipulation, session hijacking, plus brute-force and collision against application secrets. CompTIA lists ACE as an attack type; on this exam treat it as the impact several of these techniques produce, not as a separate brand of payload. You still intercept with Burp Suite or ZAP. You still discover hidden upload paths with Gobuster, DirBuster, or Wfuzz. You do not paste web-shell source into a finding.

LFI versus RFI versus web shell versus ACE

Local file inclusion uses an include, require, or template-path parameter to pull a file already on the server. Identification: a page or language parameter such as ?page=help that will also take a local path and return file contents — source, configuration, or a well-known operating-system file in an authorized test. LFI is disclosure first. It becomes ACE when the included local file is attacker-controlled (an uploaded document the engine will parse, a log the tester can write). You do not need a recipe for log poisoning; know that LFI plus a writable local file is how inclusion becomes execution.

Remote file inclusion is the same include feature pointed at a remote URL, historically when a language setting such as allow_url_include — or an equivalent "fetch this URL and evaluate it" — is enabled. Identification: the parameter accepts a remote URL and the application fetches it. Impact is ACE because the remote resource can be code. If remote includes are disabled, the finding is LFI, not RFI. Exam trap: labeling every ?file= parameter RFI. Trap two: calling traversal LFI. Parent-directory sequences that download a file are directory traversal (previous section). LFI is the include function treating that path as code or as a rendered template.

A web shell is an uploaded or included command page — a small application file that takes a parameter and runs it as the web user. On 4.5 it arrives through unrestricted upload, a writable include directory, or RFI/LFI that lands a page. Objective 5.1 also lists web shells as a backdoor persistence mechanism. On 4.5 you identify the application flaw that allowed the page. On 5.1 you discuss keeping it. Do not write web-shell source in a report or on this exam. Describe the upload or include, the resulting ACE, and the control that was missing (type allowlist, execution location outside the web root, authentication on the upload).

Arbitrary code execution is what you call the impact when the application runs the tester's code: command injection, SSTI, unsafe deserialization, RFI, a web shell, or a file upload the server executes. ACE is not "the Metasploit logo." If the stem shows a language include of a remote URL, the attack type is RFI; ACE is the impact. If the stem shows an uploaded command page, the attack type is a web shell; ACE is still the impact.

API abuse

API abuse on 4.5 is using the interface as designed, but without the authorization, rate limit, or field control the business needed.

• BOLA / IDOR on APIs: change /api/v1/users/1001 to 1002 with the same bearer token. This is the API spelling of the previous section's IDOR.
• Mass assignment: the client sends extra JSON fields (isAdmin, role, balance) and the server binds them because the framework mapped the whole body.
• Missing rate limit: password reset, one-time passcode, or login endpoints that accept thousands of guesses — the brute-force bullet applied to APIs.
• Broken authentication: missing auth on an admin route, HTTP-verb tampering, or trusting a client-supplied user-id header.

Postman is the 4.5 API client. Collection runners replay parameterized requests and Authorization headers. Burp and ZAP still intercept the browser or sit as a proxy in front of Postman. Exam trap: answering sqlmap for every JSON 500. Trap two: answering BloodHound. BloodHound graphs Active Directory, not REST object ids. Trap three: answering WPScan because the API is written in PHP. WPScan is WordPress-specific plugin, theme, and user enumeration.

JWT manipulation

A JSON Web Token is a header, payload, and signature. PT0-003 cares about broken validation, not minting a tutorial token.

• Algorithm none: the header claims the token is unsigned; a naive library accepts modified claims with an empty signature.
• Weak secret: HMAC tokens signed with a guessable passphrase. Brute-force recovers the secret; collision thinking applies when the hash or truncated MAC is too small. TruffleHog may already have found that secret in a Git repository or an application .env committed years ago.
• Missing exp / aud checks: expired tokens still work; a token minted for app A is accepted by app B.

Pass-the-token (objective 4.3) reuses a valid stolen access, refresh, or session token. 4.5 JWT manipulation is breaking validation. Burp or ZAP is the intercept; Postman is how you replay the modified Authorization header. Exam trap: calling every Bearer token Kerberos. Trap two: treating TruffleHog as an HTTP intercept proxy.

Session hijacking, brute-force, and collision

Session hijacking is using a victim's session identifier as your own. Theft paths: XSS-stolen cookies, an unencrypted cookie on the wire, a token in a URL, or session fixation (force a known id, then wait for the victim to log in). Impact: you are the user until expiry or rotation. CSRF uses the victim's browser; hijacking uses the identifier in your client. Rotate session ids at login, set cookie flags the exam expects you to recognize (HttpOnly, Secure, SameSite), and do not put session ids in URLs.

Brute-force on 4.5 is not only a 4.3 Hydra SSH story. Application brute-force is password forms, short numeric OTPs, predictable password-reset tokens, and short session ids. Missing API rate limits make it cheap. A stem that shows ten thousand POST /login attempts with no lockout is brute-force, not SQLi, unless the body also contained query syntax.

Collision attacks matter when the application uses a weak hash or a short identifier. Two different inputs that hash to the same value, or a session-id space small enough that a tester can land on a live id, are collision or brute-force problems. They are not SQLi. They are why session identifiers need cryptographically strong length and why password hashes need a slow algorithm — identification, not a collision-lab write-up. Weak HMAC secrets on JWTs sit in the same bucket: the algorithm is fine, the secret is guessable, TruffleHog or brute-force explains why.

4.5 tool matching (hard)

Worked matching

free PenTest+ practice questionsPractice questions with detailed explanations