Server Side Request Forgery

A complete operational reference for Server-Side Request Forgery (SSRF) covering detection, internal network probing, cloud metadata exploitation, blind SSRF, protocol smuggling, filter bypass, SSRF-to-RCE chains, automation with tools, and remediation. Mapped to MITRE ATT&CK T1190 / T1083 / T1552.

1. Core Concepts & SSRF Types

SSRF TAXONOMY:

SERVER-SIDE REQUEST FORGERY
├── IN-BAND (response returned to attacker)
│   ├── Basic — full response body returned in HTTP response
│   └── Partial — redirect followed, or subset of response leaked
│
├── BLIND (no direct response returned)
│   ├── Time-based — observe delay to infer open/closed port
│   └── Out-of-Band (OOB) — DNS/HTTP callback to attacker-controlled server
│
└── SEMI-BLIND
    └── Error-based — server returns different errors for open vs closed ports

Key Terms: - SSRF — The server makes an HTTP (or other protocol) request on behalf of the attacker to a target the attacker specifies. The target is typically internal or otherwise unreachable by the attacker directly. - IMDSv1 / IMDSv2 — Instance Metadata Service versions for AWS EC2. IMDSv1 requires no auth (deprecated but still enabled on many instances). IMDSv2 requires a token fetched via PUT. - 169.254.169.254 — The link-local IP address used by cloud provider metadata endpoints (AWS, GCP, Azure, Alibaba). - localhost / 127.0.0.1 / ::1 — Loopback addresses — target internal services on the server itself. - 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — RFC1918 private IP ranges — target internal network hosts. - DNS Rebinding — Attacker's DNS record resolves to an allowed domain during the check, then rebinds to an internal IP when the actual request is made — bypasses allowlist. - OOB — Out-of-Band — no SSRF response visible, but a DNS or HTTP callback to an attacker-controlled server confirms the request was made. - TOCTOU — Time-of-check vs Time-of-use — DNS rebinding exploits the race between DNS resolution for allowlist check and the actual request.

Why It Happens: The application takes a URL or hostname from user input and makes a server-side request without validating that the target is safe:

# Python / Flask — VULNERABLE:
import requests
from flask import Flask, request

app = Flask(__name__)

@app.route('/fetch')
def fetch():
    url = request.args.get('url')
    resp = requests.get(url)          # attacker controls url → SSRF
    return resp.text

# SAFE:
ALLOWED_HOSTS = ['api.trusted.com', 'cdn.trusted.com']

@app.route('/fetch')
def fetch():
    url = request.args.get('url')
    from urllib.parse import urlparse
    parsed = urlparse(url)
    if parsed.hostname not in ALLOWED_HOSTS:
        return "Blocked", 403
    resp = requests.get(url)
    return resp.text

// Node.js — VULNERABLE:
app.get('/fetch', async (req, res) => {
    const url = req.query.url;
    const response = await fetch(url);    // attacker controls url → SSRF
    res.send(await response.text());
});

SSRF vs Related Attacks: - SSRF — Server makes a request to attacker-specified target. Targets internal services. - CSRF — Browser makes a request cross-site using victim's session. Targets authenticated actions. - Open Redirect — Server redirects user to attacker-specified URL. Primarily client-side phishing. - Request Smuggling — Desync between front-end and back-end HTTP parsing. Different protocol-level attack.