SSRF Exploitation in Cloud Environments

Server-Side Request Forgery is not new, but cloud computing turned it from a moderate-impact vulnerability into a critical one. In a traditional data center, SSRF lets an attacker scan internal networks and access internal services. In a cloud environment, SSRF gives the attacker the keys to the kingdom -- literally. Cloud metadata services hand out IAM credentials, configuration data, and secrets to any process that asks, and an SSRF vulnerability lets an attacker ask.

The Capital One breach in 2019 demonstrated this perfectly. An SSRF vulnerability in a web application firewall allowed the attacker to query the AWS metadata service, obtain temporary IAM credentials, and exfiltrate data from over 100 million customer records. The attack took minutes. The cleanup took years.

How SSRF Works

SSRF occurs when an application makes HTTP requests based on user-supplied input without adequate validation. Common scenarios include:

• URL fetching features. "Enter a URL to preview" or "Fetch RSS feed from" functionality.
• Webhook delivery. The application sends HTTP requests to user-configured webhook URLs.
• Document processing. PDF generation, image resizing, or file import from URLs.
• API integrations. The application proxies requests to third-party services based on user configuration.

The attacker supplies a URL pointing to an internal resource instead of an external one. If the application makes the request server-side, the attacker accesses internal resources through the application as a proxy.

Cloud Metadata Services: The Primary Target

Every major cloud provider runs a metadata service on a link-local address that is accessible from any instance:

AWS: http://169.254.169.254/latest/meta-data/ provides instance metadata, and /latest/meta-data/iam/security-credentials/[role-name] returns temporary IAM credentials (access key, secret key, session token).

GCP: http://metadata.google.internal/computeMetadata/v1/ provides metadata and service account tokens. Requires the Metadata-Flavor: Google header, but this can be set in many SSRF scenarios.

Azure: http://169.254.169.254/metadata/instance provides instance metadata and managed identity tokens at /metadata/identity/oauth2/token.

These credentials are often over-permissioned. An instance role designed to access S3 for application data might also have permissions to list all buckets, access other services, or escalate privileges through IAM.

SSRF Bypass Techniques

Applications often implement basic protections against SSRF, but attackers have developed numerous bypass techniques:

DNS rebinding. The application validates the URL by resolving the hostname and checking if it points to an internal IP. The attacker controls a DNS server that returns a public IP for the first query (passing validation) and an internal IP for the second query (when the application makes the actual request).

IP address encoding. 169.254.169.254 can be represented as:

• Decimal: 2852039166
• Hex: 0xA9FEA9FE
• Octal: 0251.0376.0251.0376
• IPv6 mapping: [::ffff:169.254.169.254]
• URL encoding: %31%36%39%2e%32%35%34%2e%31%36%39%2e%32%35%34

Redirect-based bypass. The application validates the initial URL (which points to an external server the attacker controls), but the external server returns a 302 redirect to http://169.254.169.254/. If the application follows redirects, the metadata service is accessed.

Protocol smuggling. Using non-HTTP protocols like gopher://, dict://, or file:// to interact with internal services that expect raw TCP connections. Gopher in particular can be used to send arbitrary data to internal services.

CRLF injection. Injecting carriage return and line feed characters into the URL to manipulate the HTTP request headers, potentially adding the Metadata-Flavor: Google header required by GCP.

Cloud-Specific Defenses

Each cloud provider has introduced mitigations for metadata-based SSRF:

AWS IMDSv2. Instance Metadata Service version 2 requires a PUT request to obtain a session token, which must be included in subsequent metadata requests as a header. This blocks most SSRF attacks because the SSRF vulnerability typically only allows GET requests or cannot set custom headers.

Enable IMDSv2 and disable IMDSv1:

aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1

GCP metadata header requirement. GCP requires the Metadata-Flavor: Google header on all metadata requests. This blocks basic SSRF but can be bypassed in scenarios where the attacker controls request headers.

Azure managed identity configuration. Azure allows restricting which resources a managed identity can access and supports user-assigned managed identities with minimal permissions.

Application-Level Defenses

Cloud-level mitigations are not sufficient alone. Application-level defenses are essential:

URL validation. Parse the URL, resolve the hostname, and verify that the resolved IP address is not in private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, 127.0.0.0/8). But be aware of DNS rebinding and other bypass techniques.

Allowlist approach. If the application only needs to fetch from specific domains, maintain a strict allowlist. This is the most effective defense but limits functionality.

Network-level controls. Use firewall rules to prevent application instances from accessing the metadata service directly. Route metadata requests through a proxy that enforces restrictions.

Disable unnecessary protocols. Restrict the HTTP client to only support http:// and https:// protocols. Disable gopher://, file://, dict://, and other protocols that enable protocol smuggling.

Disable redirects. Configure the HTTP client to not follow redirects automatically. If redirects are needed, validate each redirect target against the same rules as the original URL.

Response filtering. Limit the response size and validate that the response content-type matches expectations. An SSRF that fetches a URL preview should only accept HTML, not arbitrary binary data.

Defense in Depth Strategy

No single defense is sufficient. Layer your protections:

1. IMDSv2 or equivalent -- Block simple metadata access
2. URL validation -- Prevent known-internal targets
3. DNS resolution validation -- Catch DNS rebinding attempts by resolving the hostname and validating the IP immediately before making the request (not as a separate step)
4. Network segmentation -- Firewall rules preventing application instances from reaching metadata endpoints directly
5. Least-privilege IAM -- Even if credentials are stolen, limit what they can do
6. Credential rotation -- Temporary credentials with short lifetimes limit the exposure window
7. Monitoring -- Alert on unusual metadata service access patterns

Detecting SSRF Attempts

Monitor for indicators of SSRF exploitation:

• Outbound requests from application servers to internal IP ranges
• Requests to the metadata service from unexpected processes
• DNS lookups for 169.254.169.254 or metadata.google.internal
• Unusual IAM credential usage patterns (credentials from an instance used from a different IP)
• High volumes of outbound requests to diverse IP addresses (internal port scanning)

Cloud providers offer logging that captures metadata service access:

• AWS: VPC Flow Logs capture traffic to 169.254.169.254. CloudTrail logs API calls made with instance credentials.
• GCP: VPC Flow Logs and Audit Logs capture metadata access.
• Azure: NSG Flow Logs and Activity Logs track metadata service access.

Real-World Impact

SSRF in cloud environments has been responsible for numerous high-profile breaches:

• Capital One (2019): SSRF in WAF led to S3 data exfiltration affecting 106 million customers
• Various bug bounties: SSRF in webhook features, URL preview functions, and document processors leading to AWS credential theft
• CI/CD systems: SSRF in build systems that run in cloud environments with broad IAM permissions

The pattern is consistent: SSRF provides the initial access, cloud metadata provides the credentials, and over-permissioned IAM roles provide the access to sensitive data.

How Safeguard.sh Helps

Safeguard.sh provides visibility into the libraries and frameworks in your application that handle HTTP requests, URL parsing, and outbound connections -- the components most likely to introduce SSRF vectors. When a CVE is published for an HTTP client library or URL parser in your stack, Safeguard.sh surfaces it immediately. Combined with SBOM analysis that tracks your cloud SDK dependencies, Safeguard.sh helps your team identify and remediate the components most at risk for SSRF exploitation in cloud environments.