Serverseitige Anforderungsfälschung

Sicherheitslücken durch serverseitige Anforderungsfälschung treten auf, wenn ein Benutzer eine Anwendung veranlassen kann, HTTP-Anfragen an eine vom Angreifer bestimmte Domain zu stellen. Wenn eine Anwendung Zugriff auf private/interne Netzwerke hat, kann ein Angreifer die Anwendung auch veranlassen, Anfragen an interne Server zu stellen.

Wir werden uns das anhand einiger Beispiele genauer ansehen, um besser zu verstehen, wie es in Aktion aussieht.

Stellen Sie sich eine API vor, die eine URL von einem Benutzer entgegennimmt und ein Bild der vom Benutzer bereitgestellten URL generiert, z. B. für eine Vorschau oder den Export einer Seite.

ts
lass url = request.params.url;

lass response = http.get (url);
let render = response.render ();

render.export () zurückgeben;

Da der URL-Parameter vom Benutzer gesteuert wird, kann ein Angreifer einfach auf eine beliebige URL zugreifen. In einigen Fällen kann es sich je nach der Bibliothek, die für den Zugriff auf die URL verwendet wird, sogar um lokale Dateien handeln, die das Schema „file://“ verwenden.

Eine übliche Methode, eine SSRF-Sicherheitslücke zu missbrauchen, wenn sie auf AWS gehostet wird, besteht darin, sie für den Zugriff auf die AWS-Metadaten-API zu verwenden, die Anmeldeinformationen für die AWS-API enthalten kann. Dies kann zu weiterem Zugriff auf andere AWS-Ressourcen innerhalb des Kontos führen, was, wie Sie sich vorstellen können, nicht ideal ist.

Schadensbegrenzung

Die Behebung von SSRF-Schwachstellen kann manchmal sehr schwierig sein und hängt stark davon ab, was der fragliche Code zu erreichen versucht. Abhängig von den Anforderungen gibt es verschiedene Schutzmaßnahmen, die ergriffen werden können.

Vermeiden Sie benutzerbestimmte URLs

In einigen Fällen können Sie eine Funktion möglicherweise auf eine Weise implementieren, die nicht darauf angewiesen ist, dass ein Benutzer eine beliebige URL angibt. Wenn das überhaupt möglich ist, ist es der wirksamste Weg, das SSRF-Risiko zu mindern.

Kapazitäten minimieren

Wenn Sie eine PDF-Exportfunktion implementieren, neigen Sie möglicherweise dazu, einfach einen Headless-Browser zu verwenden und einen Screenshot der Seite zu machen. Angesichts der Komplexität von Browsern und der schieren Anzahl von Funktionen und Angriffsflächen, die Browser bieten, ist dies nicht immer ratsam.

Es ist wichtig, das richtige Werkzeug für die jeweilige Aufgabe zu verwenden. In einigen Fällen reicht ein einfacher HTTP-Client aus. Es gibt immer Dinge, die getan werden können, um die Fähigkeiten und damit die verfügbaren Angriffsflächen und Vektoren zu minimieren. Zum Beispiel im Fall eines HTTP-Clients:

• Deaktiviere die folgenden Weiterleitungen
• Deaktiviere alle Schemata außer HTTPS

Es gibt einige Fallstricke

Weiterleitungen und Iframes

Eine übliche Methode, private Ressourcen (IP-Adressen oder interne Hostnamen) vor SSRF zu schützen, besteht darin, die von einem Benutzer angegebene URL zu analysieren und eine „Deny-List“ zu verwenden, um den Zugriff auf vertrauliche Ressourcen zu verhindern.

Es ist erwähnenswert, dass diese Methode in den meisten Fällen nicht effektiv ist, da sie in Szenarien umgangen werden kann, in denen der Client HTTP-Weiterleitungen, HTML/JavaScript-Weiterleitungen folgt oder komplexe Elemente wie Iframes rendern kann.

Ein Angreifer kann einer anfälligen Anwendung, die eine Seite hostet, die zu einer vertraulichen Ressource umleitet, eine URL bereitstellen, entweder über eine HTTP 301/302, eine HTML-Meta-Weiterleitung, indem er die aktuelle URL mit Javascript beim Laden festlegt oder einen Iframe einbettet, der eine interne Ressource anzeigt. Dadurch wird jeder Versuch, die ursprüngliche URL zu validieren, effektiv umgangen.

DNS-Neubindung
Eine andere „Art“ der Weiterleitung kann auch über DNS erfolgen. Eine übliche Methode, SSRF-Angriffe zu verhindern, besteht darin, Folgendes zu tun:

1. Analysieren Sie die angegebene URL
2. Nimm den Hostnamen und führe eine DNS-Suche durch
3. Lehnen Sie die URL ab, wenn sie in eine interne/private IP aufgelöst wird, oder akzeptieren Sie die URL, wenn es sich um eine öffentliche IP handelt

Diese Methode ist nicht wirklich effektiv, da sie anfällig für „DNS-Rebinding“ ist. Das DNS-Rebinding funktioniert aufgrund des Standardverhaltens der meisten Netzwerk-Stacks (z. B. von Linux und Windows), wenn eine TCP-Verbindung von einem Remote-Host geschlossen wird.
Wenn ein Remote-Host eine Verbindung gewaltsam schließt, versucht er, die Verbindung wiederherzustellen, nachdem er eine weitere DNS-Abfrage durchgeführt hat, um die IP-Adresse erneut aufzulösen.

Auf diese Weise kann ein Angreifer Folgendes tun:

1. Erstellen Sie einen DNS-Eintrag für `rebinding.attacker.com` mit einer öffentlichen IP-Adresse mit einem offenen HTTP-Port mit einer sehr kurzen TTL (Time-to-Live)
2. Senden Sie die URL (Beispiel: https://rebinding.attacker.com/) an die anfällige Anwendung. Es überprüft, ob die aufgelöste IP nicht privat ist, was nicht der Fall ist, und fährt dann mit der angeforderten Operation fort, da sie davon ausgeht, dass sie sicher ist
3. Sobald die HTTP-Verbindung hergestellt ist, wird der DNS-Eintrag für „rebinding.attacker.com“ in eine interne IP-Adresse geändert
4. Die HTTP-Verbindung wird gewaltsam geschlossen
5. Dies führt nun dazu, dass die Anwendung die IP-Adresse von „rebinding.attacker.com“ erneut auflöst, die jetzt auf eine interne IP-Adresse verweist
6. Da der IP-Auflösungsschutz bereits erfolgt ist und die Neuauflösung des DNS-Eintrags und die Neuverbindung alles im Kernel erfolgt, ist sich der Anwendung nicht bewusst, dass sich die IP jetzt geändert hat

Dadurch wird der Schutz vor der Bereitstellung von URLs, die in private IP-Adressen aufgelöst werden, effektiv umgangen.

IPv4 gegen IPv6

Eine weitere gängige Methode, jede „Ablehnungsliste“ zu umgehen, ist die Verwendung von IPv6. Da alle IPv4-Adressen in Form einer IPv6-Adresse ausgedrückt werden können, ist es oft möglich, Ablehnungslisten zu umgehen, indem eine IPv6-Adresse verwendet wird, die auch einer IPv4-Adresse zugeordnet ist, auf die man zugreifen möchte.