Wie riskieren Load Balancer und echte IP-Beziehungen Ihre Sicherheit?

Einer der Vorteile eines Sicherheitsspezialisten ist die Arbeit mit zahlreichen Teams. Nach einem Audit haben Sicherheitsspezialisten die Möglichkeit, mit Datenbankadministratoren und Analysten zusammenzuarbeiten. Damit eine Anwendung ordnungsgemäß und sicher funktioniert, versuchen diese Teams, Sicherheitslücken zu beheben, die eine gemeinsame Grundlage haben. Dialoge zwischen diesen Teams werfen einige Probleme mit echtem geistigem Eigentum auf.

Proxy- und echte IP-Konzepte

Heutige Webanwendungen laufen auf mehreren App-Servern und Datenbanksystemen. Stellen Sie sich zwei Anwendungsserver vor, die denselben Quellcode teilen. Anfragen des Benutzers können je nach Lastsituation von einem dieser Server erfüllt werden. Der Load-Balancing-Mechanismus, der HTTP-Anfragen vor den Anwendungsservern verarbeitet, entscheidet, welche Anfrage an welchen Anwendungsserver weitergeleitet wird. Dies wirft eine große Frage für Middleware-Systemadministratoren und Softwareentwickler auf: Wie lautet die echte IP-Adresse des Benutzers?

Proxys sind für die Übertragung von Daten zwischen zwei Systemen zuständig. Der Load Balancer ist der für den Proxy zuständige Mechanismus. Mit anderen Worten, nur ein System kommuniziert sowohl mit dem Benutzer als auch mit dem Anwendungsserver. In Bezug auf den Netzwerkverkehr kommunizieren Web A- oder Web B-Server immer mit der IP-Adresse des Load Balancers. Dasselbe gilt für Benutzer. Für Sicherheitsexperten verursachen Load Balancer ernsthafte Probleme bei zeitbasierten SQL-Injection-Angriffen. Aber das Hauptaugenmerk liegt hier auf IP-Spoofing.

X-Forwarded-For und IP-Beziehung

Betrachten Sie die Beziehung zwischen X-Forwarded-For, Entwickler und Middleware. Nehmen wir zum Beispiel an, die Aufgabe des Entwicklers einer Anwendung besteht darin, alle Aktivitäten, wie beispielsweise falsche Passwortversuche von Benutzern, mit ihren IP-Adressen aufzuzeichnen. Zunächst wird der Entwickler die IP-Adresse des Nutzers ermitteln, wenn die HTTP-Anfrage die von ihm verwendete Programmiersprache bietet, und versuchen, diese Daten in der Anwendung weiter zu verwenden.

Da seine IP-Adresse während des gesamten Entwicklungsprozesses festgelegt wird, sieht er während der Tests immer dieselbe Adresse, da Benutzercomputer in Unternehmensnetzwerken in der Regel mit statischer IP-über-MAC-Adresse arbeiten. Das Gerät führt einige Abnahmetests durch; jedoch wird es Probleme mit diesen geben. Das Testgerät leitet dieses Problem an den Softwareentwickler weiter.

In diesem Stadium kann der Entwickler einen Controller in der Entwicklungsumgebung schreiben und die HTTP-Anfrage in Rohform an die Anwendung übertragen sehen, da alle die gleiche IP-Adresse haben. Dies führt zur Arbeit mit X-Forwarded-For.

Header-Informationen namens X-Forwarded-For werden an den Anwendungsserver gesendet. In diesem Stadium sieht der Softwareentwickler seine IP-Adresse, die er mit ipconfig kontrolliert, nicht den Load Balancer, den er in den Protokollen sieht. Viele Programmierer denken, dass sie dieses Problem mit einem Codeblock wie diesem lösen können:

function getIPaddress() {
    $ipKeys = array(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
    foreach ($ipKeys as $key) {
        if (array_key_exists($key, $_SERVER) === true) {
            foreach (explode(',', $_SERVER[$key]) as $ip) {
                $ip = trim($ip);
                if (validate_ip($ip)) {
                    return $ip;
                }
            }
        }
    }
    return isset($_SERVER['REMOTE_ADDR'])? $_SERVER['REMOTE_ADDR']: false;
}


Dies wird nicht ausreichen – der Entwickler muss prüfen, ob der eingehende Wert eine gültige IP-Adresse ist.

Alles darüber gehörte zu dem Teil, der vom Entwickler gehandhabt wurde. Aber damit eine Anwendung ordnungsgemäß und sicher funktioniert, versuchen Teams, die theoretisch zusammenarbeiten, aber in Wirklichkeit an Extrempunkten voneinander liegen, Sicherheitslücken zu beheben, die eine gemeinsame Grundlage haben. Versuchen Sie nun, das Problem aus der Perspektive des Verantwortlichen für die Konfiguration des Load Balancers zu betrachten.

Systemadministratoren könnten denken, dass Entwickler Informationen wie X-Forwarded-For aufzeichnen, weil den Daten in der HTTP-Anforderung nicht vertraut werden kann. Diese Administratoren übertragen oft X-Forwarded-For; sie übertragen jedoch auch die TCP-Quelladresse des Systems, das die Anfrage gesendet hat, als zweiten Header-Wert. Die True-Client-IP-Struktur ist dafür ein gutes Beispiel.

Wenn Sie all diese Dinge zusammenfassen, verfolgen zwei verschiedene Einheiten unterschiedliche Wege für dasselbe Problem, das als Client-IP-Spoofing bekannt ist. Das Ergebnis ist ein kritisches Problem, bei dem keine IP-Protokollierung und IP-basierte Autorisierung funktionieren.

Wie wird Client-IP-Spoofing in Penetrationstests erkannt?

Die meisten Penetrationstester verwenden Firefox für ihre Sicherheitsüberprüfungen. Sie konfigurieren Firefox mit einem einfachen Add-on, X-Forwarded-For: 127.0.0.1 für alle HTTP-Anfragen. Damit steigt die Wahrscheinlichkeit, solche Schwachstellen bei allen Penetrationstests zu entdecken. Die Durchführung eines Audits gemäß der OWASP-Checkliste stellt sicher, dass Sie nach solchen Schwachstellen suchen. Um die X-Forwarded-For-Schwachstelle zu erkennen, benötigen Sie jedoch ein Modul in der Anwendung, das Ihre IP-Adresse oder die durchgeführten Aktionen anzeigt.

So beheben Sie die X-Forwarded-For-Schwachstelle

Organisationen benötigen ein obligatorisches Dokument für die sichere Anwendungsentwicklung für alle Softwareteams und Outsourcing-Unternehmen. Wenn Sie beispielsweise eine Benutzer-IP-Adresse benötigen, sollte das Unternehmen im Voraus planen und eine Regel für die hier verwendeten Header-Informationen festlegen. Andernfalls werden verschiedene Teams unterschiedliche Lösungen hervorbringen. Wenn eine solche Situation nicht bewältigt werden kann, kommen Outsourcing-Anwendungen ins Spiel, was die Messung von Quellcodes erschwert. In der Regel wollen Unternehmen einen solchen Weg nicht gehen.

Aber um dieses Problem zu lösen, können Sie die folgende F5-Regel verwenden:

when HTTP_REQUEST {
  HTTP::header remove X-Forwarded-For
  HTTP::header insert X-Forwarded-For [IP::remote_addr]
}


Dadurch wird das X-Forwarded-For-Feld in der HTTP-Anforderung von der Außenwelt entfernt. Dann übermittelt es die Anfrage, indem es die IP-Adresse des Systems hinzufügt, das die Anfrage an es gesendet hat. So entsteht eine verlässliche Liste für Software, die nach X-Forwarded-For handelt.

Zusammenfassend besteht das größte Ziel hier darin, einige Überprüfungen von HTTP-Anforderungen durchzuführen und eine zuverlässige Umgebung zu schaffen. Der obige Codeblock ist ein gutes Beispiel, das Sie dafür verwenden können.

Cybersecurity Frameworks und Dokumentation für Unternehmen

Die Einheiten, die scheinbar unabhängig voneinander sind, sind tatsächlich Teile eines Ganzen. Deshalb muss alles systematisch funktionieren. Zwischen den einzelnen Einheiten müssen die zuvor festgelegten Regeln angewendet werden. Wenn ein solches funktionierendes System nicht angenommen wird, können viele Probleme wie die X-Forwarded-For-Schwachstelle auftreten. Dazu sollte vorher alles bedacht und eine möglichst umfassende Dokumentation genutzt werden.

Und jede Einheit in diesem großen System muss Cybersicherheits-Frameworks annehmen und implementieren. Ihr Ausgangspunkt sollte sein, die Arbeitslogik dieser Frameworks zu erforschen und zu lernen.