Was ist SSRF?

SSRF ist eine Art von Sicherheitslücke, bei der ein Angreifer eine Webanwendung oder API dazu bringt, Anfragen an interne Ressourcen zu senden. Dies kann zu unbefugtem Zugriff, zur Offenlegung von Daten, zur Kompromittierung von Systemen und zur Ausführung von Schadcode aus der Ferne führen. Angreifer umgehen die Eingabevalidierung und zwingen Anwendungen dazu, auf schädliche Webziele zuzugreifen, selbst wenn sie durch eine Firewall oder eine Virtual-Private-Network(VPN)-Lösung geschützt sind.

Was ist ein SSRF-Angriff und wie funktioniert er?

Bei einem SSRF-Angriff manipuliert der Angreifer in der Regel Eingaben, die zur Angabe der Ziel-URL für eine serverseitige HTTP-Anfrage verwendet werden. Dies kann geschehen, wenn eine Anwendung die URL-Eingabe eines Benutzers nicht validiert oder bereinigt, bevor sie Daten von einer entfernten Ressource abruft. Der Angreifer kann den angegriffenen Server dazu bringen, Anfragen an beliebige Ziele zu senden, was verschiedene Sicherheitsrisiken mit sich bringen kann.

Diese Angriffe können auch auftreten, wenn die angegriffene Ressource Vertrauensbeziehungen zu anderen Systemen unterhält, etwa zu einem Cloud-Metadatendienst oder zu Backend-APIs. Dadurch kann ein Angreifer Anfragen an diese vertrauenswürdigen Dienste stellen und vertrauliche Informationen auslesen oder unbefugte Aktionen ausführen.

Da moderne Webanwendungen Endbenutzern praktische Funktionen bieten, ist das Abrufen einer URL zu einem gängigen Anwendungsfall geworden. Infolgedessen treten SSRF-Angriffe immer häufiger auf. Zudem nimmt der Schweregrad von SSRF zu, da APIs und Cloud-Dienste immer weiter verbreitet sind und Computing-Architekturen zunehmend dezentral und komplex werden.

SSRF gehört zu den OWASP Top 10 Application Security Risks, einer weithin anerkannten Zusammenstellung der kritischsten Sicherheitsrisiken für Webanwendungen. SSRF gehört außerdem zu den zehn größten Sicherheitsrisiken laut OWASP, die sowohl Apps als auch APIs betreffen, und erfordert bei der Implementierung von Sicherheitslösungen besondere Aufmerksamkeit.

So funktioniert ein SSRF-Angriff:

• Die Anwendung ermöglicht es, die Ziel-URL oder Ressource für eine serverseitige Anfrage anhand von Benutzereingaben festzulegen. Diese Eingaben können aus Parametern in einer URL, Eingaben in Formularfeldern oder anderen Datenquellen stammen.
• Der Angreifer sendet eine speziell präparierte Anfrage und manipuliert dabei die Eingabe so, 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 sich hinter Firewalls befinden und vom externen Netzwerk aus nicht zugänglich sind.
• Der Server verarbeitet die bösartige Eingabe des Benutzers und erstellt eine Anfrage an die angegebene URL. Diese Anfrage wird vom Server und nicht vom Browser des Benutzers aus gesendet, sodass es sich um eine serverseitige Anfrage handelt.
• Wenn sich der angegriffene Server in einem internen Netzwerk befindet, kann der Angreifer versuchen, auf interne Ressourcen zuzugreifen, vertrauliche Informationen daraus abzurufen und diese Daten anschließend an einen externen, vom Angreifer kontrollierten Ort zu übertragen. SSRF kann außerdem dazu verwendet werden, Ports interner Systeme zu scannen, um potenzielle Schwachstellen und Sicherheitslücken zu identifizieren.
• SSRF-Angriffe sind in Cloud-Umgebungen besonders besorgniserregend, da Instanzen dort möglicherweise Zugriff auf Dienste mit sensiblen Metadaten haben.
• Die Auswirkungen eines SSRF-Angriffs können schwerwiegend sein und vom unbefugten Zugriff auf sensible Daten und Dienste über die Ausnutzung interner Systeme bis hin zur Kompromittierung ganzer Cloud-Umgebungen reichen.

Beispiel für einen SSRF-Angriff

So kann ein SSRF-Angriff in der Praxis ablaufen.

Stellen Sie sich eine ungesicherte Webanwendung vor, über die Benutzer Bilder zur Verarbeitung hochladen können und die eine Funktion bietet, mit der sie die URL eines zu verarbeitenden Bildes angeben können. Anstatt jedoch eine legitime Bild-URL anzugeben, übermittelt der Angreifer eine sorgfältig präparierte Eingabe mit einer schädlichen URL, die auf eine interne Ressource des Anwendungsservers verweist, etwa eine interne Datei oder eine Backend-Datenbank. Der Anwendungsserver verarbeitet die schädliche URL ungeprüft und sendet entsprechend der Eingabe des Angreifers eine Anfrage an die in der URL angegebene interne Ressource, um vertrauliche Daten abzurufen oder eine Datenbank abzufragen und die Daten an den Angreifer zurückzugeben.

Sobald der Server kompromittiert wurde, kann der Angreifer auch Anfragen an externe Systeme senden, 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. Solche Angriffe können zu unbefugtem Datenzugriff, Dienstunterbrechungen oder einer Kompromittierung interner Systeme führen.

Drei grundlegende Arten von SSRF-Angriffen

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

Standard-SSRF-Angriff

Bei einem standardmäßigen SSRF-Angriff schleust der Angreifer eine schädliche URL als Teil der Benutzereingabe ein und veranlasst dadurch den Server, eine Anfrage an die angegebene Ressource zu senden. Der Angreifer kann die Antwort des Servers direkt einsehen und Informationen über das interne Netzwerk sammeln, etwa darüber, wie sich Daten abrufen oder zugängliche Dienste identifizieren lassen.

Blinder SSRF-Angriff

Bei blinden SSRF-Angriffen erhält der Angreifer die Antwort des Servers nicht direkt. Stattdessen stellt er den Erfolg oder Misserfolg des SSRF-Angriffs indirekt fest, indem er Veränderungen im Verhalten der Anwendung beobachtet.

Der Angreifer übermittelt eine manipulierte Eingabe und zwingt den Server dadurch, eine Anfrage an eine externe oder interne Ressource zu senden. Anschließend sucht der Angreifer nach erkennbaren Veränderungen im Verhalten der Anwendung, etwa nach abweichenden Fehlermeldungen, Antwortzeiten oder anderen Nebeneffekten. Anhand dieser Informationen kann der Angreifer darauf schließen, ob der SSRF-Angriff erfolgreich war, obwohl er die Antwort nicht direkt sieht.

Zeitbasierter blinder SSRF-Angriff

Bei zeitbasierten blinden SSRF-Angriffen werden Verzögerungen bei den Serverantworten ausgenutzt, um auf den Erfolg oder Misserfolg der SSRF zu schließen, ohne die Antwort direkt einsehen zu können.

Wie bei anderen SSRF-Angriffen übermittelt der Angreifer eine manipulierte Eingabe, die den Server dazu veranlasst, eine Anfrage an eine externe oder interne Ressource zu senden. Der Angreifer beobachtet, wie lange die Anwendung für eine Antwort benötigt. Verzögerungen bei der Antwortzeit können darauf hindeuten, dass der SSRF-Angriff erfolgreich war. Der Angreifer passt die Payload schrittweise an und überwacht die zeitlichen Verzögerungen, um Informationen über das interne Netzwerk oder interne Ressourcen zu gewinnen.

So schützen Sie sich vor SSRF-Angriffen

Zum Schutz vor SSRF-Angriffen sollten Sie eine Kombination aus präventiven Cybersicherheitsmaßnahmen implementieren, darunter:

• Eingabevalidierung. Validieren und bereinigen Sie Benutzereingaben sorgfältig, insbesondere wenn die Anwendung Anfragen an externe Ressourcen sendet. Implementieren Sie eine Positivliste für URLs, sodass nur vertrauenswürdige Domains oder bestimmte URLs zugelassen werden, auf die die Anwendung zugreifen muss. Stellen Sie sicher, dass nur die erwarteten Protokolle wie http und https zulässig sind, und vermeiden Sie potenziell riskante Protokolle wie file:// oder ftp://, die häufig für SSRF-Angriffe ausgenutzt werden. Überprüfen Sie außerdem, ob die von Benutzern angegebenen URLs den erwarteten Mustern oder Formaten entsprechen, um die Wahrscheinlichkeit der Einschleusung schädlicher URLs zu verringern.
• Positivlisten für Hosts und IP-Adressen. Führen Sie eine Positivliste der zulässigen Hosts und IP-Adressen, mit denen die Anwendung interagieren darf. Dadurch lassen sich Anfragen auf vertrauenswürdige und vorgesehene Ziele beschränken und die Angriffsfläche für SSRF reduzieren.
• Zugriff auf interne Ressourcen beschränken. Implementieren Sie eine Netzwerksegmentierung, um die Offenlegung interner Ressourcen zu begrenzen. Stellen Sie sicher, dass extern erreichbare Server nur minimalen Zugriff auf interne Systeme und Dienste haben. Konfigurieren Sie Web Application Firewalls (WAFs) und Zugriffskontrollen, um ausgehende Verbindungen vom Anwendungsserver einzuschränken. Lassen Sie nur notwendige und vordefinierte Verbindungen zu und blockieren Sie unnötigen ausgehenden Datenverkehr. Setzen Sie einen Reverse-Proxy als Vermittler zwischen der Anwendung und externen Ressourcen ein. Konfigurieren Sie den Proxy so, dass er steuert, auf welche externen Ressourcen die Anwendung zugreifen kann, und schaffen Sie damit eine zusätzliche Kontrollebene.

Wie tragen diese Präventivmaßnahmen dazu bei, SSRF-Angriffe zu verhindern? Betrachten wir dazu ein hypothetisches Szenario.

Ein Online-Content-Management-System ermöglicht es Benutzern, URLs einzugeben, um externe Bilder in ihre Beiträge einzubetten. Das System verarbeitet die von Benutzern bereitgestellten URLs ohne angemessene Eingabevalidierung. Ein Angreifer, dem die fehlende Eingabevalidierung bekannt ist, versucht, das System auszunutzen, indem er eine schädliche URL angibt, die auf eine interne Ressource wie einen internen API-Endpunkt oder einen Datenbankserver verweist. Das Sicherheitsteam der Anwendung verbessert jedoch die Eingabevalidierung des Systems, um strenge Regeln für zulässige URLs durchzusetzen. Das System prüft nun, ob die von Benutzern angegebenen URLs den erwarteten Mustern entsprechen, und das Team führt eine Positivliste zulässiger Domains für externe Ressourcen ein.

Der Angreifer veröffentlicht den Beitrag mit einer manipulierten URL, die darauf abzielt, die SSRF-Schwachstelle auszunutzen. Die Eingabevalidierung erkennt nun jedoch die schädliche URL. Sie weist die schädliche URL während der Verarbeitung zurück und verhindert so, dass die Anwendung eine Anfrage an die vom Angreifer angegebene interne Ressource sendet. Der SSRF-Angriff wird durch die verbesserte Eingabevalidierung vereitelt: Das System lässt keine unbefugten Anfragen an interne Ressourcen zu, sodass die Integrität und Sicherheit der internen Systeme gewahrt bleiben.

Durch die Implementierung einer Eingabevalidierung kann die Anwendung schädliche Eingaben ablehnen oder bereinigen, um unbefugte Anfragen zu verhindern und das Risiko von SSRF-Angriffen zu verringern.

Wie F5 helfen kann

SSRF-Angriffe sind gefährlich, da sie es Angreifern ermöglichen, herkömmliche Netzwerksicherheitsmaßnahmen wie Firewalls und Zugriffskontrollen zu umgehen und auf vertrauliche Informationen und Ressourcen zuzugreifen, die normalerweise innerhalb des internen Netzwerks eines Unternehmens geschützt und nicht für den direkten Zugriff über das Internet vorgesehen sind. Da SSRF-Angriffe erhebliche Risiken für die Vertraulichkeit, Integrität und Verfügbarkeit von Daten und Systemen darstellen, müssen Unternehmen robuste Sicherheitsmaßnahmen und bewährte Verfahren implementieren. Dazu gehören WAFs, eine ordnungsgemäße Eingabevalidierung, Zugriffskontrollen und Netzwerksegmentierung, um die von SSRF-Schwachstellen ausgehende Bedrohung zu mindern und sich vor einer möglichen Ausnutzung zu schützen.

F5 WAF-Lösungen blockieren und mindern ein breites Spektrum an Risiken aus den OWASP Top 10, einschließlich SSRF. F5 WAF-Lösungen kombinieren signaturbasierte und verhaltensbasierte Schutzmechanismen, darunter Bedrohungsinformationen von F5 Labs und automatisierte Sicherheit durch maschinelles Lernen (ML), um mit neuen Bedrohungen Schritt zu halten. Sie reduzieren den Aufwand und die Komplexität einer durchgängigen Absicherung von Anwendungen in Cloud-, On-Premises- und Edge-Umgebungen und sind mit verschiedenen Bereitstellungsoptionen verfügbar. BIG-IP Advanced WAF ist eine robuste Lösung, die Ihre Anwendungen vor SSRF-Angriffen schützen und als wichtige Übergangslösung bei Softwareschwachstellen dienen kann, während F5 Distributed Cloud WAF Anwendungen überall absichert und den Betriebsaufwand durch eine benutzerfreundliche As-a-Service-Sicherheitsplattform erheblich vereinfacht.

F5-Lösungen für Web Application and API Protection (WAAP) schützen die gesamte Angriffsfläche moderner Anwendungen durch umfassende Schutzmaßnahmen, darunter WAF, API-Sicherheit, DDoS-Abwehr auf den Ebenen 3 bis 7 sowie Bot-Schutz vor bösartiger Automatisierung und automatisierten Bedrohungen. Die verteilte Plattform erleichtert die Bereitstellung einheitlicher Richtlinien und die Skalierung der Sicherheit über Ihre gesamte Anwendungs- und API-Landschaft hinweg – unabhängig davon, wo diese gehostet wird – sowie die Integration der Sicherheit in den API-Lebenszyklus und umfassendere Ökosysteme.