SSRF — When a Server Makes the Wrong Call

TL;DR

• What: SSRF happens when an application lets a user supply a URL, and the server fetches it.

• Why it’s bad: The server sits inside a trusted network, so it can be tricked into calling localhost or internal services you can’t reach from the internet.

• Impact: Read “internal-only” data, scan private networks, hit cloud metadata endpoints, pivot to other attacks.

• Fix: Allowlist destinations, block private/loopback IPs, restrict protocols & redirects, pin DNS, and add egress firewalls + logging.

A simple story: “The messenger who trusts every address”

Think of your app as a helpful messenger. Users hand it an address (a URL), and it dutifully runs to fetch the content.
One day, a clever stranger gives the messenger a special address: “please deliver this to your own back door and bring me whatever you find there.”
Because the messenger lives inside the building, it can open doors outsiders cannot. It grabs a note from a private room and brings it back.
That’s SSRF: the attacker can’t reach the private room directly, but they convince your server—which can—to go there on their behalf.

What exactly is SSRF?

Server-Side Request Forgery is a class of bugs where the server performs a network request to a user-controlled URL. If not restricted, attackers can:

• Reach localhost (127.0.0.1, ::1) services (admin panels, dev dashboards).

• Reach private subnets (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

• Query link-local/special IPs (e.g., cloud instance metadata).

• Sometimes abuse non-HTTP protocols (if the stack allows them).

Two common flavors:

• Classic SSRF: you see the internal response in the app’s output.

• Blind SSRF: no visible response; success is inferred (e.g., via DNS logs or timing).

Where SSRF often appears

• “Fetch a URL” features: link previewers, image fetchers, PDF/thumbnail generators.

• Webhooks and integrations that pull data from third-party URLs.

• “Import from URL” in CMS/commerce backends.

• Microservices that offer proxy or redirect functionality.

Why it’s powerful (even without code execution)

• Data exposure: internal flags, config pages, health checks, open dashboards.

• Network pivot: internal port scanning via timing/response differences.

• Cloud secrets: access to metadata services if not locked down.

• Chaining: SSRF can be combined with deserialization, template injection, or misconfigured credentials for bigger impact.

How attackers make requests sneak past filters

• Alternate IP notations: 127.1, decimal 2130706433, hex 0x7f000001, IPv6/IPv4-mapped.

• Redirects: start at an allowed host, then 301/302 to private IPs.

• DNS tricks: DNS rebinding—hostname resolves to a public IP first, then to a private IP.

• Protocol confusion: file://, gopher://, etc. (depends on your stack).

Never test outside your own lab or with explicit permission.

How to defend

1. Hard allowlist of destinations
   Only permit requests to specific hosts/paths you control. Avoid “allow any URL”.

2. Block dangerous IP ranges (v4 & v6)
   Reject loopback, link-local, private, multicast, and unrouted ranges. Re-validate on every redirect.

3. Pin DNS & re-check redirects
   Resolve the hostname once, connect to that IP (avoid DNS rebinding), and disable or cap redirects.

4. Restrict protocol & method
   Allow http/https only; disallow file://, gopher://, etc. Enforce short timeouts and response size limits.

5. Egress network controls
   Firewalls/proxies so the app cannot reach private ranges or metadata endpoints unless explicitly needed.

6. Cloud hardening

   • AWS: enforce IMDSv2, least-privilege IAM roles.

   • GCP/Azure: require protective headers/firewalling for metadata; least privilege everywhere.

7. Observability
   Log full target (scheme, host, resolved IP). Alert on requests to private/link-local ranges, weird encodings, or sudden spikes.