Was ist SSRF?

Bei einem SSRF-Angriff manipuliert der Angreifer in der Regel die Eingaben, die zur Angabe der Ziel-URL für eine serverseitige HTTP-Anforderung verwendet werden. Dies kann passieren, wenn eine Anwendung die URL-Eingabe eines Benutzers nicht validiert oder bereinigt, bevor sie Daten von einer entfernten Ressource abruft. Der Angreifer kann den Zielserver dazu bringen, Anforderungen an beliebige Ziele auszuführen, was zu verschiedenen Sicherheitsrisiken führen kann.

Diese Angriffe können auch dann erfolgen, wenn die angegriffene Ressource vertrauenswürdige Beziehungen zu anderen Systemen hat, z. B. zu einem Cloud-Metadatendienst oder Backend-APIs, so dass ein Angreifer Anforderungen an diese vertrauenswürdigen Dienste stellen und sensible Informationen extrahieren oder nicht autorisierte Aktionen durchführen kann.

Da moderne Webanwendungen den Endbenutzern bequeme Funktionen bieten, ist das Abrufen einer URL zu einem alltäglichen Szenario geworden. Infolgedessen nimmt die Häufigkeit von SSRF zu. Außerdem steigt der Schweregrad von SSRF mit der zunehmenden Verbreitung von APIs und Cloud-Diensten und mit der zunehmenden Dezentralisierung und Komplexität der Rechenarchitekturen.

SSRF gehört zu den OWASP Top 10 Sicherheitsrisiken für Anwendungen, einer weithin anerkannten Zusammenstellung der kritischsten Sicherheitsrisiken für Webanwendungen. SSRF ist auch eines der OWASP Top Ten Sicherheitsrisiken, die sowohl bei Anwendungen als auch bei APIs üblich sind und bei der Implementierung von Sicherheitslösungen besonders berücksichtigt werden müssen.

So funktioniert ein SSRF-Angriff:

• Die Anwendung erlaubt Benutzereingaben, um die Ziel-URL oder -Ressource für eine serverseitige Anforderung zu bestimmen. Diese Eingaben können aus Parametern in einer URL, Benutzereingaben aus Formularfeldern oder anderen Datenquellen stammen.
• Der Angreifer sendet eine speziell gestaltete Anforderung, wobei er die Eingabe so manipuliert, dass sie auf eine Ressource verweist, auf die er zugreifen oder die er ausnutzen möchte. Bei dieser Ressource kann es sich um einen internen Server, einen Backend-Dienst, eine API oder andere interne Systeme handeln, die hinter Firewalls liegen und vom externen Netzwerk aus nicht zugänglich sind.
• Der Server verarbeitet die böswilligen Eingaben des Benutzers und erstellt eine Anforderung an die angegebene URL. Diese Anforderung erfolgt aus der Perspektive des Servers und nicht aus der des Benutzers, sodass es sich um eine serverseitige Anforderung handelt.
• Befindet sich der angegriffene Server in einem internen Netzwerk, kann der Angreifer versuchen, auf sensible Informationen zuzugreifen und diese von internen Ressourcen abzurufen, um sie dann an einen externen, vom Angreifer kontrollierten Ort zu exfiltrieren. SSRF kann auch zum Scannen von Ports auf internen Systemen verwendet werden, was dem Angreifer hilft, potenzielle Schwachstellen und Sicherheitslücken zu identifizieren.
• SSRF-Angriffe sind besonders in Cloud-Umgebungen bedenklich, in denen Instanzen Zugang zu sensiblen Metadatendiensten haben könnten.
• Die Auswirkungen eines SSRF-Angriffs können schwerwiegend sein und reichen vom unberechtigten Zugriff auf sensible Daten und Dienste über die Ausnutzung interner Systeme bis hin zur Kompromittierung ganzer Cloud-Umgebungen.

So kann sich ein SSRF-Angriff in der Praxis abspielen.

Stellen Sie sich eine ungesicherte Webanwendung vor, die es Benutzern ermöglicht, Bilder zur Verarbeitung hochzuladen, mit einer Funktion, die es Benutzern ermöglicht, eine URL zu einem zu verarbeitenden Bild anzugeben. Anstatt jedoch eine legitime Bild-URL anzugeben, übermittelt der Angreifer eine sorgfältig gestaltete Eingabe mit einer bösartigen URL, die auf eine interne Ressource auf dem Anwendungsserver verweist, z. B. eine interne Datei oder eine Backend-Datenbank. Der Anwendungsserver verarbeitet die bösartige URL selbsttätig und stellt nach der Eingabe des Angreifers eine Anforderung an die durch die URL angegebene interne Ressource, um sensible Daten abzurufen oder eine Datenbank abzufragen und die Daten an den Angreifer zurückzugeben.

Sobald der Server kompromittiert ist, kann der Angreifer auch Anforderungen an externe Systeme stellen, nach Schwachstellen suchen oder mit Diensten interagieren, auf die der Server Zugriff hat. Die Auswirkungen eines SSRF-Angriffs können je nach Systemarchitektur und den Berechtigungen des kompromittierten Servers variieren. Angriffe können zu unberechtigtem Datenzugriff, zur Unterbrechung von Diensten oder zur Kompromittierung von internen Systemen führen.

SSRF-Angriffe lassen sich in verschiedene Typen einteilen, je nachdem, wie der Angreifer mit dem Server interagiert und Informationen extrahiert.

Bei einem Standard-SSRF-Angriff fügt der Angreifer eine bösartige URL als Teil der Benutzereingabe ein und veranlasst den Server, eine Anforderung an die angegebene Ressource zu stellen. Der Angreifer kann die Antwort des Servers direkt beobachten und Informationen über das interne Netzwerk erheben, z. B. wie er Daten abrufen oder zugängliche Dienste identifizieren kann.

Bei blinden SSRF-Angriffen erhält der Angreifer die Antwort des Servers nicht direkt, sondern bestätigt den Erfolg oder Misserfolg des SSRF-Angriffs indirekt durch die Beobachtung von Änderungen im Verhalten der Anwendung.

Der Angreifer sendet eine manipulierte Eingabe und zwingt den Server, eine Anforderung an eine externe oder interne Ressource zu stellen. Der Angreifer sucht nach beobachtbaren Änderungen in der Aktivität der Anwendung, wie z. B. Unterschiede in Fehlermeldungen, Antwortzeiten oder andere Nebeneffekte. Anhand dieser Informationen kann der Angreifer ableiten, ob die SSRF erfolgreich war, auch wenn er die Antwort nicht direkt sieht.

Bei zeitbasierten blinden SSRF-Angriffen werden Verzögerungen in den Antworten des Servers ausgenutzt, um auf den Erfolg oder Misserfolg des SSRF zu schließen, ohne die Antwort direkt zu sehen.

Wie bei anderen SSRF-Angriffen sendet der Angreifer eine bösartige Eingabe, die den Server veranlasst, eine Anforderung an eine externe oder interne Ressource zu stellen. Der Angreifer beobachtet die Zeit, die die Anwendung benötigt, um zu antworten. Verzögerungen bei der Antwortzeit können darauf hindeuten, dass die SSRF erfolgreich war. Der Angreifer passt die Nutzlast iterativ an und überwacht die Zeitverzögerungen, um Informationen über das interne Netzwerk oder die Ressourcen zu erhalten.

Um sich vor SSRF-Angriffen zu schützen, sollten Sie eine Kombination aus präventiven Cybersicherheitsmaßnahmen ergreifen:

• Eingabevalidierung: Validieren und bereinigen Sie Benutzereingaben rigoros, insbesondere wenn die Anwendung Anforderungen an externe Ressourcen stellt. Implementieren Sie eine URL-Allowlist, die nur vertrauenswürdige Domänen oder bestimmte URLs zulässt, auf die die Anwendung zugreifen muss. Stellen Sie sicher, dass nur die erwarteten Protokolle wie http und https zugelassen werden, und vermeiden Sie die Zulassung potenziell riskanter Protokolle wie file:// oder ftp://, die häufig für SSRF-Angriffe ausgenutzt werden. Überprüfen Sie außerdem, ob die von den Benutzern angegebenen URLs den erwarteten Mustern oder Formaten entsprechen, um die Wahrscheinlichkeit des Einschleusens bösartiger URLs zu verringern.
• Allowlisten für Hosts und IP-Adressen: Führen Sie eine Allowliste mit erlaubten Hosts und IP-Adressen, mit denen die Anwendung interagieren darf. Dies kann dazu beitragen, Anforderungen auf vertrauenswürdige und beabsichtigte Ziele zu beschränken und so die Angriffsfläche für SSRF zu verringern.
• Beschränken Sie den Zugriff auf interne Ressourcen: Implementieren Sie eine Netzwerksegmentierung, um die Exposition interner Ressourcen zu begrenzen. Stellen Sie sicher, dass externe Server nur minimalen Zugriff auf interne Systeme und Dienste haben. Konfigurieren Sie Web Application Firewalls (WAFs) und Zugriffskontrollen, um ausgehende Verbindungen vom Anwendungsserver zu beschränken. Lassen Sie nur notwendige und vordefinierte Verbindungen zu und blockieren Sie unnötigen ausgehenden Datenverkehr. Setzen Sie einen Reverse Proxy ein, der als Vermittler zwischen der Anwendung und externen Ressourcen fungiert. Konfigurieren Sie den Proxy so, dass er kontrolliert, auf welche externen Ressourcen die Anwendung zugreifen kann, und fügen Sie so eine zusätzliche Kontrollschicht hinzu.

Wie können diese Präventivmaßnahmen dazu beitragen, SSRF-Angriffe zu verhindern? Betrachten wir ein hypothetisches Szenario.

Ein Online-Inhaltsverwaltungssystem ermöglicht es Benutzern, URLs einzugeben, um externe Bilder in ihre Posts einzubetten. Dieses System verarbeitet von Benutzern eingegebene URLs ohne ordnungsgemäße Eingabevalidierung. Ein Angreifer, der sich der fehlenden Eingabevalidierung bewusst ist, versucht, das System auszunutzen, indem er eine bösartige URL bereitstellt, die auf eine interne Ressource verweist, z. B. einen internen API-Endpunkt oder einen Datenbankserver. Das Sicherheitsteam der Anwendung verbessert jedoch die Eingabevalidierung des Systems, um strenge Regeln für akzeptierte URLs durchzusetzen. Das System beginnt mit der Validierung, ob die von Benutzern bereitgestellten URLs den erwarteten Mustern entsprechen, und das Team implementiert eine Allowlist zulässiger Domänen für externe Ressourcen.

Der Angreifer sendet den Post mit einer manipulierten URL, die den SSRF-Fehler ausnutzen soll, aber die Eingabevalidierung erkennt nun die bösartige URL. Die Eingabevalidierung weist die bösartige URL während der Verarbeitung zurück und verhindert, dass die Anwendung eine Anforderung an die vom Angreifer angegebene interne Ressource stellt. Der SSRF-Angriff wird durch die verbesserte Eingabevalidierung vereitelt: Das System lässt keine unberechtigten Anforderungen an interne Ressourcen zu, und die Integrität und Sicherheit interner Systeme bleibt gewahrt.

Durch die Implementierung einer Eingabevalidierung kann die Anwendung böswillige Eingaben zurückweisen oder bereinigen, wodurch unberechtigte Anforderungen verhindert und das Risiko von SSRF-Angriffen gemindert wird.

SSRF-Angriffe sind gefährlich, da sie es Angreifern ermöglichen, herkömmliche Netzwerksicherheitsmaßnahmen wie Firewalls und Zugriffskontrollen zu umgehen, um auf sensible Informationen und Ressourcen zuzugreifen, die in der Regel innerhalb des internen Netzwerks einer Organisation geschützt sind und nicht für den direkten Zugriff aus dem Internet vorgesehen sind. Da SSRF-Angriffe erhebliche Risiken für die Vertraulichkeit, Integrität und Verfügbarkeit von Daten und Systemen darstellen, müssen Organisationen robuste Sicherheitsmaßnahmen und bewährte Praktiken implementieren, einschließlich WAFs, ordnungsgemäßer Eingabevalidierung, Zugriffskontrollen und Netzwerksegmentierung, um die Bedrohung durch SSRF-Schwachstellen zu mindern und sich vor einer möglichen Ausnutzung zu schützen.

F5 WAF-Lösungen blockieren und mindern ein breites Spektrum von Risiken, die sich aus den OWASP Top 10 ergeben, einschließlich SSRF. F5 WAF-Lösungen kombinieren Signatur- und Verhaltensschutz, einschließlich Threat Intelligence von F5 Labs und automatisierter Sicherheit durch maschinelles Lernen (ML), um mit neu auftretenden Bedrohungen Schritt zu halten. Sie erleichtern den Aufwand und die Komplexität der konsistenten Absicherung von Anwendungen in Clouds, lokalen und Umgebungen am Netzwerkrand und sind in einer Reihe von Bereitstellungsoptionen erhältlich. BIG-IP Advanced WAF ist eine robuste Lösung, die Ihre Anwendungen vor SSRF-Angriffen schützt und eine wichtige provisorische Lösung für Software-Schwachstellen bietet, während F5 Distributed Cloud WAF Anwendungen überall mit drastisch vereinfachten Abläufen durch eine benutzerfreundliche As-a-Service-Sicherheitsplattform absichert.

F5 Web Application and API Protection (WAAP)-Lösungen schützen die gesamte Angriffsfläche moderner Anwendungen mit umfassenden Schutzmaßnahmen, darunter WAF, API-Sicherheit, DDoS-Entschärfung auf L3–L7 und Bot-Abwehr gegen bösartige Automatisierung und automatisierte Bedrohungen. Die verteilte Plattform erleichtert die Bereitstellung konsistenter Richtlinien sowie die Skalierung der Sicherheit für Ihre gesamte Palette von Anwendungen und APIs, unabhängig davon, wo diese gehostet werden, und integriert Sicherheitsmaßnahmen in den API-Lebenszyklus und in weitere Ökosysteme.