Eine Anwendung ruft serverseitig eine vom Benutzer gelieferte URL ab (z. B. für Linkvorschauen). Was ist das Risiko und die Lösung?
Kurzantwort
Das serverseitige Abrufen von durch Angreifer kontrollierten URLs ist Server-Side Request Forgery (SSRF): Es ermöglicht den Zugriff auf interne Dienste oder den Cloud-Metadaten-Endpunkt, um Zugangsdaten zu stehlen. Mildern Sie es durch eine Allow-List erlaubter Hosts und Schemata, das Sperren privater und Link-Local-Bereiche (mit erneuter Prüfung nach jeder Weiterleitung) und das Härten des Metadatenzugriffs mit IMDSv2. Zu sagen, es gebe kein Risiko, ignoriert den Zugriff, den die Anfrage gewährt, und ein Lade-Spinner oder Caching ändert nichts daran, wohin der Server sich verbinden darf.
Wenn Ihr Server eine vom Benutzer kontrollierte URL abruft — für eine Linkvorschau, einen Webhook, einen Avatar-Import — wird er zum „verwirrten Stellvertreter". Der Angreifer stellt die Anfrage nicht selbst, aber er bestimmt, wohin Ihr Server sie stellt. Das ist Server-Side Request Forgery (SSRF), und in Cloud-Infrastruktur ist es eine der gefährlichsten Fehlerklassen.
Warum dies das eigentliche Risiko ist
Der Server befindet sich meist in einem vertrauenswürdigen Netzwerk mit weit größerer Reichweite als jeder externe Client. Durch eine URL wie http://169.254.169.254/latest/meta-data/ kann ein Angreifer die Cloud-Metadaten der Instanz auslesen — einschließlich temporärer IAM-Zugangsdaten — und in Ihr Konto pivotieren. Er kann auch interne Admin-Oberflächen, Datenbanken und nicht authentifizierte Microservices erreichen, die annehmen: „Wenn du mich erreichst, bist du vertrauenswürdig." Genau so eskalierten mehrere große Cloud-Vorfälle aus einer einfachen Vorschaufunktion.
Die richtige Lösung
Verteidigen Sie in der Tiefe:
- Allow-List der genauen Hosts und Schemata, die Sie abrufen wollen (nur
https, nur bekannte Domains). Eine Allow-List schlägt geschlossen fehl; eine Deny-List „schlechter" Bereiche übersieht immer etwas. - Lösen Sie den Hostnamen selbst auf und sperren Sie private, Loopback- und Link-Local-Bereiche (
127.0.0.0/8,10/8,192.168/16,169.254/16, IPv6-Äquivalente) — und prüfen Sie nach jeder Weiterleitung erneut, denn ein erlaubter Host kann Sie per 302 auf169.254.169.254umleiten. - Härten Sie die Metadaten mit IMDSv2, das ein signiertes Sitzungs-Token via PUT verlangt und so das einfache GET, das ein SSRF ausführen kann, vereitelt.
Warum die anderen Antworten falsch sind
„Kein Risiko — es ist nur ein HTTP-Abruf" ist genau die Denkweise, die SSRF ausliefert; die Gefahr liegt in der Netzwerkposition, nicht im Protokoll. Ein Lade-Spinner ist ein UX-Detail. Die Antwort zu cachen kann es sogar verschlimmern, indem interne Daten gespeichert werden. Keine dieser Optionen beschränkt, wohin der Server sich verbindet — und genau das ist das Problem, das der Interviewer ergründet.
Wahrscheinliche Anschlussfragen
- Wie verhindert man SSRF über DNS-Rebinding oder eine HTTP-Weiterleitung auf 169.254.169.254?
- Warum ist eine Allow-List von Hosts sicherer als eine Deny-List privater Bereiche?
- Was ändert IMDSv2 daran, wie der Metadaten-Endpunkt erreicht werden kann?