Luke a Pro

Luke Sun

Developer & Marketer

đŸ‡ș🇩
EN|缀|çč
© 2015–2026 Luke Sun.
All rights reserved.

Server-Side Request Forgery (SSRF)

| , 3 minutes reading.

1. Definition

Server-Side Request Forgery (SSRF) is a vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization’s infrastructure, or force the server to connect to arbitrary external systems, potentially leaking sensitive data.

2. Technical Explanation

Modern applications often fetch resources from URLs provided by users (e.g., “Import from URL”, “Fetch preview”, “Webhook callbacks”).

If the server does not validate the destination, an attacker can:

  1. Access Internal Services: Request http://localhost:6379 (Redis), http://192.168.1.1/admin (Internal Admin), or cloud metadata endpoints.
  2. Port Scanning: Use the server as a proxy to scan internal networks.
  3. Bypass Access Controls: Internal services often trust requests from “localhost” and skip authentication.

Cloud Metadata Exploitation: Cloud providers (AWS, GCP, Azure) expose instance metadata at well-known URLs:

  • AWS: http://169.254.169.254/latest/meta-data/
  • GCP: http://metadata.google.internal/

These endpoints return IAM credentials, API keys, and configuration data.

3. Attack Flow

sequenceDiagram
    participant Attacker
    participant WebApp as Web Application
    participant Meta as Cloud Metadata Service
    participant Internal as Internal Database

    Attacker->>WebApp: POST /fetch-url<br/>url=http://169.254.169.254/latest/meta-data/iam/

    Note over WebApp: Server fetches the URL<br/>without validation

    WebApp->>Meta: GET /latest/meta-data/iam/security-credentials/
    Meta-->>WebApp: IAM Role Credentials JSON

    WebApp-->>Attacker: Response contains AWS credentials

    Note over Attacker: Attacker now has<br/>cloud infrastructure access

4. Real-World Case Study: Capital One (2019)

Target: Capital One’s AWS Infrastructure. Vulnerability Class: SSRF leading to Cloud Metadata Access (CVE-2019-4872).

The Vulnerability: Capital One used a Web Application Firewall (WAF) that had an SSRF vulnerability. The WAF was configured with an IAM role that had excessive permissions.

The Attack:

  1. The attacker discovered the SSRF vulnerability in the WAF.
  2. They sent requests to http://169.254.169.254/latest/meta-data/iam/security-credentials/
  3. Retrieved temporary AWS credentials assigned to the WAF’s IAM role.
  4. Used these credentials to access S3 buckets containing customer data.

Impact: Over 100 million customer records were exposed, including names, addresses, credit scores, and Social Security numbers. This resulted in an $80 million fine and became a landmark case for cloud security.

5. Detailed Defense Strategies

A. Input Validation and Allowlisting

Never allow user-controlled URLs to access arbitrary destinations.

  • Allowlist: Only permit requests to known, trusted domains.
  • Deny by Default: Block private IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x, 127.x.x.x, 169.254.x.x).
  • Protocol Restriction: Only allow https:// - block file://, gopher://, dict://.

B. DNS Resolution Validation

Attackers can bypass IP blocklists using DNS rebinding or domain names that resolve to internal IPs.

  • Mechanism: Resolve the hostname first, then validate the IP address before making the request.
  • Re-check: Validate the IP again after DNS resolution (prevent TOCTOU attacks).

C. Network Segmentation

Isolate servers that need to fetch external URLs.

  • Firewall Rules: Servers that fetch user-provided URLs should not have access to internal services or metadata endpoints.
  • Dedicated Proxy: Route all outbound requests through a hardened proxy with strict allowlists.

D. Disable Cloud Metadata (or Use IMDSv2)

  • AWS IMDSv2: Requires a session token obtained via PUT request, making SSRF exploitation significantly harder.
  • Block Metadata: If not needed, use firewall rules to block access to 169.254.169.254.
# AWS: Enforce IMDSv2 on EC2 instances
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required

6. References