Module 08: Server-Side Request Forgery

SSRF Breach

Zwinge den Server, Anfragen in deinem Namen zu stellen. Erreiche interne Dienste, die für das Internet unsichtbar sind, und extrahiere Cloud-Metadaten.

Das trojanische Pferd der Web-Security

Normalerweise blockiert eine Firewall den Zugriff von außen auf interne Datenbanken oder Admin-Panels. Bei **SSRF** schickst du dem Webserver eine URL (z.B. in einem Image-Uploader oder PDF-Generator).

Der Server führt die Anfrage aus seiner **internen Position** heraus aus. Da die Firewall dem Webserver vertraut, erlaubt sie den Zugriff auf das interne Netzwerk.

Beliebte Ziele:

  • - http://127.0.0.1:8080 (Lokale Dienste)
  • - http://169.254.169.254 (Cloud Metadata)
  • - http://192.168.1.1 (Interne Router)

Attack Payloads

Target: vulnerable-app.lab/api/fetch?url=... WAITING
// Sende einen Payload, um die Antwort des Servers zu sehen...
Extracted Secret: NONE

Tooling for SSRF Discovery

# Burp Suite Collaborator

Das Goldstandard-Tool, um Out-of-Band (OOB) SSRF zu erkennen, indem man den Server eine externe Domain anpingen lässt.

GET /api/proxy?url=http://your-id.oastify.com HTTP/1.1

# FFUF (Fuzzing)

Nutze FFUF, um automatisch interne IP-Bereiche über einen SSRF-Vektor zu scannen.

ffuf -u http://target.lab/fetch?url=http://192.168.1.FUZZ -w ip_list.txt

SSRF FAQ

Was ist der 169.254.169.254 Endpunkt? ▼

Dies ist die Cloud Instance Metadata Service (IMDS) IP für AWS, Azure und Google Cloud. Wenn ein Server dort eine Anfrage stellt, erhält er Informationen über sich selbst – einschließlich temporärer IAM-Credentials. In den Händen eines Angreifers bedeutet dies oft den vollen Cloud-Breach.

Wie kann man SSRF effektiv verhindern? ▼

1. Whitelisting: Erlaube nur Anfragen an bekannte, vertrauenswürdige Domains.

2. Egress Filtering: Blockiere auf Firewall-Ebene alle ausgehenden Anfragen des Webservers an interne IP-Bereiche.

3. IMDSv2: In AWS erzwingt Version 2 der Metadaten einen Session-Header, was SSRF-Angriffe massiv erschwert.