Introduction
Server-Side Request Forgery (SSRF) is often underestimated. On its own, it may seem like a low-severity issue — the ability to make a server fetch an arbitrary URL. But in cloud environments, SSRF becomes the first link in a devastating attack chain that can lead to full infrastructure compromise.
The Anatomy of SSRF
SSRF occurs when an application fetches a URL provided by the user without proper validation:
# Vulnerable endpoint
@app.route('/api/preview')
def preview():
url = request.args.get('url')
response = requests.get(url) # No validation!
return response.text
An attacker can abuse this to access internal resources that are normally unreachable from the internet.
Cloud Metadata: The Crown Jewels
Every major cloud provider exposes an instance metadata service at a well-known internal IP:
| Provider | Metadata Endpoint |
|---|---|
| AWS | http://169.254.169.254/latest/meta-data/ |
| GCP | http://metadata.google.internal/computeMetadata/v1/ |
| Azure | http://169.254.169.254/metadata/instance |
These endpoints expose: - IAM credentials with potentially broad permissions - Instance identity tokens for service-to-service authentication - User data scripts that may contain secrets - Network configuration revealing internal architecture
The Attack Chain
Step 1: Identify SSRF
We test API endpoints that accept URLs — webhooks, file imports, URL previews, PDF generators, and image processors.
Step 2: Bypass Filters
Common SSRF filters can be bypassed using:
- DNS rebinding: Register a domain that alternates between a public IP and 169.254.169.254
- URL encoding: http://169.254.169.254 → http://0xa9fea9fe
- Redirect chains: Host a page that 302-redirects to the metadata endpoint
- IPv6 mapping: http://[::ffff:169.254.169.254]/
Step 3: Harvest Credentials
# Via SSRF, access AWS temporary credentials
GET /api/preview?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/my-role
Response:
{
"AccessKeyId": "ASIA...",
"SecretAccessKey": "wJalr...",
"Token": "FwoGZX...",
"Expiration": "2026-01-28T12:00:00Z"
}
Step 4: Lateral Movement
With harvested credentials, we can: - Access S3 buckets containing backups and sensitive data - Read secrets from AWS Secrets Manager or Parameter Store - Invoke Lambda functions or modify infrastructure - Pivot to other services within the VPC
Prevention
- Disable metadata v1 — Use IMDSv2 (token-required) on AWS
- Network-level controls — Block outbound requests to 169.254.169.254 from application containers
- URL validation — Allowlist permitted domains and protocols; resolve DNS before fetching to prevent rebinding
- Least-privilege IAM — Instance roles should have minimal permissions
- Monitor metadata access — Alert on unusual metadata API calls
Conclusion
SSRF in a cloud environment is not a "medium" finding — it's a critical path to total compromise. The chain from "fetch this URL" to "here are your AWS credentials" can be executed in minutes by a skilled attacker. This is exactly the type of multi-step, context-dependent vulnerability that automated scanners consistently miss.