url-parser-confusion-testinglisted

# URL Parser Confusion & SSRF Filter Bypass Different URL parsers disagree on how to interpret malformed URLs. When an application **validates with one parser** and **fetches with another** (or fetches with the same parser but mis-trusts its output), an attacker can craft a URL that passes the allowlist check but resolves to an attacker-chosen host → **Server-Side Request Forgery (SSRF)**. Targets must be within the scope of the engagement you are authorized to test. ## When to Use - URL validation, webhook inputs, and proxy/fetch endpoints (`/fetch?url=...`, `/preview?url=...`, `/webhook`) - Hostname allowlist / denylist bypass assessments - Microservice architecture audits where validation and HTTP client libraries differ (e.g. Node validator + curl/Go backend) - SSRF filter bypass assessments for cloud metadata endpoints (`169.254.169.254`, `metadata.google.internal`) or internal network ranges (`10.0.0.0/8`, `127.0.0.1`) - Reviewing C/C++, Python, Node.js, Go, Java, or PHP URL handling logic ## Reference Case: HackerOne #3923212 (curl URL API) libcurl's `parseurl()` in `lib/urlapi.c` misparses `http:///host/path`. Per RFC 3986 the authority between `//` and `/` is **empty**, so `/host/path` is the **path**. libcurl instead treats the first path segment as the **hostname** (slash counter reaches 3, `hostp` is set to whatever follows the third slash). ```bash # curl CLI reproduction (path becomes hostname) curl -w "\n%{url_effective}\n" http:///169.254.169.254/latest/me