VenedyLaut OWASP-Seite: Exploitability "Easy", Prevalence "Common", Detectability "Easy", Technical Impact "Moderate", Business Impact "Specific". Hinweis: Basic SSRF (Antwort wird an den Angreifer zurückgegeben) ist leichter auszunutzen als Blind SSRF, bei dem der Angreifer kein Feedback über den Erfolg erhält.
Wie der Angriff funktioniert
Viele moderne API-Funktionen sollen externe Ressourcen abrufen, deren Adresse der Client vorgibt - etwa beim Hochladen eines Profilbilds per URL, bei Webhooks, URL-Vorschauen oder Single-Sign-On.
Fehlt eine saubere Validierung dieser vom Nutzer gelieferten URI, kann der Angreifer statt einer harmlosen externen Adresse ein internes Ziel angeben (z. B. localhost, interne IP-Bereiche oder Cloud-Metadaten-Endpunkte). Der Server führt die Anfrage dann mit seinen eigenen Netzwerkrechten aus und erreicht so Systeme, die von außen nicht zugänglich sind.
- Basic SSRF: Die Antwort wird an den Angreifer zurückgegeben (leicht ausnutzbar).
- Blind SSRF: Der Angreifer bekommt kein direktes Feedback und muss indirekt schließen (z. B. über Antwortzeiten), ob ein Port offen ist.
Begünstigend wirken Cloud-, Kubernetes- und Docker-Umgebungen, die Management- und Steuerkanäle über HTTP auf vorhersehbaren, wohlbekannten Pfaden bereitstellen.
Laut OWASP lässt sich das SSRF-Risiko nicht immer vollständig beseitigen; bei der Wahl der Schutzmaßnahme sind die Geschäftsrisiken und -bedürfnisse zu berücksichtigen.
Die API wird missbraucht, um interne Ziele anzufragen.
Beispiel
POST /graphql
[
{
"variables": {},
"query": "mutation { createNotificationChannel(input: { channelName: \"ch_piney\", notificationChannelConfig: { customWebhookChannelConfigs: [ { url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", send_test_req: true } ] } }) { channelId } }"
}
]Auswirkung
Erfolgreiche Ausnutzung kann zu Enumeration interner Dienste (z. B. Port-Scanning), Informationsabfluss, dem Umgehen von Firewalls oder anderen Sicherheitsmechanismen führen.
In manchen Fällen lässt sich ein Denial-of-Service auslösen, oder der Server wird als Proxy missbraucht, um bösartige Aktivitäten zu verschleiern.
Im Webhook-Beispiel kann der Angreifer über den Cloud-Metadaten-Endpunkt sogar gültige Cloud-Zugangsdaten erbeuten. Die technische Auswirkung ist laut OWASP "Moderate", der geschäftliche Schaden "Specific" (kontextabhängig).
So schützt man sich
- Den Ressourcen-Abrufmechanismus im Netzwerk isolieren - diese Funktionen sollen externe, nicht interne Ressourcen holen.
- Wo möglich Allow-Lists verwenden: für erlaubte Remote-Quellen (z. B. Google Drive, Gravatar), für erlaubte URL-Schemata und Ports sowie für akzeptierte Medientypen je Funktion.
- HTTP-Weiterleitungen (Redirects) deaktivieren.
- Einen gut getesteten und gepflegten URL-Parser einsetzen, um Probleme durch Inkonsistenzen beim URL-Parsing zu vermeiden.
- Alle vom Client gelieferten Eingabedaten validieren und bereinigen.
- Keine rohen (unveränderten) Antworten an den Client zurückgeben.