SSRF in URL Fields Fuzzer

Item	Description
Full Fuzzer Name	SSRFInUrlFieldsFuzzer
Log Key	SSRFIUF
Description	This fuzzer tests for Server-Side Request Forgery (SSRF) by sending attacker-controlled URLs in fields that are likely to be treated as URLs/URIs. It targets URL-type fields (schema format: uri / format: url) and fields whose names suggest URL content (e.g. callback, webhook, redirect, avatar, image). Payloads include localhost/internal services, cloud metadata endpoints (AWS/GCP/Azure), file protocol targets, and encoded IP variations to detect URL validation gaps and outbound request behavior.
Enabled by default?	Yes
Target field types	OpenAPI fields of type string with format: uri or format: url, plus string fields whose names match URL patterns (e.g., url, uri, link, endpoint, callback, webhook, redirect, file, image, avatar, logo, source)
Expected result when fuzzed field is required	4XX
Expected result when fuzzed field is optional	4XX
Expected result when fuzzed value is not matching field pattern	4XX
Fuzzing logic	Iteratively replaces each detected URL-type field with SSRF payloads and sends the request expecting 4XX: 1. Skips execution if the request payload is empty. 2. Identifies URL-like fields by schema (uri / url) or by name matching a built-in list of URL patterns. 3. For each URL-like field, injects a fixed list of SSRF payloads including: localhost/loopback variants, common internal ports, AWS/GCP/Azure metadata endpoints, internal hostnames, file:// URIs, DNS rebinding/bypass hostnames, and encoded IP forms (hex/decimal/octal). 4. Sends each payload one-at-a-time per field using simple field replacement. 5. Post-processes responses to detect strong SSRF indicators (reflection, metadata, file content, network/DNS/client errors, internal target leakage).
Conditions when this fuzzer will be skipped	When the request payload is empty OR no URL-like fields are found based on schema format or field name patterns.
HTTP methods that will be skipped	HEAD, TRACE
SSRF evidence detection	Flags a likely SSRF when response analysis finds one of the following: • Payload reflection: the exact SSRF URL appears in the response body. • Cloud metadata patterns: markers like instance-id, security-credentials, computeMetadata, service-accounts/default, subscriptionId, etc. • File content patterns: indicators like root:x:0:0, /bin/bash, /etc/passwd, /etc/shadow. • Network error leakage: connection refused, timed out, no route to host, network unreachable. • DNS error leakage: could not resolve host, getaddrinfo, name or service not known. • HTTP client error leakage: curl error, urlopen error, socket error, failed to connect. • Internal target mention: response contains internal host/IP fragments that also appear in the SSRF payload (e.g. localhost, 127.0.0.1, 169.254.169.254, metadata.google.internal).
Reporting	Reports error if: 1. SSRF indicators are detected in the response (reflection, metadata/file content, or outbound connection errors pointing to SSRF processing). 2. Server returns 5XX while processing SSRF payloads (may indicate attempted outbound connection or unsafe handling). 3. Any unexpected response code is returned. Reports info if: 1. SSRF payload is rejected with 4XX. 2. SSRF payload is accepted with 2XX but no SSRF indicators are found (still worth manual validation depending on API behavior).