Was ist SSRF und wie schützt man sich?
Autor: Redaktion Domeny.ForSale Veröffentlicht
Kurz erklärt: SSRF (Server-Side Request Forgery) ist eine Schwachstelle, durch die Angreifer den Anwendungsserver dazu bringen können, eine Anfrage an eine nicht vorgesehene Adresse zu senden. So kann der Server Ressourcen erreichen, die nicht direkt über das Internet zugänglich sind, etwa Dienste im internen Netzwerk. Anders als bei CSRF, wo der Browser des Nutzers ausgenutzt wird, sendet bei SSRF der Server selbst die Anfrage.
Wie SSRF funktioniert – ein einfaches Beispiel
Stell dir eine Anwendung vor, in der sich ein Produktfoto durch Einfügen einer Bildadresse hinzufügen lässt. Der Nutzer gibt eine URL an, also die Adresse einer Ressource. Der Server lädt die Datei herunter und speichert sie im Verzeichnis des Shops. Das ist praktisch, doch die Anwendung muss prüfen, wohin sie tatsächlich eine Verbindung aufbaut.
Akzeptiert sie beliebige Adressen, kann ein Angreifer statt eines Fotos einen Dienst angeben, der nur aus dem Netzwerk des Servers erreichbar ist. Die Anwendung wird damit zum Vermittler: Sie sendet eine Anfrage an ein Ziel, das der Angreifer selbst nicht erreichen könnte. Gibt sie die empfangenen Inhalte zusätzlich an den Nutzer zurück, kann sie interne Daten offenlegen.
Das lässt sich mit einem Empfangsmitarbeiter vergleichen, der auf Wunsch beliebiger Personen Dokumente aus verschlossenen Räumen holt. Das Problem ist nicht das Holen der Dokumente an sich, sondern die fehlende Prüfung, woher sie geholt und an wen sie weitergegeben werden dürfen.
Daten von einer vom Nutzer angegebenen Adresse abzurufen, ist für sich genommen noch keine Schwachstelle. SSRF liegt vor, wenn der Nutzer eine Anfrage an ein Ziel außerhalb des erlaubten Bereichs lenken kann und die Anwendung keine entsprechenden Beschränkungen durchsetzt.
Wo SSRF auftritt und welche Folgen es haben kann
SSRF kann jede Funktion betreffen, die anhand nutzerkontrollierter Daten eine Verbindung zu einer anderen Ressource herstellt. Typische Beispiele sind Linkvorschauen, der Import von Dokumenten, das Herunterladen von Bildern und die Erstellung von PDF-Dateien aus Webseiten. Ein ähnliches Risiko besteht bei Webhooks, also automatischen Benachrichtigungen, die an eine angegebene Adresse gesendet werden.
Die Folgen hängen davon ab, auf welche Ressourcen der Server zugreifen kann und wie die Anwendung mit der Antwort umgeht. Mögliche Auswirkungen sind:
- das Auslesen von Informationen aus internen Diensten;
- das Ermitteln der Dienste, die im Netzwerk des Servers erreichbar sind;
- der Zugriff auf Metadaten der Cloud-Umgebung, die mitunter Zugangsdaten enthalten;
- das Ausführen von Aktionen in einem Dienst, der Datenverkehr aus dem internen Netzwerk fälschlicherweise als vertrauenswürdig behandelt.
SSRF bedeutet nicht automatisch, dass der gesamte Server übernommen wird. Das Risiko steigt jedoch, wenn die Anwendung weitreichenden Netzwerkzugriff hat und interne Dienste keine Authentifizierung verlangen.
Daneben gibt es blind SSRF, eine Variante, bei der der Angreifer die Antwort der abgerufenen Ressource nicht direkt sieht. Dass keine Inhalte angezeigt werden, beseitigt die Schwachstelle nicht: Schon das Senden der Anfrage kann eine unerwünschte Aktion auslösen oder durch das Verhalten der Anwendung Informationen preisgeben.
SSRF und CSRF – ähnliche Namen, andere Mechanismen
Bei CSRF (Cross-Site Request Forgery) wird der Browser eines Nutzers dazu gebracht, eine unerwünschte Anfrage an eine Anwendung zu senden. Dabei kann der Browser automatisch Sitzungsdaten mitsenden, etwa das Cookie eines angemeldeten Nutzers. Meist geht es darum, eine Aktion mit dessen Berechtigungen auszuführen.
Bei SSRF sendet dagegen der Server die Anfrage. Der Angriff nutzt dessen Netzwerkzugriff und gegebenenfalls dessen Berechtigungen aus. Dafür muss grundsätzlich kein Opfer angemeldet sein, auch wenn die anfällige Funktion selbst möglicherweise erst nach einer Anmeldung zugänglich ist.
| Merkmal | SSRF | CSRF |
|---|---|---|
| Wer sendet die Anfrage? | Der Anwendungsserver | Der Browser des Nutzers |
| Was wird ausgenutzt? | Zugriffsmöglichkeiten und Berechtigungen des Servers | Die Sitzung des Nutzers |
| Zentraler Schutzansatz | Verbindungsziele und Netzwerkzugriff kontrollieren | Zustandsändernde Anfragen prüfen, unter anderem mit CSRF-Tokens |
Diese Schutzmaßnahmen sind nicht gegeneinander austauschbar. Ein CSRF-Token löst nicht das Problem eines Servers, der Daten von unzulässigen Adressen abruft. Umgekehrt ersetzt das Filtern ausgehender Verbindungen nicht den Schutz der Nutzersitzung.
Wie sich das SSRF-Risiko begrenzen lässt
Prüfe zuerst, ob die Anwendung tatsächlich Daten von beliebigen Adressen abrufen muss. Wenn die Integration nur einen Dienst betrifft, ist es sicherer, dessen Adresse in der Konfiguration zu hinterlegen und vom Nutzer lediglich eine Ressourcenkennung entgegenzunehmen.
Wenn Nutzer Adressen angeben müssen, setze mehrere Schutzebenen ein:
- Beschränke die zulässigen Ziele. Verwende nach Möglichkeit eine abschließende Liste vertrauenswürdiger Hosts, Ports und Protokolle. Prüfe Adressen nicht allein durch die Suche nach einem Textfragment.
- Prüfe die Ziel-IP-Adressen. Berücksichtige IPv4 und IPv6 und sperre unzulässige Bereiche, darunter private Netzwerke, lokale Adressen und spezielle Endpunkte für Cloud-Metadaten.
- Kontrolliere Weiterleitungen und DNS. Eine unbedenklich wirkende Adresse kann zu einer unzulässigen Ressource weiterleiten. Die Prüfung muss das tatsächliche Verbindungsziel erfassen, nicht nur die ursprüngliche URL.
- Beschränke den ausgehenden Datenverkehr. Netzwerkregeln sollten verhindern, dass die Anwendung auf Dienste zugreift, die sie nicht benötigt. Lege außerdem Zeitlimits und eine maximale Antwortgröße fest.
Übermittle Cookies, Tokens oder andere Zugangsdaten nicht automatisch an Adressen, die Nutzer angeben. Prüfe in einer Cloud-Umgebung auch die offizielle Dokumentation des Anbieters zum Schutz des Metadatendienstes.
Womit du bei der Prüfung einer Anwendung beginnen kannst
Liste die Funktionen auf, bei denen der Server Daten anhand einer Adresse oder eines anderen vom Nutzer angegebenen Werts abruft. Kläre für jede Funktion, welche Verbindungsziele zulässig sind, wie Weiterleitungen behandelt werden und welche Daten an den Nutzer zurückgegeben werden.
Führe Tests ausschließlich in deiner eigenen Umgebung oder mit Zustimmung des Eigentümers durch. Wähle zunächst eine Funktion aus, etwa den Bildimport, und prüfe, ob ihre Beschränkungen auch nach einer Weiterleitung greifen – nicht nur bei der im Formular eingegebenen Adresse.
Siehe auch: Was bedeutet www?
Lesen Sie auch
