Server-Side Request Forgery

Viele Internetdienste bestehen aus zwei Teilen: der Seite im Browser und einem Rechner im Rechenzentrum, der die eigentliche Arbeit erledigt. Dieser Rechner wird Server genannt. Oft holt er selbst Daten von anderen Adressen im Netz, etwa ein Vorschaubild zu einem Link, den ein Nutzer eingetippt hat. Bei Server-Side Request Forgery missbraucht ein Angreifer genau diese Funktion. Er gibt statt eines harmlosen Links eine Adresse an, die er nie selbst erreichen dürfte. Der Server ruft sie brav ab und liefert das Ergebnis zurück. Der Angreifer benutzt den Server also als Boten, der Türen öffnet, die für ihn verschlossen wären.

Warum ein Server ein gefährlicher Bote ist

Firmennetze sind meist wie ein Gebäude mit Pförtner aufgebaut. Von außen kommt man nur an die Empfangstheke, also an die öffentliche Website. Dahinter liegen Datenbanken, Verwaltungsoberflächen und Konfigurationsdienste ohne starken Schutz. Man hat sie bewusst schwach abgesichert, weil man annahm, dass ohnehin nur Kollegen von innen darauf zugreifen. Genau diese Annahme bricht ein SSRF-Angriff.

Besonders heikel wird es bei Diensten in der Cloud, also auf gemieteten Servern großer Anbieter. Dort gibt es eine interne Adresse, unter der ein Server seine eigenen Zugangsschlüssel abfragen kann. Wer den Server überredet, diese Adresse abzurufen, bekommt unter Umständen die Schlüssel zum gesamten Kundenkonto. Der bekannteste Fall dieser Art traf 2019 die US-Bank Capital One. Rund 100 Millionen Kundendatensätze wurden abgegriffen, die Aufarbeitung kostete das Unternehmen dreistellige Millionenbeträge.

Deshalb führt die Sicherheitsorganisation OWASP, die seit Jahren eine Rangliste der wichtigsten Web-Schwachstellen pflegt, SSRF als eigene Kategorie. Das ist ungewöhnlich: Die meisten Einträge dort sind breite Fehlerklassen, SSRF ist ein sehr konkreter Angriff. Aufgenommen wurde er, weil moderne Anwendungen ständig andere Dienste anfragen.

Vom harmlosen Link zur internen Adresse

Der Ablauf ist fast immer gleich. Eine Anwendung bietet ein Feld an, in das man eine Webadresse eintragen kann. Typische Beispiele sind ein Profilbild von einer fremden Seite, ein Import aus einem anderen Dienst oder eine Linkvorschau. Der Server nimmt die Adresse entgegen und ruft sie ab. Prüft er dabei nicht genau, wohin die Reise geht, ist die Lücke da.

Angreifer tragen dann Adressen ein, die auf das interne Netz zeigen. Dazu gehören der Server selbst oder Nummernbereiche, die nur firmenintern vergeben werden. Manchmal genügt schon die Reaktionszeit als Information: Antwortet eine Adresse schnell, existiert dort ein Dienst. So lässt sich das interne Netz kartieren, auch wenn man den Inhalt der Antwort nie zu sehen bekommt.

Der Schutz besteht nicht darin, gefährliche Adressen zu verbieten. Solche Sperrlisten lassen sich mit Umleitungen und ungewöhnlichen Schreibweisen von Zahlen fast immer umgehen. Wirksam ist der umgekehrte Weg: Man legt fest, welche wenigen Ziele erlaubt sind, und blockiert alles andere. Zusätzlich bekommt der abrufende Dienst möglichst wenige eigene Rechte, damit ein Treffer wenig einbringt.

SSRF in Sicherheitsmeldungen und KI-Werkzeugen

Im Alltag begegnet der Begriff vor allem in Meldungen über Sicherheitslücken. Wird eine Schwachstelle in einer Firewall, einem Chat-Server oder einer Software für Unternehmen bekannt, steht das Kürzel SSRF oft im Text. Meist folgt eine Aufforderung, ein Update einzuspielen. Auch Bug-Bounty-Programme, bei denen Firmen Geld für gemeldete Lücken zahlen, vergüten SSRF-Funde vergleichsweise hoch.

Neuen Auftrieb bekommt das Thema durch KI-Systeme. Sprachmodelle werden zunehmend mit Werkzeugen ausgestattet, die eigenständig Webseiten abrufen können. Damit entsteht genau die riskante Konstellation: Ein Server ruft Adressen ab, die aus einem Text stammen, den ein Fremder verfasst hat. Verwechseln sollte man SSRF trotzdem nicht mit Cross-Site Request Forgery. Dort wird der Browser eines eingeloggten Nutzers missbraucht, bei SSRF der Server selbst.