SSRF (Server-Side Request Forgery) ist eine Sicherheitslücke, bei der ein Angreifer den Server dazu bringt, HTTP-Anfragen an beliebige Ziele zu senden — auch an interne Systeme, die von außen nicht erreichbar sind. Der Server wird dabei als Proxy missbraucht: Die Anfrage scheint vom vertrauenswürdigen Server zu kommen, nicht vom Angreifer.
Wie funktioniert ein SSRF-Angriff?
Viele Anwendungen holen Inhalte von URLs, die der Benutzer beeinflussen kann — etwa beim Import von Bildern, Webhooks, PDF-Generatoren oder Statusprüfungen. Gibt der Angreifer statt einer harmlosen Adresse eine interne URL an, führt der Server die Anfrage im internen Netzwerk aus:
http://localhost/admin— interne Verwaltungsoberflächehttp://169.254.169.254/latest/meta-data/— Cloud-Metadaten mit Zugangsdatenhttp://192.168.1.10/— Geräte im internen Netz
Folgen eines erfolgreichen SSRF
- Zugriff auf interne Dienste: Datenbanken, Admin-Oberflächen, Monitoring, die hinter der Firewall liegen.
- Cloud-Credentials: Der Metadaten-Endpunkt der Cloud-Umgebung liefert häufig Zugangsschlüssel.
- Firewall-Bypass: Interne Systeme, die nur lokale Zugriffe zulassen, werden erreichbar.
- Weitere Angriffe: SSRF kann mit Phishing, XSS oder anderen Schwachstellen kombiniert werden.
Schutzmaßnahmen gegen SSRF
- Allowlisten statt Blocklisten: Nur erlaubte Ziel-URLs zulassen, keine Deny-Liste interner IPs (die lässt sich umgehen).
- URL-Validierung: Schema, Hostname und IP-Adresse strikt prüfen — auch Umgehungen wie
localhost., hexadezimale IPs oder Redirects beachten. - Outbound-Filterung: Der Server darf ausgehend nur zu erlaubten Diensten sprechen, nicht ins interne Netz.
- Keine Roh-URLs vom Benutzer: Wo möglich, feste Zieladressen oder IDs statt voller URLs verwenden.
- Netzwerksegmentierung: IDS/IPS und interne Firewalls begrenzen den Schaden, falls eine Anfrage doch durchgeht.
SSRF im Kontext anderer Angriffe
SSRF gehört wie SQL-Injection, XSS und Phishing zu den häufigen Web-Schwachstellen. Anders als Angriffe auf den Browser des Nutzers zielt SSRF auf den Server selbst — die Kommunikation mit SSL/TLS und TLS-Handshake schützt die Verbindung, nicht aber die Zielwahl der Server-Anfragen.