InhaltsverzeichnisKlicke auf den Link, um zur gewünschten Stelle zu navigieren
Wie SSRF funktioniertWarum der Server sehen kann, was der Angreifer nicht siehtSSRF und localhostSSRF in Cloud-InfrastrukturenWo SSRF am häufigsten auftrittWarum es nicht ausreicht, die URL einfach zu überprüfenWie man sich vor SSRF schützt1. Erlaubenliste2. Blockieren privater Adressen3. Redirects kontrollieren4. Protokolle einschränken5. NetzwerkisolierungBlind SSRFSSRF ist nicht einfach "eine Anfrage machen können"
Dieser Inhalt wurde automatisch aus dem Ukrainischen übersetzt.
Server-Side Request Forgery (SSRF) - ist eine Schwachstelle von Webanwendungen, die es einem Angreifer ermöglicht, den Server dazu zu bringen, eine HTTP-Anfrage an eine Ressource zu senden, die der Angreifer selbst nicht direkt öffnen kann.
Auf den ersten Blick mag das nicht sehr gefährlich erscheinen: Nun, der Server hat eine HTTP-Anfrage gemacht. Aber das Problem ist, dass der Server oft Zugriff auf interne Ressourcen hat, die im offenen Internet nicht verfügbar sind.
Zum Beispiel auf interne APIs, Datenbanken, Admin-Panels oder Cloud-Metadaten-Dienste.
Wie SSRF funktioniert
Stellen wir uns einen einfachen Dienst vor, der es ermöglicht, eine Datei über eine URL herunterzuladen:
https://example.com/download?url=https://tseivo.com/image.jpg
Der Server erhält die Adresse und lädt die Datei selbst herunter:
Benutzer
│
│ URL
▼
Webanwendung
│
│ HTTP-Anfrage
▼
https://tseivo.com/image.jpg
Das ist eine ganz normale Funktion.
Aber wenn der Server die übergebene URL nicht überprüft, kann der Benutzer anstelle einer externen Website eine interne Adresse angeben:
https://example.com/download?url=http://127.0.0.1:8080/admin
Jetzt führt der Server die Anfrage an 127.0.0.1:8080 aus.
Für den Angreifer kann das besonders interessant sein, wenn auf diesem Port ein interner Dienst läuft.
Warum der Server sehen kann, was der Angreifer nicht sieht
Stellen wir uns die Infrastruktur vor:
Internet
│
┌─────▼─────┐
│ Webserver │
└─────┬─────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
Internes Datenbank Admin
API Panel
Aus dem Internet ist nur der Webserver zugänglich.
Aber der Webserver selbst kann Zugriff auf interne APIs, Datenbanken oder Admin-Panels haben.
SSRF nutzt den Server tatsächlich als Vermittler:
Hacker │ │ "Mach eine Anfrage hier" ▼ Webserver │ │ Anfrage im Namen des Servers ▼ Internen Dienst
Das bedeutet, dass eine Firewall den direkten Zugriff des Angreifers auf die interne API hervorragend blockieren kann, aber SSRF ermöglicht es, diese Einschränkung über den Server zu umgehen, der bereits den erforderlichen Zugriff hat.
SSRF und localhost
Einer der einfachsten Angriffsvarianten ist der Zugriff auf localhost:
http://127.0.0.1/ http://localhost/
Oder auf einen bestimmten Port:
http://127.0.0.1:3000/ http://127.0.0.1:8080/
Dies kann den Zugriff auf Dienste ermöglichen, die absichtlich nur auf der lokalen Schnittstelle lauschen.
Zum Beispiel kann in der Produktion ein internes Admin-Panel laufen:
http://127.0.0.1:8080/admin
Von außen ist es nicht zugänglich.
Aber wenn Ihre Anwendung SSRF hat, kann sie selbst eine Anfrage an dieses Panel stellen.
SSRF in Cloud-Infrastrukturen
Besonders ernst wird SSRF in Cloud-Umgebungen.
In einigen Cloud-Plattformen kann der Server auf einen speziellen Metadaten-Dienst zugreifen, über den Informationen über die aktuelle Instanz oder deren Anmeldeinformationen abgerufen werden können.
Zum Beispiel kann die Anwendung Zugriff auf den Metadaten-Endpunkt haben, der Angreifer jedoch nicht.
Wenn der Angreifer SSRF findet, kann er versuchen, den Server dazu zu bringen, auf diesen Endpunkt zuzugreifen.
Im schlimmsten Fall kann dies dazu führen, dass Anmeldeinformationen erhalten werden und weiterer Zugriff auf Ressourcen der Cloud-Infrastruktur erfolgt.
Deshalb wird SSRF oft nicht nur als Problem mit HTTP-Anfragen betrachtet, sondern als potenzieller Weg zur Kompromittierung der gesamten Infrastruktur.
Wo SSRF am häufigsten auftritt
SSRF sollte in Funktionen gesucht werden, in denen der Server eine URL vom Benutzer erhält.
Zum Beispiel:
- Bild-Uploads über URL;
- Datenimport von einer externen API;
- Webhooks;
- URL-Überprüfungen;
- Generierung von Vorschauen von Webseiten;
- PDF- oder Screenshot-Dienste;
- URL-Entfaltung in Chats;
- Integrationen mit anderen Diensten;
- Funktionen wie fetch, proxy oder download.
Zum Beispiel könnte gefährlicher Code sehr einfach aussehen:
url = params[:url] response = HTTP.get(url)
Das Problem liegt hier nicht bei HTTP.get an sich.
Das Problem ist, dass der Benutzer tatsächlich die Möglichkeit erhalten hat, zu bestimmen, wohin der Server die Anfrage senden wird.
Warum es nicht ausreicht, die URL einfach zu überprüfen
Man könnte denken, dass es ausreicht, Folgendes zu blockieren:
localhost 127.0.0.1
Aber der Schutz vor SSRF ist komplizierter.
Es gibt verschiedene Darstellungen von IP-Adressen, DNS-Tricks, Redirects und andere Möglichkeiten, naive Überprüfungen zu umgehen.
Zum Beispiel kann der Server zuerst die Domain überprüfen:
https://example.com
und dann eine HTTP-Weiterleitung an eine interne Adresse erhalten.
Deshalb sollte nicht nur die URL, die der Benutzer ursprünglich übergeben hat, überprüft werden, sondern auch die endgültige Adresse, zu der tatsächlich eine Verbindung hergestellt wird.
Wie man sich vor SSRF schützt
Der beste Schutz besteht darin, dem Benutzer keine beliebigen serverseitigen Anfragen zu erlauben.
Wenn das nicht möglich ist, können mehrere Schutzebenen verwendet werden.
1. Erlaubenliste
Statt einer Blacklist ist es besser, nur bekannte Domains zuzulassen:
api.example.com images.example.com
und nicht zu versuchen, alle Adressen aufzulisten, die blockiert werden müssen.
2. Blockieren privater Adressen
Es sollte der Zugriff auf Folgendes blockiert werden:
127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
und auch auf andere spezielle und link-lokale Adressen.
3. Redirects kontrollieren
Es sollte nicht erlaubt werden:
external-site.com
↓
internal-service
Die Überprüfung sollte auch für Redirects gelten.
4. Protokolle einschränken
Wenn die Funktionen ausreichend HTTP/HTTPS sind, sollten keine beliebigen Schemas wie Folgendes erlaubt werden:
file:// gopher:// ftp://
5. Netzwerkisolierung
Selbst wenn SSRF auftritt, sollte der Server nicht in der Lage sein, kritische interne Systeme zu erreichen.
Das ist ein gutes Beispiel für das Prinzip der Verteidigung in der Tiefe: sich nicht auf einen einzigen Schutzmechanismus zu verlassen.
Blind SSRF
Es gibt noch eine interessante Variante - blind SSRF.
In diesem Fall sendet der Server eine Anfrage an eine Ressource, aber das Ergebnis wird dem Angreifer nicht zurückgegeben.
Zum Beispiel:
Angreifer │ │ URL ▼ Webanwendung │ │ Anfrage ▼ Interner Dienst
Der Angreifer sieht die Antwort nicht, kann aber dennoch feststellen, dass die Anfrage stattgefunden hat, anhand indirekter Hinweise.
Zum Beispiel kann der Server einen kontrollierten Endpunkt des Angreifers ansprechen, und dieser sieht die eingehende Anfrage in seinen Logs.
Blind SSRF ist schwieriger auszunutzen, kann aber dennoch ein ernstes Problem darstellen.
SSRF ist nicht einfach "eine Anfrage machen können"
Die Hauptgefahr von SSRF liegt in der Differenz zwischen dem, was der Benutzer sehen kann, und dem, was der Server sehen kann.
Der Benutzer hat möglicherweise nur Zugriff auf:
Internet
der Server jedoch auf:
Internet + Internes Netzwerk + localhost + Cloud-Metadaten + Private APIs
SSRF ermöglicht es dem Angreifer, diese zusätzlichen Berechtigungen des Servers auszunutzen.
Deshalb sollte jede Funktion der Art:
"Gib mir eine URL, und ich lade sie für dich herunter"
als potenzielle SSRF-Angriffsfläche betrachtet werden.
Zusammenfassend: SSRF ist eine Situation, in der ein Angreifer Ihren Server dazu bringt, Netzwerk-Anfragen in seinem Namen zu machen. Und je mehr interne Ressourcen dem Server zur Verfügung stehen, desto schwerwiegender können die Folgen einer solchen Schwachstelle sein.
