Server-seitige Anfragefälschung (SSRF-Angriff)
Ein Leitfaden zu Server-Side Request Forgery (SSRF-Angriffen)
Ein SSRF-Angriff nutzt eine Schwachstelle im Zusammenhang mit serverseitiger Request-Forgery aus, die auftreten kann, wenn eine API eine Remote-Ressource über eine vom Client bereitgestellte URL abruft, ohne diese zu überprüfen. Dadurch kann ein Angreifer den Server dazu zwingen, Anfragen an unbeabsichtigte Ziele zu senden, selbst wenn dieser hinter einer Firewall oder einem VPN steht.
SSRF tritt immer häufiger auf, da Entwicklungsmuster zunehmend das Abrufen von URLs auf Serverseite beinhalten. Webhooks, URL-basierte Dateiimporte, Link-Vorschauen und benutzerdefinierte Single-Sign-On-Integrationen fordern den Server jeweils dazu auf, eine vom Client bereitgestellte Adresse anzufragen. Jede dieser Funktionen stellt einen potenziellen SSRF-Einstiegspunkt dar, wenn die Zieladresse nicht validiert wird.
In Cloud-Umgebungen steht deutlich mehr auf dem Spiel. Interne Metadaten-Dienste sind in der Regel von innerhalb des Netzwerks über einfaches HTTP erreichbar, und eine SSRF-Sicherheitslücke legt die Anmeldedaten offen, die diese Dienste speichern.
Wichtigste Erkenntnisse
- Eine serverseitige Anfragefälschung (SSRF) liegt vor, wenn eine API eine Remote-Ressource über eine vom Client bereitgestellte URL abruft, ohne diese zu überprüfen, wodurch Angreifer den Server dazu zwingen können, Anfragen an unbeabsichtigte Ziele zu senden.
- SSRF tritt immer häufiger auf, da moderne Entwicklungsmuster wie Webhooks, das Abrufen von Dateien über URLs, URL-Vorschauen und benutzerdefiniertes SSO allesamt das serverseitige Abrufen von vom Client bereitgestellten URLs beinhalten.
- Cloud-Umgebungen machen SSRF besonders gefährlich, da interne Metadatendienste über HTTP erreichbar sind und bei Zugriff über einen SSRF-Angriff sensible Anmeldedaten offenlegen können.
- Blind-SSRF, bei dem dem Angreifer keine Antwort zurückgesendet wird, ist schwer zu erkennen, lässt sich aber dennoch ausnutzen. Angreifer können anhand von Unterschieden in den Antwortzeiten offene Ports und die Verfügbarkeit interner Dienste ableiten.
- Zur Vorbeugung ist es wichtig, Mechanismen zum Abrufen von Ressourcen zu isolieren, Whitelists für zulässige Ursprünge, URL-Schemas und Ports durchzusetzen, HTTP-Weiterleitungen zu deaktivieren und bewährte URL-Parser zu verwenden, um Inkonsistenzen beim Parsen zu vermeiden.
Warum ist das gefährlich?
Mithilfe von SSRF kann ein Angreifer den API-Server selbst in einen Proxy verwandeln, über den er auf die interne Infrastruktur zugreifen kann. Dieser Zugriff kann Folgendes ermöglichen:
- Zugriff auf interne Dienste, die nicht dafür vorgesehen sind, von außerhalb des Netzwerks erreichbar zu sein
- Diebstahl von Cloud-Zugangsdaten durch interne Metadaten-Endpunkte aufgedeckt
- Umgehung von Schutzmaßnahmen auf Netzwerkebene wie Firewalls und VPNs, da die Anfrage von einem vertrauenswürdigen Server stammt
- Blind-SSRF, bei dem zwar keine Antwort zurückgegeben wird, die Verfügbarkeit von Port und Dienst jedoch anhand von Zeitunterschieden abgeleitet wird
Typische Symptome
Unternehmen sind einem SSRF-Risiko ausgesetzt, wenn APIs:
- Eine direkt vom Client bereitgestellte URL abrufen, beispielsweise für einen Webhook oder einen Dateiimport, ohne das Ziel zu überprüfen
- HTTP-Weiterleitungen automatisch verfolgen, sodass eine ursprünglich sichere URL auf eine interne Adresse weiterleitet
- Es fehlt eine Whitelist, die festlegt, welche Ursprungsadressen, Protokolle oder Ports der Server erreichen darf
- Verwendung inkonsistenter oder unzureichend getesteter URL-Parser, wodurch Lücken zwischen der Validierungslogik und dem tatsächlichen Verhalten der Anfragen entstehen
Allgemein gesagt tritt der Fehler auf, wenn der Server ein vom Client angegebenes Ziel als vertrauenswürdig einstuft.
Maßnahmen zur Eindämmung von SSRF
Das Abrufen von Ressourcen muss isoliert und eingeschränkt werden und darf nicht standardmäßig offen bleiben.
- Isolieren Sie den Mechanismus zum Abrufen von Ressourcen in einem eigenen Netzwerksegment, da er in der Regel auf externe Ressourcen zugreifen muss und nicht auf interne.
- Eine Whitelist mit zulässigen Ursprüngen, URL-Schemas und Ports sowie akzeptierten Medientypen durchsetzen
- Automatische HTTP-Weiterleitungen deaktivieren
- Verwenden Sie bewährte URL-Parser, um Inkonsistenzen zu vermeiden, die Angreifer ausnutzen könnten
- Alle vom Client bereitgestellten Eingabedaten validieren und bereinigen
- Vermeiden Sie es, unverarbeitete Antworten aus der abgerufenen Ressource an den Client zurückzusenden.
Ein Server, der jeder URL vertraut, die ihm ein Client übermittelt, ist stets anfällig für Missbrauch.
