SSRF in Cloud Environments: From Discovery to Impact

Server-Side Request Forgery became one of the highest-impact vulnerability classes when cloud infrastructure became the default deployment model. What was once a way to probe internal networks became a mechanism for complete cloud account takeover. The Capital One breach of 2019 — 100 million customer records exposed — was the canonical demonstration of SSRF impact in AWS. This guide covers the technical mechanics, exploitation chain, and the defenses that actually work.

SSRF Fundamentals and Discovery

SSRF occurs when an application makes an HTTP request to a URL that is fully or partially controlled by an attacker. The server becomes a proxy, making requests from its network position rather than the attacker's. In most network models, the server has access to resources that are unreachable from the external internet: internal APIs, metadata services, admin interfaces, and other backend services that assume network position equals trustworthiness.

Common injection points include URL preview features, webhook registration endpoints, PDF generators that fetch URLs for embedded images, document importers (fetch a file from a URL), image processing services (resize an image at this URL), and integration configuration (connect to this external service at this host). Any feature that causes the server to initiate outbound HTTP connections on behalf of user-supplied input is a candidate. Check request parameters named url, target, endpoint, host, proxy, callback, redirect, image, and uri.

Even when there is no obvious URL parameter, SSRF can surface in unexpected places: XML parsers that resolve external entity references (XXE-based SSRF), HTTP headers like X-Forwarded-Host or Host used to construct absolute URLs in password reset emails, and import features in productivity applications. The key is thinking about any server action that might trigger an outbound network connection and whether that action can be influenced by user input.

Cloud Metadata Endpoints and IMDSv1 vs IMDSv2

The cloud metadata service lives at the link-local address 169.254.169.254 on all major cloud platforms (AWS, GCP, Azure, DigitalOcean, Oracle). It provides instance metadata, configuration, and — critically — temporary IAM credentials to the application running on the instance. These credentials have the same permissions as the instance's IAM role. In AWS, http://169.254.169.254/latest/meta-data/iam/security-credentials/ lists attached roles, and appending the role name returns a JSON document with AccessKeyId, SecretAccessKey, and Token — a complete, working IAM credential set that expires in hours.

AWS IMDSv1 requires only a simple HTTP GET to 169.254.169.254 — no authentication, no headers, no session. Any request from the instance is answered. IMDSv2 (Instance Metadata Service version 2) adds a required pre-flight step: the client must first PUT to http://169.254.169.254/latest/api/token with a TTL-Seconds header to receive a session token, then include that token in subsequent requests. The PUT method requirement is specifically designed to block SSRF exploitation — SSRF vulnerabilities typically only control the URL, not the HTTP method. An SSRF that only allows GET requests cannot complete the IMDSv2 pre-flight PUT.

GCP metadata is available at http://metadata.google.internal/computeMetadata/v1/ and requires a Metadata-Flavor: Google header — a partial mitigation that blocks naive SSRF attacks unless the attacker can also control request headers. Azure IMDS at http://169.254.169.254/metadata/instance requires a Metadata: true header. These header requirements are meaningful obstacles but are bypassable if the SSRF allows header injection or if the application adds certain headers to all outbound requests.

Blind SSRF, DNS Rebinding, and URL Parser Differentials

Blind SSRF occurs when the application initiates the server-side request but does not return the response to the attacker. The request fires, but from the attacker's perspective the response is the same regardless of whether the internal request succeeded. Detection relies on out-of-band techniques: supply a URL pointing to an attacker-controlled server and monitor for incoming DNS queries and HTTP connections. Burp Collaborator and interactsh are standard tools for this — any interaction with the callback server confirms SSRF, even if you cannot read the response.

DNS rebinding attacks bypass IP-based blocklists that prevent direct connections to internal addresses. The attack uses a DNS record that first resolves to a legitimate public IP (passing the application's pre-connection validation) then resolves to an internal IP address (used for the actual connection). The validation check and the connection resolve the DNS name at different times, and if the TTL is set low enough, the two lookups can receive different answers. Tools like singularity and rbndr.us provide DNS rebinding infrastructure for testing. The defense is to resolve the hostname once, validate the resulting IP, and then connect using the IP directly — preventing re-resolution.

URL parser differentials exploit inconsistencies between the URL parser used for blocklist validation and the URL parser used for the actual HTTP request. If the validation code uses one library and the HTTP client uses another, they may disagree about what http://[email protected]/ means, or how to interpret http://169.254.169.254#@evil.com/, or whether http://[::ffff:169.254.169.254] (IPv6-mapped IPv4 address) matches an IPv4 blocklist entry. Orange Tsai's research on URL parsing inconsistencies across languages and libraries is essential reading for anyone implementing SSRF defenses.

Pivoting Through Internal Services

Once SSRF is confirmed against the metadata endpoint, the next step is understanding the broader internal network topology reachable from the compromised instance. Cloud VPCs typically have internal service discovery mechanisms: AWS uses Route 53 internal hosted zones and service discovery endpoints; Kubernetes deployments expose a DNS-based service registry. Credentials obtained from the metadata service can be used to query the cloud control plane directly — describing EC2 instances, RDS databases, S3 buckets, Lambda functions, and IAM roles to build a picture of the environment.

Internal HTTP services that assume network position as authentication are particularly valuable pivot targets. Kubernetes API servers (https://kubernetes.default.svc from within a pod), Consul and etcd endpoints, internal Elasticsearch clusters, Redis instances without authentication, and internal administrative web interfaces all become reachable through the SSRF vector. In a well-segmented environment, the damage may be limited; in a flat internal network, a single SSRF can be a stepping stone to every backend service.

Port scanning via SSRF — sending requests to http://internal-host:PORT and observing response time and content differences — reveals what services are running internally. Error responses, connection refused signals, and timeout behavior all carry information about the internal service topology. Combined with cloud API access from stolen credentials, a comprehensive internal map can be constructed without ever gaining direct network access to the environment.

Defense Strategies That Actually Work

The primary defense against SSRF is an allowlist of destinations the application is permitted to reach, rather than a blocklist of forbidden destinations. Allowlists are difficult for attackers to circumvent because any bypass requires the application to accept requests to unlisted destinations. Blocklists are inherently incomplete — new internal services are added, edge cases in URL parsing create bypasses, IPv6 addresses are missed, and alternative representations of blocked IP ranges are not anticipated.

IMDSv2 enforcement for all EC2 instances is a critical cloud-specific control. AWS now allows setting a maximum hop limit of 1 for IMDSv2, which additionally prevents metadata access from containers running on the host that may not be directly associated with the instance role. Enforcing IMDSv2 through the AWS Organizations service control policy ensures it cannot be disabled by instance owners. For new deployments, IMDSv2 should be required by the launch template or AMI configuration; for existing fleets, a gradual migration with monitoring for IMDSv1 usage is the practical path.

Network-level controls provide defense in depth. VPC security groups and NACLs can block outbound connections from application instances to the metadata address range, though this also blocks legitimate metadata access and requires the application to use IMDSv2 through the VPC endpoint instead. For containerized workloads, network policies in Kubernetes can prevent pods from reaching 169.254.169.254 entirely, forcing all credential management through workload identity mechanisms like IRSA (IAM Roles for Service Accounts) rather than the metadata endpoint. Egress filtering to restrict application outbound connections to expected destinations completes the defense-in-depth picture.