Server-Side Request Forgery (SSRF) occurs when a web application accepts a URL or network address from a user and instructs the backend server to fetch data from that location without proper validation. In modern cloud environments (AWS, GCP, Azure, Kubernetes), SSRF frequently escalates into full infrastructure takeover through cloud instance metadata endpoints.
The cloud metadata danger: AWS IMDS and GCP
Cloud instances host a local metadata service at the link-local IP `169.254.169.254`. Under legacy AWS IMDSv1, a simple HTTP GET request to `http://169.254.169.254/latest/meta-data/iam/security-credentials/` extracts temporary IAM access keys, secret keys, and session tokens, allowing an attacker to authenticate directly to the AWS API.
- AWS IMDSv2 protection: require session-oriented HTTP PUT tokens with a hop-limit of 1 to defeat standard SSRF relays.
- GCP metadata header requirement: ensure `Metadata-Flavor: Google` header validation is strictly enforced.
- Kubernetes and container metadata: disable access to pod metadata endpoints and cluster API servers from internal application pods.
Bypassing naive IP blacklists
Simple string filters checking for `127.0.0.1` or `169.254.169.254` are notoriously easy to bypass. Attackers routinely evade basic regexes using decimal representations (`2130706433`), hex encodings (`0x7f000001`), IPv6 representations (`[::1]`), or DNS rebinding techniques where a custom domain resolves to a public IP on the first lookup and `127.0.0.1` on the second.
To safely fetch external URLs, resolve the DNS record first, verify that the resulting IP does not belong to private or reserved IP ranges (RFC 1918, RFC 3927), and connect directly to the validated IP address.