Server-Side Request Forgery (SSRF): Cloud Metadata Exploitation and Modern Defense
Understanding how SSRF compromises internal microservices, AWS/GCP metadata endpoints, and how to implement zero-trust egress filters.
1. What Makes SSRF So Dangerous in Cloud Architecture?
In modern cloud deployments, servers possess privileged network identities (such as AWS IAM Instance Profiles or Google Cloud Service Accounts).
When a web application allows users to provide a URL to fetch an avatar, generate a PDF report, or test a webhook, an attacker can input internal loopback addresses or cloud metadata IPs to extract temporary infrastructure credentials.
2. The Infamous Cloud Metadata Target
AWS, Azure, and Google Cloud provide an internal link-local IP (`169.254.169.254`) accessible only from inside running virtual machines. Under legacy IMDSv1, a simple HTTP GET request returns administrative secret keys.
# IMDSv1 (Vulnerable to simple SSRF GET):
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/AdminRole
# IMDSv2 (Enforces PUT session handshake with hop limit):
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/3. Robust Defensive Validation Strategy
Never validate URLs using regex on raw strings. Instead:
1. Parse the URL and resolve its hostname to all associated IP addresses using an isolated DNS resolver.
2. Verify that none of the resolved IPs belong to private or reserved subnets (`127.0.0.0/8`, `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `169.254.0.0/16`, `::1`).
3. Perform the HTTP request with automated redirection explicitly disabled.