SSRF (Server-Side Request Forgery): Ablauf, Beispiele und Schutz

Was ist SSRF?

Viele Webanwendungen rufen selbst Adressen auf. Sie laden ein Bild von einer URL, erzeugen eine Linkvorschau oder schicken einen Webhook an ein anderes System. Die Zieladresse kommt dabei oft vom Nutzer.

Prüft die Anwendung diese Adresse nicht richtig, kann ein Angreifer ein anderes Ziel eintragen. Der Server ruft es dann auf, und zwar aus dem internen Netz heraus. Firewalls, die Zugriffe von außen abwehren, greifen in diesem Fall nicht.

Der Name beschreibt genau das: Die Anfrage wird auf dem Server (server-side) gefälscht (forgery).

So läuft ein SSRF-Angriff ab

Ein vereinfachtes Beispiel: Eine Anwendung bietet eine Funktion „Bild von URL importieren“. Normal sieht die Anfrage so aus:

POST /import
url=https://example.com/logo.png

Der Angreifer trägt stattdessen eine interne Adresse ein:

POST /import
url=http://localhost:8080/admin

1. Einstiegspunkt finden: Der Angreifer sucht eine Funktion, die eine URL oder einen Hostnamen annimmt.
2. Ziel ändern: Er setzt eine interne Adresse ein, etwa localhost, eine private IP-Adresse oder den Metadatendienst der Cloud.
3. Server fragt an: Der Server ruft das Ziel mit seinen eigenen Rechten und aus seinem Netz heraus auf.
4. Ergebnis auswerten: Je nach Anwendung bekommt der Angreifer die Antwort zu sehen oder schließt aus Fehlermeldungen und Antwortzeiten, was intern erreichbar ist.

Typische Einstiegspunkte

• Import per URL: Bilder, Dokumente oder Feeds, die der Server von einer Adresse lädt.
• Linkvorschau: Chat- und Social-Funktionen, die Titel und Vorschaubild einer Seite abrufen.
• Webhooks: Nutzer hinterlegen eine Adresse, an die der Server Ereignisse schickt.
• PDF- und Bildgeneratoren: Werkzeuge, die HTML rendern und dabei eingebettete Ressourcen nachladen.
• XML-Verarbeitung: Externe Entitäten in XML (XXE) können ebenfalls Anfragen auslösen.
• Interne Proxys und APIs: Dienste, die Anfragen an andere Dienste weiterreichen und das Ziel aus Parametern übernehmen.

Was Angreifer mit SSRF erreichen

• Interne Dienste: Admin-Oberflächen, Datenbanken oder Caches, die nur intern lauschen und oft keine Anmeldung verlangen.
• Cloud-Zugangsdaten: Der Metadatendienst unter 169.254.169.254 kann temporäre Schlüssel der Server-Rolle liefern.
• Netzwerk erkunden: Über Antwortzeiten und Fehler lässt sich ein internes Netz Stück für Stück abtasten.
• Lokale Dateien: Erlaubt die Anwendung andere Protokolle wie file://, kann der Angreifer Dateien vom Server lesen.
• Weitere Angriffe: Eine erreichte interne Schnittstelle mit Schwachstelle kann bis zur Ausführung von Code führen.

Beispiel: Der Fall Capital One

2019 erbeutete eine Angreiferin Daten von rund 100 Millionen Kunden der US-Bank Capital One. Der Einstieg war eine falsch konfigurierte Web Application Firewall in der AWS-Cloud. Über sie fragte sie den Metadatendienst ab und erhielt Zugangsdaten einer Server-Rolle. Diese Rolle hatte zu viele Rechte und durfte Speicher-Buckets mit Kundendaten lesen.

Der Fall zeigt, wie SSRF und zu großzügige Rechte zusammenwirken. AWS hat danach die zweite Version des Metadatendienstes (IMDSv2) eingeführt, die solche Angriffe deutlich erschwert.

Arten von SSRF

• Einfaches SSRF: Die Anwendung gibt die Antwort des Ziels an den Angreifer zurück. Er sieht direkt, was intern abrufbar ist.
• Blind SSRF: Die Antwort bleibt verborgen. Der Angreifer erkennt nur, dass eine Anfrage stattfand, etwa über einen Rückruf an seinen eigenen Server oder über Laufzeitunterschiede.

Warum einfache Filter nicht reichen

Eine Sperrliste mit „localhost“ und „127.0.0.1“ ist schnell umgangen. Angreifer nutzen dafür unter anderem:

• Andere Schreibweisen: 127.0.0.1 lässt sich auch als 2130706433, 0x7f000001 oder [::1] schreiben.
• Eigene Domains: Ein Hostname, der auf eine interne IP-Adresse zeigt, sieht für einen Textfilter harmlos aus.
• Weiterleitungen: Die erlaubte Adresse leitet auf ein internes Ziel weiter.
• DNS-Rebinding: Der Hostname liefert bei der Prüfung eine erlaubte und beim eigentlichen Abruf eine interne IP-Adresse.
• Unterschiede beim Parsen: Prüfung und Abruf lesen dieselbe URL unterschiedlich.

So schützen Sie sich vor SSRF

1. Freigabeliste statt Sperrliste: Lassen Sie nur die Ziele zu, die die Funktion wirklich braucht. Wenn möglich, wählt der Nutzer nur aus festen Optionen.
2. IP-Adresse nach der Auflösung prüfen: Lösen Sie den Hostnamen auf, prüfen Sie die IP-Adresse und verbinden Sie sich genau mit dieser. Private, Loopback- und Link-Local-Bereiche werden gesperrt.
3. Nur nötige Protokolle erlauben: In der Regel reichen https und http. Protokolle wie file://, gopher:// oder ftp:// werden abgelehnt.
4. Weiterleitungen nicht blind folgen: Schalten Sie sie ab oder prüfen Sie jedes neue Ziel wie das erste.
5. Antworten nicht durchreichen: Geben Sie dem Nutzer nur das zurück, was die Funktion braucht, und keine rohen Fehlermeldungen.
6. Ausgehenden Verkehr begrenzen: Anwendungsserver dürfen per Firewall nur die Ziele erreichen, die sie brauchen. Funktionen, die fremde URLs abrufen, laufen am besten in einem eigenen Segment. Siehe Netzwerksegmentierung.
7. Metadatendienst absichern: Bei AWS erzwingen Sie IMDSv2. Er verlangt ein Sitzungstoken, das eine einfache SSRF-Anfrage nicht mitliefern kann.
8. Rechte klein halten: Cloud-Rollen und Dienstkonten bekommen nur die Rechte, die sie brauchen. Dann richtet auch ein erbeuteter Schlüssel wenig Schaden an. Siehe Least-Privilege-Prinzip.

Eine Web Application Firewall kann zusätzlich bekannte Muster abfangen. Sie ersetzt aber keine dieser Maßnahmen.

SSRF erkennen

In den Protokollen fallen SSRF-Versuche oft durch ausgehende Verbindungen auf, die nicht ins Bild passen. Beispiele sind Anfragen eines Webservers an 169.254.169.254, an localhost oder an interne Adressen, mit denen er sonst nie spricht. Wer ausgehenden Verkehr der Anwendungsserver protokolliert und auf solche Ziele alarmiert, erkennt Angriffe früh.

Ob eine Anwendung anfällig ist, zeigt ein Penetrationstest. Tester prüfen dabei jede Funktion, die Adressen annimmt, auch auf Blind SSRF mit einem eigenen Rückruf-Server. SecTepe bietet dafür Penetrationstests für Webanwendungen und Infrastruktur.

SSRF in den OWASP Top 10

In den OWASP Top 10 von 2021 war SSRF eine eigene Kategorie (A10). In der Ausgabe 2025 wurde es in A01 Broken Access Control aufgenommen. Im CWE-Katalog trägt SSRF die Nummer CWE-918.

SSRF und CSRF: der Unterschied

Die Namen klingen ähnlich, die Angriffe sind verschieden. Bei Cross-Site Request Forgery (CSRF) schickt der Browser eines angemeldeten Nutzers ungewollt eine Anfrage. Bei SSRF schickt der Server selbst die Anfrage. Das Ziel von CSRF sind die Rechte des Nutzers, das Ziel von SSRF ist das Vertrauen, das der Server im internen Netz genießt.

Fazit

SSRF macht aus einer harmlosen Funktion wie einem Bildimport einen Zugang ins interne Netz. Besonders gefährlich ist das in der Cloud, wo Zugangsdaten nur eine Anfrage entfernt sind. Wirksam schützt eine Kombination aus Freigabeliste in der Anwendung, begrenztem ausgehendem Verkehr, abgesichertem Metadatendienst und knappen Rechten.