14.2 CSRF, SSRF, Deserialization, IDOR, and Directory Traversal

Objective 4.5 continues with attacks that are not injection even though they still abuse HTTP. This section is cross-site request forgery (CSRF), server-side request forgery (SSRF), deserialization, insecure direct object reference (IDOR), and directory traversal. Brute-force and collision against session material wait until the next section with JWT and session hijacking. File inclusion is also next: traversal walks a path; inclusion includes or executes a file. Exam items here are differentials. They ask who sent the request and what identifier you changed.

CSRF: forge the logged-in browser user's request

CSRF tricks a victim's browser into sending a request the victim did not intend to a site where they are already authenticated. The browser attaches the session cookie. The application sees a genuine logged-in user. Identification: a state-changing action — password change, fund transfer, email swap, OAuth grant — that relies only on cookies, with no unguessable anti-CSRF token, SameSite restriction, or custom header that a third-party page cannot set.

Impact: the victim performs the action. The tester did not steal the cookie first; that would be session hijacking. CSRF uses the existing session in the victim's browser. Exam trap: calling CSRF XSS. XSS executes script in the application's origin. CSRF does not need script in origin if the browser will auto-submit a cookie. Trap two: calling CSRF SSRF. CSRF's client is the user's browser. SSRF's client is the application server.

Defenses you should recognize, not implement as a how-to: synchronizer (anti-CSRF) tokens, SameSite cookies, and requiring a request header that third-party sites cannot set. Burp Suite and ZAP are how you observe whether the action is cookie-only. If the intercept shows a random token that the third-party page cannot read, CSRF failed — that is the control working.

SSRF: make the server request an internal URL

SSRF occurs when the application fetches a URL the tester influences — a webhook, thumbnailer, PDF renderer, or "import from URL" feature — and the server is the HTTP client. The tester points that fetch at an address the tester could not reach directly: cloud instance metadata at 169.254.169.254, an internal admin port, a link-local orchestrator, or another scheme the library still honors.

169.254.169.254 is the exam's classic cloud-adjacent SSRF example. CompTIA also lists metadata-service attacks under 4.6. On 4.5, the finding is still SSRF: the web application was the proxy. On 4.6, you talk about IAM credentials and the metadata service as a cloud control-plane issue. Do not skip the address because "cloud is the next chapter." Do not write a full metadata harvest chain; identification is enough: a server-side fetch to a link-local or internal URL.

Impact: internal port mapping, reading metadata, hitting admin APIs that trust the virtual network, and sometimes ACE if the internal service is dangerous. Remediation: allowlist outbound URLs and schemes, block link-local and private destinations from that feature, and do not attach cloud-role credentials to a renderer that fetches user URLs. Exam trap: answering CSRF because "a request was forged." Ask whose HTTP client it was. Trap two: answering sqlmap because the thumbnailer returned a 500.

Deserialization: untrusted object graphs execute gadgets

Deserialization attacks reconstruct an object graph from bytes the client supplied — native Java serialization, PHP unserialize, Python pickle-style payloads conceptually, or a similar language format. If the application deserializes untrusted data, a gadget — existing code the object graph can reach during reconstruction or first use — may run. Identification: content types or parameters that look like serialized objects, language magic headers, or framework session blobs, and a change to that blob that alters server behavior without a normal form field.

Impact is often ACE. You do not need to author a gadget chain for PT0-003. The exam wants the class: untrusted deserialization is unsafe, gadgets are code already on the classpath, and the fix is not to deserialize untrusted input (or to use a safe format with an allowlist of types). Exam trap: calling every JSON API "deserialization ACE." Mapping JSON onto a data-transfer object without invoking attacker-chosen class constructors is not automatically a gadget runner. Native language serialization is the usual 4.5 picture. Trap two: calling deserialization JWT alg none. JWT is a signed token format in the next section, not a native object graph.

IDOR: change 1001 to 1002

Insecure direct object reference is missing authorization on an object identifier. The tester is authenticated as user A, opens /invoices/1001, then changes the id to 1002 and receives user B's invoice. The application trusted that anyone who knew or guessed the id was allowed to read it. Identification is that simple. Impact is horizontal privilege (peer data) or vertical privilege (admin objects). IDORs on APIs are the same class and overlap broken object level authorization (BOLA) in the next section.

IDOR is not directory traversal. Traversal uses ../ to leave a directory. IDOR uses a business identifier. It is not SQLi unless the id is also concatenated into SQL — then you may have two findings. It is not CSRF: the tester is using their own session, not the victim's browser. Burp or ZAP replay of /invoices/1002 is the proof. Gobuster is not required, but content discovery may have found /invoices/.

Directory traversal: parent-directory sequences to files

Directory traversal (path traversal) injects ../ sequences, or encoded equivalents, so a file API reads outside the intended directory. Identification: a download, image, or template parameter that takes a file name, and parent-directory sequences cause a different file to be returned — often a well-known operating-system or application configuration file in an authorized test. Impact is disclosure. If the same parameter later includes the file as code, you have crossed into local file inclusion (next section). Traversal that only downloads web.config is still traversal, not a web shell.

Gobuster, DirBuster, and Wfuzz are 4.5 content-discovery tools. They brute-force hidden paths, backup files, and admin panels so you have a surface to test for traversal, IDOR, or inclusion. Wfuzz also fuzzes parameters. Discovering /backup/web.config.bak is still discovery until you prove the download or the ../. They are not sqlmap, not WPScan, and not TruffleHog.

Worked matching

The intranet app has a "change email" POST with only a session cookie: CSRF if a third-party page can submit it. A PDF previewer that fetches https://169.254.169.254/ is SSRF, and you will mention metadata again on 4.6 without treating the 4.5 name as optional. A Java session cookie that is a native serialized object and that changes server control flow when tampered is deserialization, not JWT manipulation. /api/orders/1001 to /api/orders/1002 as another customer is IDOR. A download parameter with parent-directory sequences plus a sensitive filename is directory traversal. Gobuster found /download; Burp or ZAP proved the ../. sqlmap is the wrong logo unless a SQL error appeared. Sequence on the exam: name who sent the request, then name what identifier moved.