SSRF: Making a Server Fetch Things It Should Not, and How to Stop It

Server-Side Request Forgery tricks a server into making an HTTP request the attacker chooses. The server is the one that connects, so the request comes from inside the network with whatever access the server has — which is the entire point. SSRF turns a web application into a proxy into places the attacker cannot reach directly.

Where it comes from

Applications fetch URLs for legitimate reasons: importing an image from a link, rendering a page to PDF, validating a webhook endpoint, retrieving an XML schema, previewing a shared link. Any feature that takes a URL from a user and retrieves it is a candidate.

It also appears indirectly through document parsers, XML processing with external entities enabled, and libraries that follow redirects without the developer realizing a fetch is happening at all.

Why it is severe

Internal network access. The server can reach private address ranges the internet cannot. An attacker can enumerate internal hosts and ports by observing response times and error messages, and reach administrative interfaces that were "safe" because they were internal only.

Cloud metadata endpoints. This is the case that turns SSRF from serious to critical. Cloud platforms expose an instance metadata service at a fixed link-local address that returns instance details and, crucially, temporary credentials for the role attached to that instance. An SSRF that reaches it retrieves working cloud credentials, and from there the attacker has whatever permissions that role holds — often far more than anyone intended.

The defence at the platform level is the newer session-oriented metadata service, which requires a PUT request with a specific header before it will answer. Simple SSRF that can only issue GET requests fails against it, which is why enforcing it rather than leaving the older version enabled is one of the highest-value cloud hardening settings there is.

Other protocols. Where the fetching library supports more than HTTP, an attacker may reach file, gopher, ftp or other schemes, and read local files or interact with non-HTTP services.

Blind SSRF returns nothing to the attacker, but timing differences and out-of-band interactions — a DNS lookup arriving at a domain the attacker controls — confirm the request happened and can still exfiltrate data one lookup at a time.

Why blocklists fail

The instinctive fix is to reject requests to internal addresses. Attackers have a long list of ways around it.

Alternative representations of the same address — decimal, octal, hexadecimal, IPv6-mapped forms, shortened notations — all resolve to the same place while failing a string comparison. A domain name the attacker controls can simply resolve to an internal address. Redirects move a request from an allowed destination to a forbidden one after validation has passed.

Worst is DNS rebinding: the attacker's domain resolves to a legitimate external address when the application validates it, and to an internal address moments later when the request is actually made. The check and the connection use different answers, and no amount of validating the hostname fixes it.

What works

Allowlist destinations. Where the application needs to fetch from a known set of hosts, permit exactly those and nothing else. This is the only approach that does not depend on enumerating every representation of badness.

Validate after resolution, and connect to what you validated. Resolve the hostname, check the resulting IP address against forbidden ranges, and then connect to that address rather than re-resolving — which closes DNS rebinding. Disable redirect following, or re-validate every hop.

Restrict at the network layer. The most robust control, because it does not depend on application code being correct. Egress filtering from the application tier so it can only reach what it needs, and specifically cannot reach the metadata endpoint or internal management ranges. An SSRF in a segment that can reach nothing interesting is a low-severity finding.

Limit the schemes to http and https, and configure the fetching library rather than trusting its defaults.

A WAF catches obvious payloads and is trivially bypassed by encoding, so it is a delay rather than a control — the same position as with file inclusion, where the real fix is also refusing to let user input select a destination.

Detection

Outbound connections from application servers to internal addresses they have no reason to contact, requests to the metadata endpoint from anything other than the instance's own legitimate tooling, and DNS lookups for attacker-controlled domains originating from server infrastructure. Feed application egress logs into your SIEM — a web server initiating connections it never normally makes is a strong signal and an easy rule.

Exam angles

Define SSRF as inducing a server to make attacker-chosen requests, and know that its severity comes from the server's network position. Identify cloud instance metadata as the highest-impact target and credential theft as the outcome. Know blind SSRF as the variant with no direct response. Recognize that blocklists fail to encoding, redirects and DNS rebinding, and that destination allowlisting plus egress network restriction are the effective controls.