SSRF: when your server makes requests for the attacker

Definitions follow OWASP and CWE-918. Not to be confused with CSRF, which forges requests from the victim's browser.

1. The application fetches a URL from input. To show a preview, download an image or call a webhook.
2. The attacker supplies an internal address. A private range, localhost, or a name that resolves to one.
3. The server makes the request. From inside the network, with whatever access the server has.
4. The response comes back, or its effect does. The attacker reads the result directly, or infers it from timing and errors.

The server becomes a proxy into places the attacker cannot reach. In cloud environments, the most damaging target is usually the metadata service, which can return temporary credentials for the server's role.

In basic SSRF the application returns the fetched content, so the attacker reads internal pages directly. In blind SSRF nothing is returned; the attacker learns from response times and error messages which addresses answer, or triggers actions on internal services that do not need a reply.

Blind SSRF is easy to dismiss and still dangerous: an internal endpoint that changes state on a simple request can be triggered without the attacker ever seeing the result.

Link previews fetch a page to show its title and image; given an internal address, they fetch an internal page instead. Image import by URL downloads whatever the address returns. Webhooks call a URL the customer configured, which may be an internal one.

Document converters that render HTML into PDF are a quieter case: the HTML can include references the renderer fetches while drawing the page. Any feature that turns user-supplied addresses into server-side requests belongs on the list to review.

A filter can match obvious internal targets in a parameter: loopback, private ranges, metadata addresses. That catches careless attempts.

It misses what only becomes internal later: a public name that resolves to a private address, an allowed host that redirects inward, or an address written in an unusual notation. The decision has to be made at the moment the server connects, which is inside the application.

1. Do not fetch arbitrary URLs. Where possible, allow only a fixed list of hosts the feature needs; the OWASP SSRF Prevention Cheat Sheet starts here.
2. Check the resolved address before connecting. Refuse private, loopback, link-local and other special-purpose ranges listed in RFC 6890.
3. Do not follow redirects blindly. Re-check every hop, or turn redirects off.
4. Isolate the fetcher. Run URL fetching from a network segment that cannot reach internal services.
5. Protect the metadata service. Use the cloud provider's hardened mode that requires a session token.