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 Zielserver in einem internen Netzwerk, kann der Angreifer versuchen, auf vertrauliche Informationen aus den internen Ressourcen zuzugreifen und diese abzurufen und diese Daten dann an einen vom Angreifer kontrollierten externen Speicherort zu exfiltrieren. SSRF kann auch zum Scannen von Ports auf internen Systemen verwendet werden und hilft dem Angreifer 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 es Benutzern ermöglicht, Bilder zur Verarbeitung hochzuladen, mit einer Funktion, mit der Benutzer eine URL zu einem Bild angeben können, das sie verarbeiten möchten. Anstatt jedoch eine legitime Bild-URL anzugeben, übermittelt der Angreifer eine sorgfältig erstellte Eingabe mit einer bösartigen URL, die auf eine interne Ressource auf dem Anwendungsserver verweist, beispielsweise eine interne Datei oder eine Back-End-Datenbank. Der Anwendungsserver verarbeitet die bösartige URL blind und sendet gemäß der Eingabe des Angreifers eine Anforderung an die durch die URL angegebene interne Ressource, um vertrauliche Daten abzurufen 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 Standard-SSRF-Angriff fügt der Angreifer als Teil der Benutzereingabe eine bösartige URL ein und veranlasst den Server dadurch, eine Anfrage an die angegebene Ressource zu stellen. Der Angreifer kann die Antwort des Servers direkt beobachten und Informationen über das interne Netzwerk sammeln, etwa wie Daten abgerufen oder zugängliche Dienste identifiziert werden.

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 übermittelt den Beitrag mit einer manipulierten URL, die den SSRF-Fehler ausnutzen soll, doch die Eingabeüberprüfung erkennt nun die bösartige URL. Die Eingabevalidierung lehnt die bösartige URL während der Verarbeitung ab und verhindert so, dass die Anwendung eine Anfrage an die vom Angreifer angegebene interne Ressource stellt. Der SSRF-Angriff wird durch die erweiterte Eingabevalidierung vereitelt: Das System lässt keine unbefugten Anfragen an interne Ressourcen zu und die Integrität und Sicherheit interner Systeme bleiben gewahrt.

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.