Was ist SSRF?

SSRF einfach erklärt

Stellen Sie sich den Empfang eines Bürogebäudes vor. Besucher dürfen nur in die Lobby, der Empfang dagegen hat Schlüssel für alle Räume. Bittet ein Besucher: „Holen Sie mir doch bitte das Dokument aus Raum 12“, sollte der Empfang vorher prüfen, ob der Besucher das überhaupt darf. Tut er das nicht, kommt der Besucher über diesen Umweg an alles heran – auch an das Archiv oder das Büro der Geschäftsführung.

Bei SSRF übernimmt ein Webserver die Rolle des Empfangs. Viele Anwendungen laden Inhalte aus dem Internet nach: ein Profilbild von einer angegebenen Adresse, eine Linkvorschau oder Daten für einen Webhook, also eine automatische Benachrichtigung an ein anderes System. Prüft die Anwendung die angegebene Adresse nicht streng genug, kann ein Angreifer stattdessen interne Ziele eintragen.

Der englische Name bedeutet sinngemäß „serverseitige Anfragefälschung“. Nicht zu verwechseln ist SSRF mit CSRF, bei der der Browser einer angemeldeten Person missbraucht wird.

So funktioniert SSRF

1. Funktion finden: Der Angreifer sucht eine Stelle, an der die Anwendung eine von außen angegebene Adresse (URL) abruft – etwa beim Import von Dateien per Link.
2. Internes Ziel eintragen: Statt einer normalen Internetadresse gibt er eine interne Adresse an, z. B. die Verwaltungsoberfläche eines internen Systems.
3. Server als Werkzeug nutzen: Der Server stellt die Anfrage aus dem internen Netz heraus. Die Firewall am Netzwerkrand bemerkt davon nichts, denn die Anfrage kommt von innen – von einem vertrauenswürdigen System.
4. Antwort auswerten: Die Anwendung gibt die Antwort zurück oder verrät durch ihr Verhalten, ob ein Ziel existiert. Im zweiten Fall spricht man von Blind SSRF.

Besonders kritisch ist SSRF in der Cloud. Virtuelle Server können dort über einen internen Metadatendienst Informationen über sich selbst abrufen – unter Umständen auch temporäre Zugangsdaten. Liest ein Angreifer diese über SSRF aus, kann er im Namen des Servers auf weitere Cloud-Ressourcen zugreifen, etwa auf Datenspeicher.

Ein Beispiel aus der Praxis

Ein Softwareanbieter betreibt eine Cloud-Plattform für Eventplanung. Kunden können ihr Firmenlogo per Link hochladen. Bei einem Penetrationstest tragen die Tester statt eines Bildlinks die Adresse des internen Metadatendienstes ein. Die Plattform liefert die Antwort als vermeintlich defektes Bild zurück – samt temporärer Zugangsdaten des Servers.

Diese Zugangsdaten haben deutlich mehr Rechte als nötig, darunter Lesezugriff auf den Speicher mit allen Kundendokumenten. Der Anbieter beschränkt die Logo-Funktion auf geprüfte Bildquellen, sperrt interne Adressbereiche, erzwingt die Schutzfunktionen des Metadatendienstes und reduziert die Rechte des Servers auf das Nötigste.

Warum ist das für Unternehmen wichtig?

SSRF hebelt eine verbreitete Annahme aus: dass interne Systeme sicher sind, solange sie von außen nicht erreichbar sind. Über einen einzigen anfälligen Server können Angreifer interne Verwaltungsoberflächen, Datenbanken oder Cloud-Zugangsdaten erreichen. Aus einer harmlos wirkenden Funktion wird so schnell ein Datenleck oder sogar die Übernahme ganzer Cloud-Umgebungen.

Die Bedeutung zeigt sich auch in den Standards: Die OWASP Top 10, die bekannteste Übersicht der kritischsten Risiken für Webanwendungen, führten SSRF 2021 erstmals als eigene Kategorie. In der Ausgabe 2025 zählt SSRF dort zur fehlerhaften Zugriffskontrolle (Broken Access Control). Die OWASP API Security Top 10 von 2023 nennen SSRF als eigenes Risiko.

So schützen Sie sich

• Erlaubte Ziele festlegen: Die Anwendung ruft nur Adressen aus einer festen Liste erlaubter Domains und Protokolle ab.
• Interne Adressen sperren: Interne Adressbereiche werden blockiert. Geprüft wird die tatsächliche Zieladresse, nicht nur der eingegebene Name – sonst lässt sich die Sperre mit Tricks umgehen.
• Weiterleitungen kontrollieren: Die Anwendung folgt Weiterleitungen nicht automatisch oder prüft jedes neue Ziel erneut.
• Ausgehenden Verkehr begrenzen: Server dürfen nur die Verbindungen aufbauen, die sie wirklich brauchen. Eine saubere Segmentierung begrenzt zusätzlich, was erreichbar ist.
• Metadatendienst absichern: Aktivieren und erzwingen Sie dessen Schutzfunktionen – etwa die Pflicht, vor jeder Abfrage ein besonderes Zugangstoken anzufordern. Daran scheitern einfache SSRF-Anfragen.
• Rechte minimieren: Server in der Cloud erhalten nur die Berechtigungen, die sie für ihre Aufgabe benötigen.
• Antworten filtern: Die Anwendung gibt abgerufene Inhalte nicht ungeprüft an Nutzende weiter. Ein Logo-Import liefert z. B. nur echte Bilddaten zurück.

Wie Rootsektor unterstützt

Im Cloud-Penetrationstest prüfen wir, ob Angreifer über Schwachstellen wie SSRF an Zugangsdaten gelangen und ihre Rechte in Ihrer Cloud-Umgebung ausweiten können. Anwendungen und Schnittstellen testen wir im Penetrationstest für Webanwendungen und im API-Penetrationstest. Der Retest der behobenen Schwachstellen ist kostenlos.