API7:2023 — Server Side Request Forgery

Slide 6 · Why It Happens

Trust flows the wrong direction. The server trusts the URL it’s told to fetch.

Four root causes that turn a URL-fetching feature into an SSRF vulnerability.

❌

No URL validation before fetching

The server takes the user-supplied URL and passes it directly to an HTTP client library (curl, requests, fetch, HttpClient). No check: is this a permitted host? Is this a private IP? Is this a permitted protocol?

❌

Blocklist instead of allowlist

The developer blocks “obvious” internal addresses: 127.0.0.1, localhost, 169.254.169.254. Attackers bypass with: decimal notation (2130706433 = 127.0.0.1), URL encoding, IPv6 (::1), DNS rebinding, or redirects to internal IPs.

❌

Following HTTP redirects automatically

The URL validation checks the original URL and it passes. The fetch follows a redirect (302) to an internal address. The library fetches the redirect destination — bypassing the validation entirely.

❌

Returning full server responses to the client

The server fetches the URL and returns the raw response body to the API caller. If the URL was a metadata endpoint, the caller receives the credentials. If it was a config file, the caller receives the secrets.

The invisible network boundary

Developers build URL-fetching features thinking about external URLs. They don’t think about the fact that the server is inside the network and can reach internal services that have no auth because they’re “trusted.” The boundary they forgot exists is the one between the internet and the internal network — and the API server straddles it.

← Back Who does this affect? →