Overview
Whether a server-side fetcher is vulnerable depends on its URL validation — how it restricts the destinations it will fetch. This lesson covers assessing URL validation.
Learning objectives
- Explain URL validation in SSRF defense.
- Identify weak validation that enables SSRF.
- Assess validation safely and in-scope.
Core concept
URL validation is how a server-side fetcher restricts which destinations it will request. Strong validation uses an allowlist of permitted destinations and safely handles the URL (parsing, canonicalizing, checking the resolved host, not blindly following redirects) — from the web-security SSRF module. Weak validation — no restriction, a bypassable blocklist of internal ranges, or checks that miss alternate encodings/redirects/DNS tricks — enables SSRF. Assessing the fetcher's URL validation (safely, in-scope) determines whether it can be pointed at unintended destinations.
How it works
The researcher assesses how the fetcher validates the destination: does it allow arbitrary URLs (no/weak restriction)? Does it merely blocklist internal ranges (bypassable via encodings, redirects, or DNS resolving to internal addresses)? Or does it properly allowlist permitted destinations and validate the resolved host safely? Testing is done safely and in-scope — checking whether the fetcher's validation can be induced to accept an unintended destination, without actually attacking internal systems or exfiltrating data (proving the validation is weak/bypassable is the goal, done minimally). Weak or bypassable validation indicates SSRF; robust allowlisting indicates the fetcher is likely safe.
Practical example
Testing an in-scope "import from URL" fetcher, the researcher assesses its URL validation. They find it uses a blocklist attempting to ban internal IP ranges but does not account for alternate encodings or redirects — a bypassable validation that indicates SSRF. They demonstrate the weakness safely and minimally (showing the validation can be induced to accept an unintended destination) without actually reaching or harming internal systems. Had the fetcher used a strict allowlist with safe resolution, it would likely be secure. The validation assessment revealed the SSRF.
Cybersecurity relevance
Assessing URL validation is central to SSRF hunting: the fetcher's validation strength determines whether SSRF exists. Blocklist-based validation is notoriously bypassable (encodings, redirects, DNS), while allowlisting permitted destinations (with safe resolution) is robust — directly reflecting the web-security SSRF defense lessons. Finding weak/bypassable validation is a high-value SSRF finding; the fix is allowlisting plus network isolation. Testing must be safe and in-scope — proving the validation is weak without attacking internal systems or exfiltrating data. Understanding URL validation guides both finding SSRF and recommending its fix.
Common mistakes
- Not assessing the fetcher's URL validation, missing whether SSRF exists.
- Assuming a blocklist is sufficient (it's bypassable) vs recognizing allowlisting is the robust approach.
- Actually attacking internal systems or exfiltrating data instead of safely proving weak validation.
Key takeaways
- URL validation restricts a fetcher's destinations; strong validation allowlists permitted destinations and safely resolves the URL, while weak/blocklist validation is bypassable and enables SSRF.
- Assess the fetcher's validation safely and in-scope — proving it can be induced to accept an unintended destination, without attacking internal systems or exfiltrating data.
- Weak validation is a high-value SSRF finding (fix: allowlisting + network isolation); this reflects the web-security SSRF defense lessons.
Check your understanding
- Why is blocklist-based URL validation bypassable, and what is the robust alternative?
- How can weak URL validation be demonstrated safely without attacking internal systems?