SSRF in APIs verhindern: Ziel-URLs sicher verarbeiten

Welche Funktion öffnet die Vertrauensgrenze?

Typische Fälle sind ein Dokumentimport per URL, eine Linkvorschau oder eine API, die Benachrichtigungen an eine vom Kunden hinterlegte Callbackadresse sendet. Der eingehende Aufruf und der spätere ausgehende Abruf sind zwei verschiedene Verbindungen. Die Anmeldung des Nutzers klärt noch nicht, ob er Ihren Server zu jedem erreichbaren Ziel schicken darf. OWASP API7:2023.

Betrachten Sie zuerst den tatsächlichen Weg: Welche Komponente löst Namen auf? Welcher HTTP-Client öffnet die Verbindung? Gibt es einen ausgehenden Proxy? Welche internen Netze, Verwaltungsdienste und Zugangsdaten sind dort erreichbar? Eine Webanwendung ohne direkte Datenbankberechtigung kann trotzdem einen gefährlichen Netzwerkzugang haben.

Eine öffentliche Zieladresse ist zudem nicht automatisch ein erlaubter Empfänger vertraulicher Informationen. Bei einem Callback müssen die Registrierung des Ziels, die Befugnis des Kunden und die versandten Daten zusammenpassen. Ein technisch zulässiger Verbindungsweg ersetzt keine Datenfreigabe.

Bekannte Quellen bevorzugen, freie Ziele bewusst isolieren

Die ersten beiden Varianten reduzieren den Raum möglicher Ziele. Sie sind kein pauschales Verbot kundeneigener Integrationen. Bei der dritten Variante muss der zusätzliche Aufwand Teil der Produktentscheidung sein. OWASP unterscheidet ebenfalls zwischen bekannten zulässigen Anwendungen und der deutlich schwierigeren Aufgabe, beliebige externe Ziele abzurufen. OWASP: SSRF Prevention, „Cases“.

Auch bei einem festgelegten Host sollten Pfad und Query aus erlaubten Bestandteilen entstehen. Wenn der Nutzer statt einer Dokumentkennung einen ganzen Pfad beisteuern darf, könnte er Funktionen außerhalb des Imports auswählen. URL-Bestandteile korrekt zu kodieren und erlaubte Operationen festzulegen sind deshalb getrennte Aufgaben.

URL, DNS und Verbindung als einen Vorgang behandeln

Nutzen Sie einen zur Laufzeit passenden URL-Parser und prüfen Sie die daraus gelesenen Bestandteile. Ein bloßer Textanfang wie „enthält unseren Partnernamen“ ist keine Hostprüfung. Erlauben Sie nur benötigte Protokolle und Ports; eingebettete Zugangsdaten haben in einem benutzerdefinierten Importziel normalerweise nichts zu suchen. Unklare oder fehlerhafte Angaben werden abgelehnt.

Die Namensprüfung allein reicht nicht. Derselbe Hostname kann auf unterschiedliche IPv4- oder IPv6-Adressen zeigen. Eine vorher geprüfte Auflösung hilft wenig, wenn die spätere Verbindungsbibliothek erneut auflöst und ein anderes Ziel verwendet. Prüfen Sie daher alle vom Verbindungsweg nutzbaren Adressen gegen Ihre Zielpolitik und stellen Sie sicher, dass die tatsächliche Verbindung diese Entscheidung nicht umgeht.

Für einen Abrufdienst, der ausschließlich öffentliche Quellen erreichen soll, gehören unter anderem interne, lokale und link-lokale Adressbereiche außerhalb seines erlaubten Zielraums. Dazu zählen auch Verwaltungs- und Metadatendienste der eigenen Umgebung. Übernehmen Sie dafür keine kurze handgeschriebene Blockliste als angeblich vollständige Lösung. Auswahl und Pflege geeigneter Adressklassifikation sowie Netzregeln sind Teil der Implementierung.

Wird ein zuvor geprüftes Ziel für die Verbindung fest gebunden, müssen Hostname, TLS-Servername und Zertifikatsprüfung trotzdem korrekt bleiben. Einfach die URL gegen eine IP-Adresse auszutauschen und Zertifikatsfehler zu ignorieren würde eine neue Schwäche schaffen. Proxys und Verbindungs-Pools gehören in dieselbe Betrachtung: Entscheidend ist, welche Komponente tatsächlich auflöst und verbindet. Das ist ein Integrationspunkt für Ihre Plattform, kein universell einsetzbarer Codeblock.

Weiterleitungen und mitgesendete Daten begrenzen

Deaktivieren Sie automatische Redirects, wenn die Funktion sie nicht benötigt. Falls sie nötig sind, prüfen Sie jeden neuen Zielschritt nach derselben Politik und begrenzen Sie die Zahl der Schritte. Eine einmal freigegebene Startadresse macht das Ziel einer Weiterleitung nicht vertrauenswürdig.

Übertragen Sie Authentifizierungsdaten und sensible Nutzlasten nicht ungeprüft an ein neues Ziel. Das betrifft neben Headern auch den Body einer Anfrage. Eine Weiterleitung kann je nach Status und Client das Verfahren samt Body fortsetzen. OWASP beschreibt beim Konsum externer APIs gerade solche Risiken durch blindes Folgen von Redirects. OWASP API10:2023.

Erlauben Sie dem Abrufdienst nur die benötigten Methoden. Für eine reine Vorschau besteht normalerweise kein Anlass, beliebige Schreibmethoden oder eigene Zugangsdaten des Hauptdienstes weiterzureichen. Begrenzen Sie außerdem Antwortgröße, dekomprimierte Datenmenge, Laufzeit und gleichzeitige Abrufe. Ein zulässiges Ziel kann langsam sein oder unerwartet viele Daten liefern.

Die erhaltenen Inhalte bleiben externe Daten. Weder eine erlaubte Domain noch eine erfolgreiche TLS-Verbindung macht ein Dokument automatisch sicher für Parser, HTML-Ausgabe oder weitere Verarbeitung. Dafür führt Externe APIs sicher einbinden weiter.

Den Abrufdienst vom restlichen Betrieb trennen

Eine zusätzliche Netzgrenze begrenzt Folgen einer fehlerhaften Anwendungsprüfung. Ein isolierter Abrufdienst benötigt zum Beispiel keinen Zugang zu internen Verwaltungsoberflächen, produktiven Datenbanken oder dem gesamten Netz anderer Dienste. Er sollte auch nur die Geheimnisse besitzen, die seine enge Aufgabe erfordert.

Ausgehende Netzregeln, ein geeigneter Egress-Proxy oder vergleichbare Plattformfunktionen können diese Grenze durchsetzen. Prüfen Sie dabei beide IP-Familien und den tatsächlich verwendeten Pfad. Eine Regel am falschen Container oder nur für einen Teil der Verbindungen liefert keinen vollständigen Nachweis. Eine noch so strenge ausgehende Regel ersetzt wiederum nicht die Eingabeentscheidung, welche öffentlichen Ziele und Daten für diesen Nutzer zulässig sind.

Für bekannte Partner können Änderungen an deren Zielbereichen Betriebsvorfälle auslösen. Legen Sie deshalb fest, wie eine notwendige Erweiterung geprüft wird und wer sie freigibt. Ein großzügiges „vorübergehend alles erlauben“ sollte nicht die normale Reaktion auf einen fehlgeschlagenen Import werden.

Eigene Schutzregeln kontrolliert nachweisen

Erstellen Sie für die konkrete Plattform eine kleine Entscheidungsmatrix. Verwenden Sie zunächst simulierte Auflösung und einen Verbindungsadapter, der nur aufzeichnet, welches Ziel gewählt würde. Geeignete Fälle sind eine erlaubte Quelle, ein unbekannter Host, ein unzulässiges Protokoll, mehrere DNS-Antworten mit einem unerlaubten Ziel, ein geändertes Ziel beim Verbindungsaufbau und eine Weiterleitung außerhalb der Erlaubnis.

Der Erfolg besteht jeweils darin, dass kein verbotener Verbindungsversuch den Adapter erreicht. Nur eine nachträgliche Fehlermeldung zu sehen reicht dafür nicht. Ergänzen Sie Grenzen für Antwortgröße und Dauer. Diese logischen Fälle ersetzen noch keinen Nachweis der tatsächlichen Netzisolierung.

Prüfen Sie den realen Verbindungsweg anschließend ausschließlich in einer freigegebenen eigenen Testumgebung mit dafür vorgesehenen Diensten. Für den Artikel wurden keine Zielsysteme zu SSRF-Prüfzwecken aufgerufen, keine internen Adressen getestet und keine SSRF-Payloadsammlung ausgeführt. Ein Parserbeispiel wäre ohne den Netzwerkpfad keine belastbare Schutzimplementierung; deshalb enthält diese Anleitung kein solches Universalrezept.

Führen Sie eine neue Zielpolitik zuerst mit inventarisierten erlaubten Integrationen ein. Bei einer berechtigten Fehlablehnung korrigieren Sie den konkreten Eintrag oder die betroffene Funktion. Bewahren Sie die letzte sichere Konfiguration auf. Falls die Schutzwirkung unklar ist, kann eine vorübergehende Pause des URL-Imports sinnvoller sein, als die Zielprüfung vollständig zu öffnen.

Was ein API-Check hier nicht beantworten kann

Ein gewöhnlicher öffentlicher Antwortcheck prüft nicht, wohin Ihre Anwendung später serverseitig verbindet. Auch ein SSRF-Schutz im Scanner selbst wäre nur dessen Schutz vor unerlaubten Zielaufrufen; daraus folgt keine Untersuchung Ihrer API auf SSRF.

Der API Security Check liefert daher keinen Nachweis für diesen Ablauf. Nutzen Sie Code-, Konfigurations- und eigene Integrationstests entlang des tatsächlichen Abrufwegs. Inventar und Versionierung helfen, alle Import- und Callbackfunktionen zu finden; Logging und Monitoring zeigen, wie zulässige Ablehnungen im Betrieb nachvollziehbar bleiben.

Passende nächste Schritte