Demystifying SSRF Attacks in Cloud Environments

Server-Side Request Forgery (SSRF) is a web vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain. While SSRF has been known for years, the shift to public cloud hosting (AWS, Azure, Google Cloud) has exponentially escalated the severity of this vulnerability.

In this article, we’ll demystify how SSRF functions, explore why cloud environments are particularly vulnerable, and outline defenses you should implement.

The Mechanics of SSRF

A typical SSRF vulnerability occurs when a server-side application accepts a URL from a user, attempts to connect to it, and renders the result back. For example, a web feature that generates PDF invoices from a user-supplied URL or fetches user avatars might look like this:

https://target.com/generate-pdf?url=http://example.com/invoice.html

An attacker can manipulate the url parameter to target internal systems that are otherwise shielded by firewalls:

https://target.com/generate-pdf?url=http://192.168.1.50/admin-panel

Cloud Metadata Endpoints: The Ultimate Prize

In public clouds, every virtual instance can query a link-local address to retrieve metadata about itself. This service is known as the Instance Metadata Service (IMDS), and it resides at the non-routable IP address:

169.254.169.254

If an application running in AWS is vulnerable to SSRF, an attacker can request the following endpoint:

http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role

The server will make the request, fetch the metadata, and return the temporary AWS Access Key ID, Secret Access Key, and Token directly to the attacker. Within minutes, the attacker can configure their local AWS CLI and hijack the entire cloud account.

The Defense: IMDSv1 vs IMDSv2

To mitigate metadata theft, cloud providers introduced updated metadata service versions. In AWS, this is IMDSv2, which adds session-oriented authentication.

• IMDSv1 (Vulnerable to SSRF): A simple GET request is sufficient to retrieve credentials.
• IMDSv2 (Secure): Requires a HTTP PUT request to generate a token first, and then a GET request with that token in the header. Since most SSRF vulnerabilities only allow basic GET requests without custom headers, IMDSv2 successfully blocks unauthorized metadata reads.

Application-Level Mitigations

1. Input Validation & Blacklisting: Avoid accepting raw URLs from users. If required, validate them against strict whitelists of allowed domains.
2. Network-Level Segregation: Block outgoing requests from the web servers to private ranges (RFC 1918) and link-local addresses.
3. Disable Unused Protocols: Restrict the HTTP client inside the application to only support http and https protocols, blocking file://, gopher://, or dict:// handlers which can be abused to read files or interact with databases.