Server-side request forgery (SSRF)

Some features make the server fetch a URL on your behalf: import an image from a link, send a webhook, generate a preview of a page, pull an avatar from a URL, fetch SSO metadata. If you control that URL, you can make the server request things it can reach but you cannot, internal services, admin panels, and the cloud metadata endpoint that hands out credentials. This is Server-Side Request Forgery, SSRF.

Why it is powerful#

Your machine sits outside the target's network. The server sits inside it, behind the firewall, next to databases, internal APIs, admin dashboards, and, in the cloud, a special metadata service. SSRF turns the server into your proxy into that trusted zone: you say "fetch this URL", it fetches from its network position, and it hands you (or acts on) the response. A request you could never make from outside, the server makes for you from inside.

The classic jackpot: cloud metadata#

Cloud servers expose an internal metadata endpoint at a fixed address, http://169.254.169.254/, reachable only from the instance itself. It serves configuration and, critically, temporary credentials for the instance's cloud role. If you can point an SSRF at it:

url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

the server fetches its own cloud credentials and returns them to you. Those keys often unlock storage buckets, databases, and more of the account. This is the single highest-impact SSRF outcome, and the first thing to try when you find a fetch you control on cloud-hosted infrastructure.

Finding SSRF#

Hunt for anywhere the server fetches a URL derived from your input:

• Explicit URL fields: url, uri, link, src, dest, feed, webhook, callback, proxy, image.
• "Import from URL" / "fetch from link" features: import a document, avatar-from-URL, "add by RSS".
• Link previews / unfurlers that fetch a page to show a thumbnail.
• PDF/screenshot generators that render a URL.
• Webhooks you can point anywhere.
• SSO/SAML metadata URLs and any XML that can reference external resources (overlaps with XXE, next lesson).

Confirm it by pointing the URL at a server you control and watching for the request to arrive, that proves the server fetches your URL (and whether it follows redirects, what user-agent it uses, whether it is blind).

Reaching internal targets, and bypassing the allow-list#

Once you have a fetch you control, aim it inward:

• Internal hosts and ports: http://127.0.0.1:port/, http://localhost/admin, internal hostnames, other private-range IPs. Ports and paths that answer reveal internal services.
• Cloud metadata: the 169.254.169.254 endpoint above.

Careful apps put an allow-list or block private IPs, and testers bypass those filters, a whole craft:

• Redirects: the app checks your URL is external, then follows a redirect from your server to an internal one.
• Alternate IP encodings: decimal, octal, hex, or shortened forms of 127.0.0.1 and 169.254.169.254 that the filter does not recognise but the fetch library resolves.
• DNS rebinding: a hostname you control that resolves to an allowed IP at check time and an internal IP at fetch time.
• Odd schemes and tricks: http://[::1], adding a userinfo part (http://expected@internal/), or a trailing dot.

A rejected URL is a filter, not a closed door.

Blind SSRF#

Sometimes the server fetches but never returns the response to you. That is blind SSRF, and it is still useful: an out-of-band callback (the server hits your listener) confirms it, port-scanning by timing reveals internal services, and hitting an internal endpoint that does something (a webhook that triggers an action) can have impact even without reading the response. As with blind SQLi and command injection, an out-of-band interaction is your confirmation.

The honesty gate#

The finding is making the server reach somewhere it should not. Prove it with the least intrusive request: a callback to your own listener, a read of the metadata endpoint (report that credentials are reachable, you may need to show one to prove it, but do not then go using those keys to rifle through the cloud account beyond confirming access, per the program's rules), or evidence an internal host responded. Do not scan the whole internal network or pivot into internal systems beyond what is authorised. On this Academy's labs, explore freely.

Your labs#

Three SSRF labs, escalating: LinkPeek URL preview SSRF is the clean case, a preview feature that fetches your URL, where you aim it internally. SnapProof webhook SSRF uses a webhook as the fetch sink. GreenGrid firmware-import redirect SSRF adds the bypass skill: an allow-list you defeat with a redirect. Do LinkPeek first for the concept, then the other two for the sinks and the bypass.

Where this goes next#

SSRF often rides on data the server parses. The next lesson goes after the parser itself: XXE, where an XML document you supply tells the parser to read files and make requests, file disclosure and SSRF through the XML layer, plus a look at testing web services.