IT-Sicherheit Glossar

Was ist SSRF?

Server-Side Request Forgery, kurz SSRF, entsteht, wenn eine Anwendung eine vom Benutzer gewählte oder beeinflusste URL abruft. Der Angreifer nutzt den Server als Vermittler, um interne Dienste, Cloud-Metadaten oder vertrauenswürdige Partnersysteme zu erreichen, die nicht direkt aus dem Internet zugänglich sind.

Typische Einstiegspunkte sind URL-Vorschauen, Webhook-Tests, Bildimporte und PDF-Generatoren. Bei Blind SSRF wird die Antwort nicht direkt zurückgegeben. Timing, DNS-Abfragen oder Callbacks können trotzdem belegen, dass der Server die Anfrage gestellt hat.

Wie lässt sich SSRF verhindern?

  • - Beliebige URLs vermeiden und benötigte Schemas, Hosts sowie Ports über eine Positivliste erlauben.
  • - Jedes Ziel einschließlich Weiterleitungen auflösen und prüfen; private, Loopback- und Link-Local-Netze sperren.
  • - Ausgehenden Netzwerkverkehr von Anwendungssystemen auf Netzwerkebene begrenzen.
  • - Cloud-Metadatendienste schützen und Workloads keine unnötigen Zugangsdaten zuweisen.

Codebeispiel: Ziel auswählen statt URL übernehmen

Verwundbar:

// Der Nutzer kontrolliert Schema, Host, Port und Pfad
$response = Http::get($request->input('url'));

Sicherer Entwurf für bekannte Integrationen:

$providers = [
    'billing' => 'https://billing.example/api/status',
    'shipping' => 'https://shipping.example/api/status',
];

$provider = $request->string('provider')->toString();
abort_unless(array_key_exists($provider, $providers), 400);

$response = Http::timeout(3)
    ->withoutRedirecting()
    ->get($providers[$provider]);

Eine Auswahl aus festen Zielen ist robuster als das Filtern beliebiger URLs. Muss eine URL frei sein, sind ein einheitlicher URL-Parser, DNS-/IP-Prüfung bei jeder Verbindung und Weiterleitung sowie ausgehende Firewallregeln erforderlich.

Warum ist URL-Prüfung anspruchsvoll?

DNS kann im Zeitverlauf unterschiedliche Adressen liefern, Weiterleitungen ändern das Ziel und Parser bewerten ungewöhnliche URL-Formen verschieden. Eine sichere Lösung prüft das geparste und aufgelöste Ziel beim Verbindungsaufbau und kombiniert Anwendungskontrollen mit Netzwerkregeln.

Ein typischer SSRF-Angriffsweg

Ausgangspunkt ist häufig eine Funktion, die Bilder importiert, Webhooks prüft, PDFs erzeugt oder Vorschauen für eine URL erstellt. Der Angreifer ersetzt die erwartete externe Adresse durch ein internes Ziel. Der Server stellt die Verbindung aus seinem eigenen Netz und mit seiner Identität her. Dadurch erreicht er Dienste, die aus dem Internet nicht zugänglich sind, etwa Verwaltungsoberflächen, interne APIs oder Cloud-Metadatendienste.

Blind SSRF und mögliche Auswirkungen

Bei Blind SSRF zeigt die Anwendung die Antwort des Zielsystems nicht an. Der Angriff kann trotzdem anhand ausgehender DNS- oder HTTP-Anfragen, unterschiedlicher Laufzeiten oder Seiteneffekte nachweisbar sein. SSRF erlaubt je nach Umgebung das Scannen interner Ports, Auslesen von Zugangsdaten, Umgehen netzbasierter Zugriffskontrollen oder Auslösen interner Aktionen. Nicht jeder Fund führt automatisch zu Datenzugriff; Reichweite und Antwortverarbeitung müssen konkret geprüft werden.

Wie wird SSRF getestet?

Tester erfassen alle Funktionen, bei denen der Server eine vom Benutzer beeinflussbare Ressource abruft. Kontrollierte Testdomains zeigen ausgehende Verbindungen und DNS-Auflösung. Anschließend werden Redirects, alternative IP-Schreibweisen, IPv6, eingebettete Zugangsdaten und Unterschiede zwischen Validierung und tatsächlichem Abruf untersucht. Interne Produktivsysteme sollten nur nach Absprache und mit ungefährlichen Requests angesprochen werden.

Wirksame Absicherung in mehreren Schichten

Am sichersten ist eine feste Positivliste erlaubter Ziele und Protokolle. DNS-Auflösung und jede Weiterleitung müssen erneut geprüft werden; private, Loopback-, Link-Local- und Metadatenbereiche gehören gesperrt. Ein eigener Egress-Proxy kann Zielregeln technisch erzwingen und protokollieren. Cloud-Metadatendienste sollten zusätzliche Authentisierung verlangen. Netzwerkregeln begrenzen die Folgen, während die Anwendung weiterhin nur erwartete Ziele abrufen darf.

Penetrationstests

Sicherheitslücken aufdecken

Professionelle Penetrationstests für Ihr Unternehmen

Web Apps
Netzwerke
Mobile Apps
10% Neukunden-Rabatt
Jetzt planen

Mehr Informationsmaterial

Open-Source-Werkzeuge

Nur gegen freigegebene Ziele verwenden. Metadaten-, interne und zustandsändernde Requests benötigen besonders enge Testgrenzen; ein Callback beweist Erreichbarkeit, nicht automatisch die maximale Auswirkung.

Vielen Dank für dein Feedback! Wir werden es prüfen und unseren Artikel anpassen.

Hast du Feedback zum Thema Server-Side Request Forgery (SSRF)? Schreib uns!