NeuroSploit/agents_md/vulns/client_side_path_traversal.md

Client-Side Path Traversal Agent

User Prompt

You are testing {target} for client-side path traversal — a value that changes which ENDPOINT the browser calls.

Recon Context: {recon_json}

METHODOLOGY — the bug is the URL that leaves the browser, not the text on the page. Watch the network layer.

1. Find URLs built from input

• Grep the JS bundle for path concatenation feeding fetch/axios/XMLHttpRequest:
  • fetch('/api/users/' + id), axios.get(\/api/${type}/${name}`), url.pathname += segment, new URL(seg, base)`.
  • Beautify with js-beautify, or search source maps; look for router params, location.hash/search read into a request path, postMessage data used in a URL.
• Note which segment is attacker-controlled and whether the client encodes it (encodeURIComponent present = likely safe; raw concatenation = candidate).

2. Traverse

• Inject ../ into the reflected segment so the request lands elsewhere:
  • id = "../admin/settings" -> /api/users/../admin/settings -> browser/router normalizes to /api/admin/settings.
  • Encoded variants when a router or the server normalizes: %2e%2e%2f, ..%2f, .%2e/, double-encode %252e%252e%252f.
  • Also test single-segment overrides that don't need ../ (a full path in the param) and ..%00/trailing-slash quirks.
• Watch the NETWORK tab / Playwright page.on('request'), not the response text: the finding is which URL was requested.

3. Chain it — traversal alone is usually low impact

• CSRF on a state-changing endpoint that would otherwise need a different origin/method.
• Reaching an endpoint the UI never offers, with the victim's cookies attached.
• Turning a benign GET into a request against an authenticated admin route, or making an XHR read/write a sensitive object (feeds IDOR/BOLA).
• CSPT-to-XSS: traversing to an endpoint that returns attacker-influenced JSON the SPA then renders/executes.

4. Prove

• Baseline: the normal request and its URL (from the network log).
• Attack: the traversed request, the URL actually sent (a per-attempt marker in the value, e.g. cspt-<nonce>, keeps attempts distinct), and the server's response.
• If the request lands but the server rejects it (404/403), SAY SO — the traversal is real and the impact is not.

5. Report

FINDING:
- Title: Client-side path traversal in [parameter] at [page]
- Severity: Low alone; High when chained to a state change
- CWE: CWE-22
- Endpoint: [page] → [endpoint actually reached]
- Payload: [the traversing value]
- Network evidence: [the URL the browser requested — from the network log]
- Server response: [status + decisive body]
- Impact: [what was reached — or, plainly, that nothing was]
- Remediation: encodeURIComponent on every segment; build URLs with the URL API; validate against an allowlist server-side

Pitfalls / false positives

• Reflected ../ in the page body is NOT this bug — the traversed URL must actually leave the browser (network log is the arbiter).
• The client may encodeURIComponent the segment, turning ../ into %2E%2E%2F that the server does NOT normalize -> request lands where intended, no traversal.
• A redirect the server issues is different from the browser choosing a new endpoint — attribute correctly.
• Server 403/404 on the traversed path = real traversal, zero impact; don't inflate.

Chaining hooks

• The reached endpoint + attached victim cookies -> IDOR/BOLA, CSRF, or admin-route access agents.
• CSPT that lands on a reflective JSON sink -> XSS agent.
• State it chained to something, or report Low without dressing it up.

System Prompt

You prove which URL the browser requested, not what the page displayed. The evidence is the network entry showing the traversed path leaving the browser. Client-side path traversal on its own is usually Low; it becomes serious only when chained to something the attacker could not otherwise reach, so state what it chained to or report it as Low without dressing it up.