SSRF ist ein Problem der Cloud-Identität, nicht nur eines URL-Filters

Kurz gesagt: Eine serverseitige Anfragefälschung kann eine harmlose Abruffunktion in einen Zugang zu internen Diensten und Cloud-Zugangsdaten verwandeln. Nachhaltige Schutzmaßnahmen beschränken Ziele, Weiterleitungen, DNS-Auflösung und Workload-Identität gemeinsam.

Die anfällige Funktion wirkt oft harmlos

Anwendungen rufen entfernte Inhalte für Linkvorschauen, Webhooks, Dokumentimporte, Bildverarbeitung und Sicherheitsscans ab. Die Gefahr beginnt, sobald ein Angreifer einen beliebigen Teil des Ziels kontrolliert und der Server Netzwerke erreichen kann, auf die der Angreifer keinen Zugriff hat. Die Anwendung wird zu einem Proxy, der das Vertrauen des Servers in interne Bereiche überträgt.

Eine kurze Liste von Zeichenfolgen zu blockieren, reicht nicht aus. Alternative IP-Darstellungen, IPv6-Formate, Weiterleitungen, Benutzerinfo-Syntax und DNS-Rebinding können eine scheinbar öffentliche URL in eine Anfrage an eine Loopback-Adresse, einen privaten Dienst oder einen Cloud-Metadatenendpunkt verwandeln, nachdem die Validierung bereits erfolgreich abgeschlossen wurde.

Jede Netzwerkentscheidung validieren

• Erlauben Sie nur erforderliche Schemas und Ports und lehnen Sie Zugangsdaten, Fragmente, mehrdeutige Hostsyntax und nicht kanonische Adressformate ab.
• Lösen Sie den Hostnamen auf, klassifizieren Sie jede zurückgegebene Adresse und lehnen Sie Loopback-, private, Link-Local-, Multicast- und reservierte Bereiche sowohl für IPv4 als auch für IPv6 ab.
• Validieren Sie jedes Weiterleitungsziel erneut und binden Sie die Verbindung an die validierte Adresse, damit DNS zwischen der Prüfung und der Anfrage keine Änderung bewirken kann.
• Legen Sie Grenzwerte für Antwortgröße, Inhaltstyp, Zeitüberschreitung und Weiterleitungen fest, damit ein erlaubter Abruf nicht zur Ressourcenüberlastung führen kann.

Netzwerkkontrollen müssen Anwendungsprüfungen absichern

Die Anwendungsvalidierung wird weiterentwickelt und kann Rückschritte aufweisen. Daher benötigt die Laufzeitumgebung eine unabhängige Ausgangsverkehrsgrenze. Ein dedizierter Abrufdienst mit einer eng gefassten Positivliste, einem isolierten Netzwerkpfad und ohne Zugriff auf produktive Steuerungsebenen reduziert erheblich, was ein Parserfehler erreichen kann.

Auch Schutzmaßnahmen für Cloud-Metadaten sind wichtig. Fordern Sie, sofern unterstützt, sitzungsorientierte Metadatenprotokolle, blockieren Sie Metadatenrouten auf Netzwerkebene und weisen Sie dem abrufenden Workload die kleinstmögliche Identität zu. Falls eine Anfrage dennoch einen internen Endpunkt für Zugangsdaten erreicht, sollte es dort kaum oder nichts Brauchbares zu stehlen geben.

Umgehungsklassen testen, nicht nur eine Nutzlast

Eine einzelne Anfrage an eine bekannte Metadatenadresse ist lediglich ein Smoke-Test. Eine vollständige SSRF-Testsuite deckt Kodierungstricks, dezimale und hexadezimale Adressen, gemischte IPv6-Notation, Weiterleitungsketten, DNS-Änderungen, Abweichungen zwischen Parsern und interne Hostnamen ab. Sie überprüft außerdem, dass Fehler weder Antwortzeiten noch Fragmente des Antwortinhalts preisgeben.

Der nachweisorientierte Ansatz von KENSAI zeichnet die Klassifizierung des Ziels und die tatsächlich verbundene Adresse auf. Dadurch wird aus einer scheinbaren Blockierung ein überprüfbarer Nachweis, dass die Anfrage die vorgesehene Netzwerkgrenze nie überschritten hat.

Fazit

Behandeln Sie das Abrufen entfernter Inhalte als privilegierten Netzwerkzugriff. Validieren und fixieren Sie Ziele, prüfen Sie Weiterleitungen erneut, beschränken Sie den Ausgangsverkehr und minimieren Sie die Workload-Identität, damit ein einzelner Parserfehler nicht zur Kompromittierung der Cloud führen kann.