A10: Server-Side Request Forgery (SSRF)

Making the Server Fetch Something It Shouldn't

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker can cause the server to make HTTP requests to an arbitrary destination — including internal systems that are not accessible from the public internet. The attacker doesn't make the request themselves; they trick the server into making it on their behalf.

Think of it like this: you can't walk into a bank's back office yourself, but you can hand a note to a bank employee and ask them to go check something for you. If the employee follows your instructions without verifying whether they should, you've just gained access to the back office by proxy.

The Cloud Metadata Attack: Why SSRF Is Catastrophic

Every major cloud provider (AWS, Azure, GCP) exposes an instance metadata service at a well-known internal IP address. This service provides the running instance with its configuration, credentials, and identity information. It is only accessible from within the instance itself — or so the design assumes.

The Attack Scenario:

# Application feature: "Enter a URL to import your avatar image"
# Normal use:
POST /api/profile/avatar
{ "url": "https://my-photos.com/me.jpg" }
# Server fetches the image and saves it.

# SSRF attack:
POST /api/profile/avatar
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/my-ec2-role" }
# Server fetches the metadata endpoint and returns the response to the attacker.

The response from the metadata endpoint contains:

{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "wJalrXUtnFEMI...",
  "Token": "AQoDYXdzEJr...",
  "Expiration": "2024-01-15T12:00:00Z"
}

The attacker now has temporary AWS credentials for the EC2 instance's IAM role. Depending on that role's permissions, they may be able to read S3 buckets, access RDS databases, create new IAM users, or pivot to other services. This is how the 2019 Capital One breach occurred — SSRF against the AWS metadata service exposed credentials that were then used to exfiltrate over 100 million customer records.

The Fix: Defense in Depth

No single control is sufficient. Apply all of these:

1. Input Validation — Allowlist, Not Blocklist

import ipaddress
from urllib.parse import urlparse

ALLOWED_DOMAINS = {'my-photos.com', 'cdn.mysite.com'}

def is_safe_url(url: str) -> bool:
    parsed = urlparse(url)

    # Only allow HTTPS
    if parsed.scheme != 'https':
        return False

    # Only allow known domains
    if parsed.hostname not in ALLOWED_DOMAINS:
        return False

    # Resolve the hostname and block private/loopback IPs
    try:
        ip = ipaddress.ip_address(socket.gethostbyname(parsed.hostname))
        if ip.is_private or ip.is_loopback or ip.is_link_local:
            return False
    except Exception:
        return False

    return True

Note: Blocklisting 169.254.169.254 is insufficient — attackers can bypass it using DNS rebinding, IPv6 equivalents, decimal IP notation (2852039166), or redirects.

2. IMDSv2 (AWS Instance Metadata Service v2)
AWS introduced IMDSv2, which requires a session-oriented token obtained via a PUT request before metadata can be accessed. A simple GET to the metadata endpoint no longer works. Enforcing it on an EC2 instance is a one-line change to the instance's metadata options, setting http-tokens to required.

3. Network Segmentation
Application servers should not have network routes to internal services they don't need. Use security groups, VPC network ACLs, or service mesh policies to enforce this at the network layer — so even if SSRF occurs, the server cannot reach sensitive internal endpoints.

Key Point: SSRF is particularly dangerous in microservice architectures and cloud environments because the server making the request often has implicit trust within the internal network. A request from the application server to an internal database or admin API may bypass authentication entirely, because the network perimeter was assumed to be the security boundary. SSRF collapses that assumption. Defense must be applied at the application layer, not just the network perimeter.