EN

Server-Side Request Forgery (SSRF) Sicherheitslücke

In diesem Artikel:

Unter Ausnutzung einer Schwachstelle in der serverseitigen Anfragenfälschung (Server-Side Request Forgery, SSRF) zielen Angreifer auf den Backend-Server einer anfälligen Anwendung ab und bringen ihn dazu, böswillige Anfragen für die Ausführung unbeabsichtigter Aktionen auszuführen.

Durch SSRF-Angriffe können Hacker andere Systeme infiltrieren, die mit dem Webserver verbunden sind, oder auf interne Ressourcen zugreifen, die sie von außerhalb des Netzwerks nicht erreichen können. Angesichts der sich verändernden Bedrohungslandschaft wird SSRF auf Platz 10 (A10) der OWASP Top Ten Schwachstellen 2021 aufgeführt und gilt weiterhin als großes Sicherheitsrisiko für Unternehmen, die Anwendungen besitzen.

In diesem Artikel werden die Bedeutung von Server-seitigen Request Forgery-Angriffen, die gängigen Methoden, mit denen Hacker SSRF-Schwachstellen ausnutzen, und die Techniken zu ihrer Verhinderung erläutert.

Wie SSRF-Angriffe verhindert werden können und welche Bedeutung sie für die Sicherheit haben

Inter-Server-Anfragen sind für Webanwendungen unerlässlich, um auf Remote-Ressourcen anderer Anwendungen zuzugreifen, indem Metadaten der Ressourcen aus den URLs importiert werden. Wenn die Ziel-URL mit vom Benutzer kontrollierbaren Daten aufgebaut ist, kann ein Angreifer Parameterwerte innerhalb der Anwendung ändern, um bösartige Anfragen vom Backend-Server zu erstellen.

Durch die Kontrolle der serverseitigen Anfragen können Hacker eine Vielzahl von Angriffen auf interne Netzwerke durchführen, wodurch die SSRF-Prävention für Unternehmen zu einem vorrangigen Anliegen wird. Im folgenden Abschnitt wird die SSRF-Prävention und ihre Bedeutung für die Anwendungssicherheit erörtert.

Vorbeugung gegen Server-Side Request Forgery

Einige Standardtechniken zur Verhinderung von Server-seitigen Request Forgery-Angriffen umfassen:

DNS Domain Whitelisting

Ein idealer Ansatz, um das Senden bösartiger Anfragen vom Backend-Server einer Anwendung für nicht autorisierte Aktionen einzuschränken, besteht darin, den Zugriff der Anwendung auf die erforderlichen externen Entitäten zu erlauben, indem eine Domänen-Whitelist erstellt wird. Die Whitelist bietet einen vertrauenswürdigen Ansatz zur Sicherstellung der Kommunikation mit zulässigen DNS-Einträgen und IP-Adressen und gewährleistet, dass die Systemressourcen nur von gültigen Rechnern aus zugänglich sind.

Deaktivieren nicht verwendeter URL-Schemata

Die Anwendung sollte nur das Schema zulassen, das für Anfragen verwendet wird, und alle anderen deaktivieren. Die Deaktivierung nicht verwendeter URL-Schemata ist eine wirksame Präventivmaßnahme gegen SSRF-Angriffe, da dies Angreifer daran hindert, URL-Schemata auszunutzen, um bösartige URLs für den Zugriff auf Backend-Ressourcen zu erstellen.

Zu den häufig ausgenutzten URL-Schemata gehören file://,ftp://,dict:// und gopher://. Eine bewährte Praxis in der Branche ist die Verwendung von https://, da sie dem Netzwerk eine zusätzliche Sicherheits- und Vertrauensebene verleiht, die es Hackern unmöglich macht, auf Ressourcen zuzugreifen, selbst wenn sie Zugriff auf die Webanwendung erhalten haben.

Interne Authentifizierung erzwingen

Die meisten Websysteme verlangen keine Authentifizierung der Benutzer für interne Dienste wie MongoDB, Memcached, ElasticSearch, Redis usw. Wenn keine geeigneten Authentifizierungsmechanismen vorhanden sind, können Angreifer bösartige serverseitige Anfragen erstellen, die auf solche anfälligen Dienste abzielen. Es wird empfohlen, die Authentifizierung für alle Dienste zu erzwingen, einschließlich derjenigen innerhalb des lokalen Netzwerks, um sensible Informationen und Werte zu schützen.

Behandlung von Antworten

Die internen Server einer Anwendung sollten keine unbearbeiteten Antworten, die in der Anfrage enthalten sind, an den Client senden dürfen. Die an den Client gesendeten Antworten sollten mit der erwarteten Antwort abgeglichen werden, um zu verhindern, dass Antwortdaten an den Angreifer weitergegeben werden.

Verwenden Sie eine Web Application Firewall

Mit einer Web Application Firewall können Entwickler Richtlinien für die externen Ressourcen implementieren, mit denen die Anwendung interagieren kann. Dies ermöglicht die Kontrolle aller ausgehenden Verbindungen auf der Grundlage der Anfrage der Anwendung/des Clients und verhindert den unbeabsichtigten Zugriff auf Ressourcen. Auf jedem Host sollte eine Firewall eingerichtet werden, wobei Zugriffskontrolllisten zur Verwaltung der Kommunikation zwischen Servern empfohlen werden.

Warum ist es wichtig, Ihr Unternehmen vor SSRF-Schwachstellen zu schützen?

Die Auswirkungen eines erfolgreichen Server-seitigen Request Forgery-Angriffs reichen von leicht bis verheerend, je nachdem, wie die Zielanwendung Antworten von Remote-Hosts verarbeitet. Daher ist die Implementierung präventiver Techniken für Unternehmen von entscheidender Bedeutung und unterscheidet sich. SSRF-Angriffe betreffen den anfälligen Server und nutzen das Zielsystem als Vermittler, um Anfragen an externe Ressourcen/Netzwerke weiterzuleiten. Der Angriff ermöglicht es Hackern, ihre Reichweite über die Firewall hinaus auf interne Systeme auszudehnen, die normalerweise nicht über das Internet zugänglich sind.

SSRF-Angriffe stellen verschiedene Bedrohungen für die Anwendungssicherheit dar, wie z. B.:

Missbrauch des Vertrauens zwischen Systemen – Angreifer nutzen SSRF, um die Kontrollen zu umgehen, die die Interaktion mit anderen Systemen regeln, die der angreifbaren Anwendung vertrauen. Dies erleichtert Angreifern den Austausch von Daten, Abfragen und bösartigen Befehlen über Ports, die ansonsten für öffentliche Netzwerke gesperrt sind. 

Ermöglicht die Aufzählung von Netzwerken – Angreifer nutzen ungültige Anfragen, um Netzwerkinformationen aus Fehlermeldungen, Dienstbannern und der Seitenladezeit zu extrahieren, um offene Ports und die Verfügbarkeit von Diensten zu prüfen. Durch die Ausführung verschiedener Kombinationen von ungültigen Anfragen können Angreifer das Verhalten des Zielservers interpretieren und die Anwendungsfunktionen ausnutzen.

Offenlegung von Dateien und internen Ressourcen – Angreifer verwenden file://, ftp:// oder gopher:// URL-Schemata, um Ressourcen zuzuordnen oder Dateien aus dem lokalen Dateisystem des Hosts zu lesen.

Beispiele für Server-Side Request Forgery

Es gibt mehrere Ansätze zur Durchführung von SSRF-Exploits. Einige davon sind im Folgenden aufgeführt:

Port-Scanning mit SSRF

Eine offene SSRF-Schwachstelle kann ausgenutzt werden, um Zielanwendungsserver zu scannen und Informationen über offene Ports und Dienste zu sammeln, die im Netzwerk laufen. Zu diesem Zweck erstellen Hacker eine Reihe von Anfragen an verschiedene Ports auf dem Server und analysieren die Antwort, um Informationen über die auf den Ports laufenden Dienste zu sammeln.

Angenommen, eine E-Commerce-Website verwendet die folgende Anfrage, um die Spezifikationen eines bestimmten Produkts abzurufen:

https://darwinmarket.com/products?url=https://productspecs.com/specs?id=24

Angesichts des Anfragemechanismus über die URL kann ein Hacker den URL-Parameter in der Anfrage wie folgt ändern:

https://darwinmarket.com/products?url=192.168.1.10:21

Anhand der Serverantworten können die Angreifer feststellen, ob der Host 192.168.1.10 über einen FTP-Dienst an Port 21 verfügt oder nicht. Sie erweitern das Senden sekundärer Anfragen an den Server, indem sie den Anfrageparameter für die Portnummer ändern, um eine Liste der offenen Ports und der auf dem Server laufenden Dienste zu erhalten.

SSRF auf Localhost

Angenommen, der Server sendet die folgende Anfrage, um Produktdetails zu erhalten:

https://darwinmarket.com/products?url=https://productspecs.com/specs?id=24

Der Angreifer kann die Anfrage manipulieren, um Verzeichnis- und Ordnerinformationen des verwundbaren Servers zu erhalten:

https://darwinmarket.com/products?url=file:///etc/passwd

Wenn der Server diese Anfrage ausführt, wird der Inhalt der Datei /etc/passwd angezeigt, was einen unbeabsichtigten Zugriff auf das Konto ermöglicht.

SSRF für internen Zugriff

Angenommen, die gleiche Anwendung verwendet die folgende Anfrage für Produktspezifikationen:

https://darwinmarket.com/products?url=https://productspecs.com/specs?id=24

Der Angreifer kann eine bösartige Anfrage erstellen, um Zugang zu internen Portalen zu erhalten:

https://darwinmarket.com/products?url=https://productspecs.com/admin

Damit hätte der Hacker Zugriff auf das Verwaltungsportal, das nur innerhalb des Netzwerks eingesehen werden kann. Der Hacker kann seine Privilegien mit administrativem Zugriff erweitern, um den Angriff weiter auszubauen.

Häufig gestellte Fragen

Warum ist Blacklisting kein wirksamer Schutz gegen SSRF-Angriffe?

Die Erstellung blockierter Listen von IP-Adressen und Domänen gilt als unwirksame Verteidigungstechnik, da es verschiedene Umgehungsmöglichkeiten gibt, die Hacker nutzen können, um die Validierungsmaßnahmen der Blacklists zu umgehen. In Anwendungen, die den localhost auf eine Blocklist setzen, indem sie den DNS-Eintrag localhost und IP-Adressen wie 127.0.0.1 blockieren, können Angriffe auf verschiedene Weise durchgeführt werden:

IPv6 Exploits:

http://[::]/

http://[::]:80/

http://0000::1/

http://0000::1:80/

Domain Redirection

http://localtest.me

http://darwin-127-0-0-1.nip.io

Andere Techniken zur Umgehung von Blacklists sind: Änderung der dezimalen IP-Position, missgestaltete URLs, Einbettung von Adressen und Kurzschrift von IP-Adressen.

Was ist der Unterschied zwischen CSRF- und SSRF-Schwachstellen?

Ein CSRF-Angriff zielt auf den Benutzer ab, um bösartige Anfragen im Namen des Angreifers auszuführen. Ein SSRF-Angriff hingegen zielt in erster Linie auf den Backend-Server ab, um interne Ressourcen aus einem externen Netzwerk zu lesen oder zu aktualisieren.

Erhalten Sie jetzt kostenlos einen schnellen Sicherheitsbericht für Ihre Website

Wir analysieren derzeit https://example.com
Wir scannen derzeit https://example.com
Status des Scans: In Bearbeitung
Scan target: http://example.com/laskdlaksd/12lklkasldkasada.a
Datum: 12/08/2022
Crashtest Security Suite prüft auf:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Scanauftrag ausfüllen
Bitte geben Sie Ihre Daten ein, um die schnelle Sicherheitsüberprüfung zu erhalten.
Ein Sicherheitsspezialist analysiert gerade Ihren Scan-Bericht.
Bitte geben Sie Ihre Telefon-/Handynummer an, damit wir Ihre Identität überprüfen können:
Vielen Dank.
Wir haben Ihren Antrag erhalten.
Sobald Ihr Sicherheitsaudit fertig ist, werden wir Sie benachrichtigen.