Server-Side Request Forgery (SSRF) verhindern

1. Was ist Server-Side Request Forgery?

Server-Side Request Forgery, kurz SSRF, tritt auf, wenn eine Anwendung eine vom Nutzer beeinflussbare URL entgegennimmt und selbst eine HTTP-Anfrage an diese URL stellt. Typische Beispiele sind Webhook-Konfigurationen, Bildimporte per URL, PDF-Generatoren, die eine externe Seite rendern, oder Funktionen, die entfernte Dateien herunterladen. Die Schwachstelle gehört seit Jahren zu den OWASP Top 10 und gewinnt mit der Verbreitung von Cloud-Infrastruktur zusätzlich an Relevanz.

Der Server agiert dabei aus Sicht des Zielsystems als vertrauenswürdiger interner Client. Ein Angreifer, der die Ziel-URL kontrolliert, kann diese Anfrage nutzen, um Ressourcen anzusprechen, die von außen gar nicht erreichbar wären, etwa interne Netzwerksegmente, Datenbank-Admin-Oberflächen oder Cloud-Metadaten-Dienste.

2. Typische Einfallstore in Anwendungen

Am häufigsten entsteht SSRF über Funktionen, die explizit eine URL vom Client entgegennehmen: Ein Webhook-Ziel, ein Profilbild-Import per Link, eine URL-Vorschau-Funktion in einem Chat oder ein PDF-Renderer, der eine externe Seite als Vorlage lädt. Auch scheinbar harmlose Funktionen wie ein Link-Checker oder ein RSS-Feed-Import können SSRF ermöglichen, wenn die Ziel-URL nicht eingeschränkt wird. Selbst Funktionen, die nur mittelbar mit URLs arbeiten, etwa ein Dienst, der eine Domain auf Erreichbarkeit prüft, können missbraucht werden, um interne Adressen abzutasten.

Die abgesicherte Variante im folgenden Beispiel prüft den Host gegen eine feste Allowlist, erzwingt HTTPS, löst den Hostnamen selbst auf und lehnt private oder reservierte IP-Bereiche ab, um DNS-Rebinding-Tricks zu erschweren. Zusätzlich werden automatische Redirects deaktiviert, da ein Angreifer sonst über eine erlaubte URL auf eine interne Weiterleitung umleiten könnte.

<?php

declare(strict_types=1);

namespace App\Service;

use Symfony\Contracts\HttpClient\HttpClientInterface;

final class WebhookImageFetcher
{
    private const ALLOWED_HOSTS = [
        'images.trusted-partner.com',
        'cdn.mironsoft.de',
    ];

    public function __construct(
        private readonly HttpClientInterface $httpClient,
    ) {
    }

    // Verwundbar: Jede vom Client übergebene URL wird direkt angefragt
    public function fetchVulnerable(string $imageUrl): string
    {
        $response = $this->httpClient->request('GET', $imageUrl);

        return $response->getContent();
    }

    // Abgesichert: Nur explizit erlaubte Hosts dürfen angefragt werden
    public function fetchSecured(string $imageUrl): string
    {
        $host = parse_url($imageUrl, PHP_URL_HOST);
        $scheme = parse_url($imageUrl, PHP_URL_SCHEME);

        if ($scheme !== 'https' || $host === null || !\in_array($host, self::ALLOWED_HOSTS, true)) {
            throw new \InvalidArgumentException('URL host is not on the allowlist.');
        }

        $ip = gethostbyname($host);
        if ($this->isPrivateOrReservedIp($ip)) {
            throw new \InvalidArgumentException('Resolved IP is not publicly routable.');
        }

        $response = $this->httpClient->request('GET', $imageUrl, [
            'max_redirects' => 0,
        ]);

        return $response->getContent();
    }

    private function isPrivateOrReservedIp(string $ip): bool
    {
        return filter_var(
            $ip,
            FILTER_VALIDATE_IP,
            FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE
        ) === false;
    }
}

3. Cloud-Metadaten-Endpunkte als Hauptziel

Ein besonders beliebtes SSRF-Ziel sind Cloud-Metadaten-Dienste, die unter einer festen Link-lokalen Adresse wie 169.254.169.254 erreichbar sind und ohne Authentifizierung Instanz-Informationen ausliefern, teilweise inklusive temporärer Zugangsdaten für die Cloud-API. Kann ein Angreifer den Server dazu bringen, diese Adresse anzufragen und die Antwort zurückzugeben, erhält er potenziell weitreichenden Zugriff auf die gesamte Cloud-Infrastruktur, etwa auf Speicher-Buckets, Datenbanken oder sogar auf die Fähigkeit, weitere Serverinstanzen zu steuern.

Aus diesem Grund gehört die explizite Sperrung link-lokaler und privater IP-Bereiche zu den wichtigsten Maßnahmen gegen SSRF, unabhängig davon, ob die Anwendung überhaupt in einer Cloud-Umgebung mit Metadaten-Dienst läuft, da sich Angriffsziele im Lauf der Infrastruktur-Lebenszeit ändern können. Viele große Anbieter haben inzwischen zusätzliche Schutzmechanismen wie IMDSv2 eingeführt, die einen Token-basierten Zugriff erzwingen und einfache SSRF-Anfragen erschweren, ersetzen aber keine saubere Validierung auf Anwendungsebene.

4. Warum eine reine Blockliste nicht ausreicht

Eine Blockliste, die bekannte interne IP-Bereiche wie 127.0.0.1 oder 10.0.0.0/8 ausschliesst, wirkt auf den ersten Blick ausreichend, lässt sich aber auf vielfältige Weise umgehen: durch alternative IP-Schreibweisen wie Oktalzahlen oder Dezimalnotation, durch DNS-Rebinding, bei dem ein Hostname zunächst auf eine erlaubte IP und nach der Prüfung auf eine interne IP aufgelöst wird, oder durch offene Redirects auf erlaubten Domains.

Eine Allowlist bekannter, vertrauenswürdiger Ziel-Hosts umgeht diese Probleme grundsätzlich, weil nur explizit freigegebene Ziele überhaupt in Frage kommen. Wo eine feste Allowlist fachlich nicht möglich ist, etwa bei frei wählbaren Webhook-Zielen von Kunden, muss zusätzlich die aufgelöste IP-Adresse unmittelbar vor der eigentlichen Anfrage geprüft werden, um DNS-Rebinding zu verhindern. Wichtig ist dabei, dieselbe aufgelöste IP-Adresse für die Prüfung und für die eigentliche Anfrage zu verwenden, statt zweimal getrennt aufzulösen, da sonst erneut ein Zeitfenster für Rebinding entsteht.

5. Netzwerkseitige Absicherung

Neben der Validierung auf Anwendungsebene sollte der Server, der externe Anfragen ausführt, netzwerkseitig so segmentiert werden, dass er interne Systeme wie Datenbanken, Admin-Panels oder Cloud-Metadaten-Dienste gar nicht erst erreichen kann. Eine dedizierte Egress-Firewall-Regel für den ausführenden Dienst reduziert den Schaden selbst dann, wenn eine Anwendungslücke übersehen wurde. Dieses Prinzip der Verteidigung in mehreren Schichten ist besonders wichtig, weil Anwendungslogik sich im Laufe eines Projekts ständig ändert, während eine grundlegende Netzwerksegmentierung stabiler bleibt.

In containerisierten Umgebungen bietet sich zusätzlich ein separater, stark eingeschränkter Netzwerk-Namespace für Dienste an, die externe URLs verarbeiten, sodass ein erfolgreicher SSRF-Angriff bestenfalls ins Leere läuft, weil das Zielsystem aus diesem Namespace ohnehin nicht erreichbar ist. Ergänzend lohnt sich eine regelmäßige Überprüfung der Firewall-Regeln, da neue Dienste im Laufe der Zeit gerne mit zu großzügigen Standardregeln ausgestattet werden.

6. Sicherer Umgang mit der Antwort

Auch die Antwort einer SSRF-anfälligen Anfrage muss sorgfältig behandelt werden. Wird der komplette Response-Body ungefiltert an den Client zurückgegeben, kann ein Angreifer interne Systeme regelrecht durch die eigene Anwendung hindurch auslesen, auch wenn die Anfrage selbst durch eine Allowlist eingeschränkt ist.

Sinnvoll sind eine Begrenzung der maximalen Antwortgröße, ein Timeout für die Anfrage sowie eine Prüfung des Content-Type, damit etwa ein Bildimport tatsächlich nur Bilddaten akzeptiert und keine beliebigen Textinhalte durchreicht. Wird die Antwort anschließend weiterverarbeitet, etwa in einer Bildbibliothek, sollte auch diese Verarbeitung isoliert erfolgen, um Folgeschwachstellen in der Bildverarbeitung selbst auszuschließen.

7. Code-Review-Checkliste für SSRF

Bei jedem Code-Review sollte gezielt nach Funktionen gesucht werden, die eine URL, einen Hostnamen oder eine IP-Adresse aus Nutzereingaben entgegennehmen und für eine eigene HTTP-Anfrage verwenden. Für jede dieser Funktionen ist zu prüfen, ob eine Allowlist existiert, ob Redirects kontrolliert werden und ob private IP-Bereiche ausgeschlossen sind.

Besonders im Blick behalten sollte man Bibliotheken von Drittanbietern, etwa für PDF-Generierung oder URL-Vorschauen, da diese häufig eigene HTTP-Clients mitbringen, die Redirects und interne Adressen standardmäßig nicht einschränken. Ein Blick in die Konfigurationsoptionen dieser Bibliotheken lohnt sich, da viele davon durchaus eine eigene Allowlist oder eine Option zum Blockieren interner Adressen anbieten, die aber oft nicht standardmäßig aktiviert ist.

8. Häufige Fehler bei der Absicherung

Ein häufiger Fehler ist, nur die ursprünglich vom Nutzer eingegebene URL zu prüfen, aber nicht die tatsächlich aufgelöste IP-Adresse, wodurch DNS-Rebinding weiterhin möglich bleibt. Ein weiterer Fehler ist, Redirects unverändert zu folgen, sodass eine zunächst erlaubte URL auf eine interne Adresse umleiten kann.

Auch das voreilige Vertrauen in interne Netzwerkkomponenten ist riskant: Selbst wenn ein Reverse Proxy grundsätzlich vorgeschaltet ist, sollte die Anwendung selbst keine ungeprüften Anfragen an beliebige Ziele stellen, da nicht jede Komponente in der Kette zwingend konsistent konfiguriert ist.

9. Best Practices und Checkliste

Jede Funktion, die eine externe URL anfragt, sollte auf eine feste Allowlist erlaubter Hosts und Schemata prüfen, die aufgelöste IP-Adresse unmittelbar vor der Anfrage validieren und automatische Redirects deaktivieren oder streng kontrollieren.

Ergänzend gehören eine Begrenzung von Antwortgröße und Timeout, eine netzwerkseitige Segmentierung des ausführenden Dienstes sowie eine gezielte Prüfung von Drittanbieter-Bibliotheken mit eigenem HTTP-Client zu einer robusten SSRF-Absicherung.

10. Zusammenfassung

11. FAQ: SSRF