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 die 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, dass die Aufgabe des Entwicklers einer Anwendung darin besteht, alle Aktivitäten, wie z. B. falsche Passwortversuche von Benutzern, mit ihren IP-Adressen aufzuzeichnen. Zunächst ermittelt der Entwickler die IP-Adresse des Benutzers, wenn die HTTP-Anforderung mit der erfüllt wird Möglichkeit, die die von ihm verwendete Programmiersprache bietet, und wird versuchen, diese Daten weiterhin in der zu verwenden Anwendung.
Da seine IP-Adresse während des gesamten Entwicklungsprozesses festgelegt wird, wird ihm während der Tests immer dieselbe Adresse angezeigt, da Benutzercomputer im Allgemeinen verwendet werden Unternehmensnetzwerke arbeiten mit statischer IP über MAC-Adresse. 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 an die Anwendung übermittelte HTTP-Anforderung in Rohform sehen, da alle dieselbe IP-Adresse haben. Dies führt zur Arbeit mit X-Forwarded-For.
Header-Informationen namens X-Forwarded-For 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:
FunktiongetIPAdresse() {
$ipKeys = Reihe(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
für jede ($ipKeys als $taste) {
Wenn (array_key_exists($key, $_SERVER) WAHR) {
für jede (explodieren(',', $_SERVER[$taste]) als $ip) {
$ip = trim($ip);
Wenn (validate_ip($ip)) {
zurückkehren $ip;
}
}
}
}
zurückkehrenisset($_SERVER['REMOTE_ADDR'])? $_SERVER['REMOTE_ADDR']: FALSCH;
}
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 richtig und sicher funktioniert, müssen Teams theoretisch zusammenarbeiten, aber in Realität, an extremen Punkten voneinander – versuchen Sie, mit Sicherheitslücken umzugehen, die a haben gemeinsame Basis. 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. Durchführung einer Prüfung gem 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:
wenn HTTP_REQUEST {
HTTP:: Header entfernen X-Forwarded-Für
HTTP:: Header einfügen X-Forwarded-Für [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 übernehmen und implementieren. Ihr Ausgangspunkt sollte sein, die Arbeitslogik dieser Frameworks zu erforschen und zu lernen.
