SSRF verstehen – Teil 1: Einführung in Server-Side Request Forgery

Sep. 12, 2025

—

von

Was ist SSRF überhaupt?

Server-Side Request Forgery (SSRF) ist eine Sicherheitslücke, bei der ein Angreifer es schafft, dass der Server selbst Netzwerk-Anfragen ausführt – und zwar zu Zielen, die der Angreifer bestimmt.

Das klingt zunächst abstrakt. Machen wir es greifbar:

Dein Webserver ist wie ein Mitarbeiter, der Aufträge entgegennimmt.
Normalerweise soll er nur offizielle Anfragen bearbeiten – z. B. Bilder aus dem Internet laden.
Ein Angreifer schiebt ihm aber einen Auftrag unter, der ihn dazu bringt, intern im Firmennetzwerk herumzutelefonieren oder geheime Daten bei der Cloud anzufragen.
Der Mitarbeiter (der Server) gehorcht – und merkt nicht, dass er gerade ausgenutzt wird.

Warum ist das gefährlich?

Interne Systeme freilegen
Viele Unternehmen betreiben Dienste, die nicht ins Internet geöffnet sind – Admin-Panels, Datenbanken, Monitoring-Tools. SSRF kann den Server zwingen, trotzdem dorthin zu verbinden.
Cloud-Missbrauch
Große Cloud-Anbieter (AWS, Azure, GCP) haben spezielle „Metadaten-Services“, die Konfigurations-Infos bereithalten. Beispiel AWS: http://169.254.169.254/latest/meta-data/ Hierüber lassen sich z. B. API-Keys oder Rollen-Zugangsdaten abrufen. Über SSRF bekommt der Angreifer plötzlich vollen Cloud-Zugriff.
Daten exfiltrieren
Wenn der Server die Antwort des internen Dienstes an den Angreifer zurückgibt, kann dieser vertrauliche Informationen direkt abgreifen.

SSRF vs. CSRF – oft verwechselt

CSRF (Cross-Site Request Forgery): Der Browser eines Nutzers wird getäuscht, ungewollte Aktionen im Namen des Nutzers auszuführen. Beispiel: Ein unbedachter Klick löscht dein Konto.
SSRF (Server-Side Request Forgery): Der Server wird missbraucht, Requests dorthin zu senden, wo der Angreifer es will.

👉 Der Unterschied: Bei SSRF wird nicht dein Browser, sondern die gesamte Server-Infrastruktur in Mitleidenschaft gezogen.

Ein einfaches, aber gefährliches Beispiel

Nehmen wir an, ein Entwickler möchte ein Feature bauen:

„User sollen einfach eine Bild-URL angeben können, und wir laden das Bild automatisch und zeigen es an.“

In PHP könnte der Code so aussehen:

<?php
// Beispiel: Bild von externer URL laden
if (isset($_GET['url'])) {
    $url = $_GET['url']; // nimmt die Eingabe aus der URL
    $img = file_get_contents($url); // lädt die Ressource
    echo "<img src='data:image/png;base64," . base64_encode($img) . "' />";
}

Schritt für Schritt erklärt

$_GET['url']
- Hier wird der Wert des Parameters url aus der Adresszeile entgegengenommen.
- Beispiel: Aufruf mit http://example.com/image.php?url=https://example.org/logo.png führt dazu, dass $url den Wert https://example.org/logo.png erhält.
file_get_contents($url)
- Normalerweise liest file_get_contents() eine Datei.
- Aber: Wenn man eine URL übergibt, lädt es den Inhalt übers Internet.
- Das heißt: Der Server ruft diese URL ab – nicht der Browser des Besuchers!
base64_encode($img) + <img>
- Damit das Bild im Browser angezeigt werden kann, wird es Base64-kodiert und direkt eingebettet.
- Ergebnis: Der Nutzer sieht das gewünschte Bild.

Was kann der Angreifer tun?

Ein Angreifer könnte statt eines echten Bildes eine „gefährliche“ URL übergeben:

Zugriff auf lokale Services: http://localhost:8080/admin → Der Server fragt sein eigenes Admin-Interface ab.
Zugriff auf Cloud-Metadaten: http://169.254.169.254/latest/meta-data/iam/security-credentials/ → Liefert Zugangsdaten für AWS-Dienste.
Zugriff auf interne Firmennetze (z. B. 10.x.x.x oder 192.168.x.x): http://192.168.0.10:8080/db-console → Interne Datenbankoberfläche wird ungewollt erreichbar.

Da der Server diese Requests ausführt, agiert er als Proxy für den Angreifer.

Warum merken Entwickler das oft nicht sofort?

Auf den ersten Blick funktioniert der Code ja: Der User gibt eine URL ein, ein Bild wird geladen.
SSRF nutzt eine Logik-Lücke: Entwickler denken, sie hätten „nur“ ein Bild geladen – tatsächlich öffnen sie eine Tür ins gesamte Netzwerk.
Viele Frameworks und Standardfunktionen (file_get_contents, curl, requests in Python) unterstützen URLs, ohne Einschränkungen einzubauen.