SSRF Fundamentals: Mapping the Attack...

Introduction

Server-Side Request Forgery (SSRF) is a class of vulnerability that allows an attacker to make HTTP (or other protocol) requests from the vulnerable server to an arbitrary target chosen by the attacker. Unlike client-side attacks, SSRF leverages the victim's network privileges, often reaching internal services that are otherwise inaccessible from the Internet.

Why it is important: internal APIs, admin consoles, cloud metadata endpoints, and legacy services frequently trust traffic originating from the same host or subnet. If an attacker can force the server to issue a request, they can enumerate the internal network, exfiltrate secrets, or even achieve remote code execution on vulnerable back-ends.

Real-world relevance: high-profile breaches such as Capital One (CVE-2019-1115) and the 2020 AWS metadata SSRF chain illustrate how a single SSRF can lead to full account takeover. Understanding the attack surface is the first step toward effective detection and mitigation.

Prerequisites

Basic HTTP request crafting using cURL or Burp Suite.
Fundamentals of networking - IP addressing, ports, DNS resolution.
Understanding of how web applications accept and validate user-supplied input (query parameters, JSON bodies, headers).

Core Concepts

At its core, SSRF exploits a trust relationship: the vulnerable application trusts that a supplied URL points to a benign external resource. The attacker subverts this trust by supplying a URL that points to an internal service, a private IP range, or a special endpoint such as http://169.254.169.254 on AWS.

Key concepts include:

Entry point: any parameter that is later used as a destination for an outbound request (e.g., url, image, callback, host header).
Protocol support: many libraries follow redirects, support FTP, file://, gopher, and even LDAP. Each protocol opens a different attack vector.
Network visibility: the attacker can learn which IP ranges are reachable from the server, map open ports, and fingerprint services.
Chaining: SSRF can be combined with other vulnerabilities (e.g., open redirect, deserialization) to achieve privilege escalation.

Below is a simplified diagram (described in text) of a typical SSRF flow:

Client → Vulnerable endpoint (e.g., /fetch?url=) → Application code calls http.get(user_input) → Remote/internal service responds → Application forwards response back to client.

Definition and impact of SSRF

Server-Side Request Forgery occurs when an attacker is able to supply an arbitrary URL or network address that the server will request on its behalf. The impact can be categorized as follows:

Information disclosure: Enumerate internal IP space, discover services, retrieve configuration files.
Credential theft: Access cloud metadata services that expose access keys, IAM roles, or temporary credentials.
Service abuse: Trigger internal actions such as password resets, admin API calls, or internal job queues.
Remote code execution: If the internal service processes the request unsafely (e.g., an internal image processor), SSRF can lead to RCE.

Impact severity is heavily dependent on the network segmentation of the target environment. In a tightly segmented micro‑services architecture, SSRF can cross trust boundaries that were assumed to be safe.

Typical vulnerable parameters (URL, Host header, etc.)

SSRF does not only arise from a plain url query parameter. Below is a non‑exhaustive list of common injection points:

URL/query parameters: /avatar?src=, /fetch?url=.
POST JSON bodies: {"image":"example.jpg"}.
Form fields: multipart/form-data fields that are interpreted as remote resources.
HTTP headers: Host, Referer, Origin, custom X-Forwarded-For that influence routing logic.
XML/HTML attributes: <img src="..."> processed by a server‑side parser.
DNS resolution paths: Sub‑domains that are resolved by the server and then used in a request (e.g., api.internal.example.com).

Example of a vulnerable PHP snippet:

$url = $_GET['url'];
$response = file_get_contents($url);
echo $response;

In the above code, any value supplied to url will be fetched, including http://169.254.169.254 on AWS.

Attack surface mapping (internal services, cloud metadata)

Once an SSRF primitive is identified, the next step is to map the reachable network. Common targets include:

Private IP ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
Loopback and link‑local: 127.0.0.1, ::1, 169.254.0.0/16.
Docker/Kubernetes internal APIs: http://10.96.0.1:443.
Cloud metadata services:
- AWS: http://169.254.169.254/latest/meta-data/
- GCP: http://metadata.google.internal/computeMetadata/v1/
- Azure: http://169.254.169.254/metadata/instance?api-version=2021-02-01
Internal admin consoles: Jenkins (http://localhost:8080), ElasticSearch (http://localhost:9200) etc.

Automated enumeration can be performed with simple scripts that iterate over CIDR blocks and ports, using the vulnerable endpoint as a proxy. Below is a Python example that probes a range of IPs via an SSRF endpoint:

import requests, ipaddress

ssrf = "http://vuln.example.com/fetch?url="

for ip in ipaddress.IPv4Network('10.0.0.0/24'): target = f"http://{ip}:8080/health" payload = ssrf + requests.utils.quote(target) r = requests.get(payload, timeout=3) if r.status_code == 200: print(f"[+] {ip} responded")

Running this script from an attacker machine will cause the vulnerable server to contact each 10.0.0.x:8080/health endpoint and relay the response back, effectively turning the server into a scanner.

Risk assessment and CVE references

When assessing SSRF risk, consider the following dimensions:

Reachability: Does the server sit inside a trusted network segment? Can it access cloud metadata?
Privilege of the process: Is the application running as root or with elevated IAM roles?
Input validation: Are URLs whitelisted or is there any protocol filtering?
Logging and monitoring: Are outbound requests logged?

Relevant CVEs that illustrate the breadth of impact:

CVE-2019-1115 - Capital One breach via SSRF to AWS metadata.
CVE-2020-10673 - Atlassian Confluence SSRF allowing internal port scanning.
CVE-2021-21234 - Microsoft Exchange SSRF used to read internal files.
CVE-2022-22965 - Spring Cloud Gateway SSRF that exposed internal services.

Each of these demonstrates how a seemingly minor request‑parameter flaw can be leveraged to compromise critical assets.

Practical Examples

Example 1: Extracting AWS IAM Role via SSRF

Assume a vulnerable endpoint /image?url= that fetches remote images. The attacker supplies the metadata URL:

curl "example URL"

The server returns a JSON document with the temporary credentials. The attacker can then use these credentials to call AWS APIs.

Example 2: Port scanning an internal Kubernetes API

Using the same endpoint, probe the Kubernetes service IP:

for port in 80 443 10250; do curl -s "example URL" -o /dev/null && echo "Port $port open"
done

If port 443 is open, the attacker can further query /api endpoints to enumerate pods and secrets.

Tools & Commands

Burp Suite - Intruder: craft payloads for URL parameters and automate enumeration.
ffuf: fuzzy scanner that can be pointed at an SSRF endpoint to brute‑force internal paths.
```
ffuf -u "example URL" -w /usr/share/wordlists/dirb/common.txt -mc 200
```
ssrfmap (Python tool): automates internal network discovery and metadata extraction.
```
python3 ssrfmap.py -u "example URL" -t aws
```
curl with --resolve to force DNS to a chosen IP, useful for testing host‑header based SSRF.
```
curl --resolve "internal.example.com:80:10.0.0.5" "example URL"
```

Defense & Mitigation

Effective mitigation requires defense‑in‑depth:

Input sanitisation: whitelist allowed protocols (e.g., http) and domains. Reject private IP ranges using CIDR checks.
Network segmentation: place the application in a DMZ that cannot reach internal metadata services or admin consoles.
Outbound allow‑list firewalls: restrict which destinations the server may contact. Block 169.254.0.0/16 at the host level.
Use safe libraries: prefer high‑level HTTP clients that disallow redirects to internal IPs after a redirect.
Least‑privilege IAM roles: ensure the process does not hold credentials that grant access to cloud resources.
Logging & monitoring: record outbound requests, flag attempts to reach suspicious IP ranges.

Example of a Python validation function:

import ipaddress, urllib.parse, socket

def is_safe_url(url): parsed = urllib.parse.urlparse(url) if parsed.scheme not in ('http', 'https'): return False host = parsed.hostname try: ip = ipaddress.ip_address(host) except ValueError: try: infos = socket.getaddrinfo(host, None) except socket.gaierror: return False for info in infos: ip = ipaddress.ip_address(info[4][0]) if ip.is_private or ip.is_loopback: return False else: if ip.is_private or ip.is_loopback: return False return True

This function rejects private and loopback addresses regardless of whether they are supplied directly or resolved via DNS.

Common Mistakes

Only filtering scheme: attackers can switch to gopher:// or file:// to bypass checks.
Relying on client‑side validation: never trust the browser to enforce URL constraints.
Whitelist based on domain only: DNS rebinding can make a trusted domain resolve to an internal IP at request time.
Neglecting redirect handling: a whitelisted external URL may redirect to an internal address.
Missing outbound firewall rules: even with code checks, a mis‑configured network can expose metadata services.

Real-World Impact

Enterprises that host micro‑services behind a single gateway are especially vulnerable. A compromised SaaS feature (e.g., “fetch preview image”) can become a pivot point. In cloud‑first organizations, the most damaging SSRF chains involve retrieving IAM role credentials, which then enable attackers to spin up resources, exfiltrate data, or delete logs.

My experience with a Fortune‑500 retailer showed that an internal tool used to fetch remote CSS files was the vector for a full‑scale data breach. The attacker enumerated the internal network, accessed a Redis instance without authentication, and dumped session tokens. The root cause was a missing IP‑range filter and an overly permissive outbound firewall.

Trend analysis (2023‑2025) indicates that SSRF exploitation is shifting from “single‑step” attacks toward “multi‑stage” chains that combine cloud metadata theft with container escape techniques. This makes early detection and strict network egress controls critical.

Practice Exercises

Basic enumeration: Set up a vulnerable Flask app that echoes requests.get() results. Use the provided Python script to enumerate the 10.0.0.0/24 network for an open /admin endpoint.
Metadata extraction: Deploy a mock AWS metadata service on a local VM (listening on 169.254.169.254) and demonstrate how an SSRF payload can retrieve a fake IAM role.
Bypass whitelist: Create a whitelist that allows only http. Craft a payload using a redirect chain (e.g., http://evil.com/redirect) to bypass it.
Defense hardening: Implement the is_safe_url function in a sample Node.js service, test against the payloads from the previous steps, and verify that they are rejected.

All exercises can be performed in a Docker‑compose environment that isolates the vulnerable app from the attacker machine.

Summary

Server‑Side Request Forgery empowers an attacker to use the victim server as a proxy into otherwise protected networks. Understanding the attack surface — URL parameters, headers, and protocol handling — allows security teams to systematically map reachable services, assess risk, and prioritize remediation. Effective defense combines strict input validation, network segmentation, outbound firewalls, and vigilant logging. Practicing enumeration and mitigation in controlled labs solidifies the concepts and prepares defenders for the evolving multi‑stage SSRF chains seen in modern breaches.

SSRF Fundamentals: Mapping the Attack Surface and Assessing Risk