Was ist SSRF?

Bei einem SSRF-Angriff manipuliert der Angreifer normalerweise Eingaben, die zum Angeben der Ziel-URL für eine serverseitige HTTP-Anforderung verwendet werden. Dies kann passieren, wenn eine Anwendung die von einem Benutzer eingegebene URL nicht validiert oder bereinigt, bevor sie Daten von einer Remoteressource abruft. Der Angreifer kann den Zielserver dazu bringen, Anfragen an beliebige Ziele auszuführen, was möglicherweise zu verschiedenen Sicherheitsrisiken führt. 

Solche Angriffe können auch erfolgen, wenn die angegriffene Ressource Vertrauensbeziehungen zu anderen Systemen unterhält, etwa zu einem Cloud-Metadatendienst oder Back-End-APIs. Dadurch könnte ein Angreifer Anfragen an diese vertrauenswürdigen Dienste stellen und vertrauliche Informationen extrahieren oder nicht autorisierte Aktionen ausführen.

Da moderne Webanwendungen Endbenutzern praktische Funktionen bieten, ist das Abrufen einer URL zu einem gängigen Szenario geworden. Infolgedessen nimmt die Häufigkeit von SSRF zu. Darüber hinaus nimmt die Schwere von SSRF zu, da APIs und Cloud-Dienste immer weiter verbreitet sind und Computerarchitekturen dezentraler und komplexer werden.

SSRF zählt zu den Top 10 der Anwendungssicherheitsrisiken von OWASP , einer weithin anerkannten Zusammenstellung der kritischsten Sicherheitsrisiken für Web-Anwendungen. SSRF zählt außerdem zu den zehn größten Sicherheitsrisiken von OWASP , die sowohl bei Apps als auch bei APIs auftreten , und muss bei der Implementierung von Sicherheitslösungen besonders berücksichtigt werden. 

So funktioniert ein SSRF-Angriff:

• Die Anwendung ermöglicht Benutzereingaben, um die Ziel-URL oder Ressource für eine serverseitige Anforderung zu bestimmen. Diese Eingabe kann von Parametern in einer URL, Benutzereingaben aus Formularfeldern oder anderen Datenquellen stammen.
• Der Angreifer übermittelt eine speziell gestaltete Anfrage und manipuliert die Eingabe so, dass sie auf eine Ressource verweist, auf die der Angreifer zugreifen oder die er ausnutzen möchte. Diese Ressource kann ein interner Server, ein Backend-Dienst, eine API oder andere interne Systeme sein, die sich hinter Firewalls befinden und vom externen Netzwerk nicht zugänglich sind.
• Der Server verarbeitet die böswilligen Eingaben des Benutzers und erstellt eine Anfrage an die angegebene URL. Diese Anforderung wird aus der Perspektive des Servers und nicht des Browsers des Benutzers gestellt und ist daher eine serverseitige Anforderung.
• Befindet sich der angegriffene Server in einem internen Netzwerk, versuchen Sie, auf vertrauliche Informationen aus internen Ressourcen zuzugreifen und diese an eine vom Angreifer kontrollierte externe Stelle zu übertragen. Nutzen Sie SSRF auch, um Ports auf internen Systemen zu scannen und so potenzielle Schwachstellen und Sicherheitslücken zu erkennen.
• SSRF-Angriffe sind insbesondere in Cloud-Umgebungen besorgniserregend, in denen Instanzen möglicherweise Zugriff auf vertrauliche Metadatendienste haben.
• Die Folgen eines SSRF-Angriffs können schwerwiegend sein und vom unbefugten Zugriff auf vertrauliche Daten und Dienste über die Ausnutzung interner Systeme bis hin zur Gefährdung ganzer Cloud-Umgebungen reichen.

So kann sich ein SSRF-Angriff im wirklichen Leben auswirken.

Stellen Sie sich eine ungesicherte Webanwendung vor, die Nutzern ermöglicht, Bilder zur Verarbeitung hochzuladen und ihnen die Möglichkeit gibt, eine URL zu einem Bild anzugeben, das sie verarbeiten wollen. Anstatt jedoch eine legitime Bild-URL einzureichen, übermittelt der Angreifer eine präparierte Eingabe mit einer bösartigen URL, die auf eine interne Ressource des Anwendungsservers verweist, etwa eine interne Datei oder eine Backend-Datenbank. Der Anwendungsserver verarbeitet die bösartige URL unangefochten und ruft gemäß der Eingabe des Angreifers die interne Ressource ab, um vertrauliche Daten zu ziehen oder eine Datenbank abzufragen und die Daten an den Angreifer zurückzugeben.

Ist der Server erst einmal kompromittiert, kann der Angreifer auch Anfragen 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 Berechtigungen des angegriffenen Servers variieren. Angriffe können zu unbefugtem Datenzugriff, Dienstunterbrechung oder Beeinträchtigung interner Systeme führen.

SSRF-Angriffe können in verschiedene Typen eingeteilt werden, basierend darauf, wie der Angreifer mit dem Server interagiert und Informationen extrahiert.

Bei einem typischen SSRF-Angriff injizieren Sie als Angreifer eine bösartige URL in die Benutzereingabe, woraufhin der Server eine Anfrage an die vorgegebene Ressource sendet. Sie können die Serverantwort direkt auswerten und so Informationen über das interne Netzwerk sammeln, etwa wie Sie Daten abrufen oder zugängliche Dienste erkennen.

Bei blinden SSRF-Angriffen erhält der Angreifer die Antwort nicht direkt vom Server. Stattdessen bestätigt der Angreifer den Erfolg oder Misserfolg des SSRF-Angriffs indirekt, indem er Änderungen im Verhalten der Anwendung beobachtet.

Der Angreifer übermittelt eine manipulierte Eingabe und zwingt den Server, eine Anfrage an eine externe oder interne Ressource zu stellen. Der Angreifer sucht nach erkennbaren Änderungen in der Aktivität der Anwendung, wie etwa Unterschieden bei Fehlermeldungen, Reaktionszeiten oder anderen Nebenwirkungen. Mithilfe dieser Informationen kann der Angreifer feststellen, ob das 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 übermittelt der Angreifer eine böswillige Eingabe, die den Server dazu veranlasst, eine Anfrage an eine externe oder interne Ressource zu stellen. Der Angreifer beobachtet die Zeit, die die Anwendung zum Reagieren benötigt. Verzögerungen in der Antwortzeit können darauf hinweisen, dass das 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 extrahieren.

Zum Schutz vor SSRF-Angriffen implementieren Sie eine Kombination aus vorbeugenden Cybersicherheitsmaßnahmen , darunter: 

• Eingabevalidierung. Überprüfen und bereinigen Sie die vom Benutzer bereitgestellten Eingaben sorgfältig, insbesondere wenn die Anwendung Anforderungen an externe Ressourcen stellt. Implementieren Sie eine URL-Whitelist, indem Sie nur vertrauenswürdige Domänen oder bestimmte URLs zulassen, auf die die Anwendung zugreifen muss. Stellen Sie sicher, dass nur die erwarteten Protokolle wie http und https zugelassen sind, und vermeiden Sie die Zulassung potenziell riskanter Protokolle wie file:// oder ftp://, die häufig bei SSRF-Angriffen ausgenutzt werden. Überprüfen Sie außerdem, ob die von den Benutzern bereitgestellten URLs den erwarteten Mustern oder Formaten entsprechen. So verringern Sie die Wahrscheinlichkeit der Einschleusung bösartiger URLs.
• Whitelists für Hosts und IP-Adressen. Pflegen Sie eine Whitelist mit zulässigen Hosts und IP-Adressen, mit denen die Anwendung interagieren darf. Dies kann dazu beitragen, Anfragen auf vertrauenswürdige und vorgesehene 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 Gefährdung interner Ressourcen zu begrenzen. Stellen Sie sicher, dass nach außen gerichtete 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 Reverseproxy ein, der als Vermittler zwischen der Anwendung und externen Ressourcen fungiert. Konfigurieren Sie den Proxy, um zu steuern, auf welche externen Ressourcen die Anwendung zugreifen kann, und fügen Sie so eine zusätzliche Kontrollebene hinzu.

Wie helfen diese Präventivmaßnahmen, SSRF-Angriffe zu verhindern? Schauen wir uns ein hypothetisches Szenario an.

Ein Online-Content-Management-System ermöglicht es Benutzern, URLs einzugeben, um externe Bilder in ihre Beiträge einzubetten. Dieses System verarbeitet vom Benutzer bereitgestellte URLs ohne ordnungsgemäße Eingabevalidierung. Ein Angreifer, der sich der fehlenden Eingabeüberprüfung bewusst ist, versucht, das System auszunutzen, indem er eine bösartige URL angibt, die auf eine interne Ressource, beispielsweise einen internen API-Endpunkt oder einen Datenbankserver, verweist. Das Sicherheitsteam der Anwendung verbessert jedoch die Eingabevalidierung des Systems, um strenge Regeln für akzeptierte URLs durchzusetzen. Das System beginnt mit der Überprüfung, ob die von den Nutzern angegebenen URLs den erwarteten Mustern entsprechen, und das Team implementiert eine Whitelist zulässiger Domänen für externe Ressourcen. 

Der Angreifer sendet den Beitrag mit einer speziell gestalteten URL, um die SSRF-Schwachstelle auszunutzen. Doch die Eingabevalidierung erkennt die böswillige URL sofort. Die Eingabevalidierung lehnt die böswillige URL während der Verarbeitung ab und verhindert so, dass die Anwendung eine Anfrage an die vom Angreifer angegebene interne Ressource stellt. Die erweiterte Eingabevalidierung stoppt den SSRF-Angriff effektiv: Das System erlaubt keine unbefugten Anfragen an interne Ressourcen und schützt damit die Integrität und Sicherheit der internen Systeme.

Durch die Implementierung einer Eingabevalidierung kann die Anwendung bösartige Eingaben ablehnen oder bereinigen, wodurch nicht autorisierte Anfragen verhindert und das Risiko von SSRF-Angriffen verringert wird.

SSRF-Angriffe sind gefährlich, da Angreifer damit herkömmliche Netzwerksicherheitsmaßnahmen wie Firewalls und Zugriffskontrollen umgehen und so auf vertrauliche Informationen und Ressourcen zugreifen können, die normalerweise im internen Netzwerk einer Organisation geschützt sind 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 Methoden implementieren, darunter WAFs, ordnungsgemäße Eingabevalidierung, Zugriffskontrollen und Netzwerksegmentierung, um die Bedrohung durch SSRF-Schwachstellen zu verringern und sich vor einer potenziellen 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 Signatur- und Verhaltensschutz, einschließlich Bedrohungsinformationen von F5 Labs und automatisierte Sicherheit durch maschinelles Lernen (ML), um mit neuen Bedrohungen Schritt zu halten. Sie verringern den Aufwand und die Komplexität der konsistenten Sicherung von Anwendungen in Clouds, lokalen Umgebungen und Edge-Umgebungen und sind in verschiedenen Bereitstellungsoptionen verfügbar. BIG-IP Advanced WAF ist eine robuste Lösung, die Ihre Anwendungen vor SSRF-Angriffen schützt und eine wichtige Notlösung für Software-Schwachstellen bietet, während F5 Distributed Cloud WAF Apps überall mit drastisch vereinfachten Vorgängen über eine benutzerfreundliche Sicherheitsplattform als Service schützt.  

Die WAAP-Lösungen (Web Application and API Protection) von F5 schützen die gesamte Angriffsfläche moderner Apps mit umfassenden Schutzmechanismen, die WAF, API-Sicherheit , L3-L7-DDoS-Minderung und Bot-Abwehr gegen bösartige Automatisierung und automatisierte Bedrohungen umfassen. Mithilfe der verteilten Plattform können Sie ganz einfach einheitliche Richtlinien implementieren und die Sicherheit für Ihren gesamten App- und API-Bestand skalieren, unabhängig davon, wo diese gehostet werden. Zudem können Sie die Sicherheit in den API-Lebenszyklus und umfassendere Ökosysteme integrieren.