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

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

Die anfällige Funktion wirkt oft harmlos

Anwendungen rufen externe 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 trägt.

Eine kurze Liste von Zeichenfolgen zu blockieren, reicht nicht aus. Alternative IP-Darstellungen, IPv6-Formate, Weiterleitungen, Benutzerinformationssyntax 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

• Nur erforderliche Protokollschemata und Ports zulassen sowie Zugangsdaten, Fragmente, mehrdeutige Hostsyntax und nicht kanonische Adressformate ablehnen.
• Den Hostnamen auflösen, jede zurückgegebene Adresse klassifizieren und Loopback-, private, Link-Local-, Multicast- und reservierte Bereiche sowohl für IPv4 als auch für IPv6 ablehnen.
• Jedes Weiterleitungsziel erneut validieren und die Verbindung an die validierte Adresse binden, damit DNS sich zwischen der Prüfung und der Anfrage nicht ändern kann.
• Grenzwerte für Antwortgröße, Inhaltstyp, Zeitüberschreitung und Weiterleitungen anwenden, damit ein zulässiger Abruf nicht zur Ressourcenerschöpfung führen kann.

Netzwerkkontrollen müssen Anwendungsprüfungen absichern

Die Anwendungsvalidierung entwickelt sich weiter und kann Rückschritte machen, weshalb die Laufzeitumgebung eine unabhängige Ausgangsverkehrsgrenze benötigt. Ein dedizierter Abrufdienst mit einer eng gefassten Positivliste, einem isolierten Netzwerkpfad und ohne Zugriff auf produktive Steuerungsebenen reduziert drastisch, was ein Parserfehler erreichen kann.

Auch Schutzmaßnahmen für Cloud-Metadaten sind wichtig. Sitzungsorientierte Metadatenprotokolle sollten, sofern unterstützt, vorgeschrieben, Metadatenrouten auf Netzwerkebene blockiert und der abrufenden Workload die kleinstmögliche Identität zugewiesen werden. Falls eine Anfrage dennoch einen internen Zugangsdatenendpunkt erreicht, sollte es dort kaum oder gar nichts Nützliches 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 Teile des Antwortinhalts preisgeben.

Der nachweisorientierte Ansatz von KENSAI zeichnet die Klassifizierung des Ziels und die tatsächlich verbundene Adresse auf. So wird eine vermeintliche Blockierung zu überprüfbaren Belegen dafür, dass die Anfrage die vorgesehene Netzwerkgrenze niemals überschritten hat.

Fazit

Behandeln Sie das Abrufen externer Inhalte als privilegierten Netzwerkzugriff. Validieren und binden 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.