Comment les équilibreurs de charge et la relation IP réelle mettent-ils votre sécurité en danger ?

L’un des avantages d’être un spécialiste de la sécurité est de travailler avec de nombreuses équipes. Après un audit, les spécialistes de la sécurité auront l’opportunité de travailler avec des administrateurs et des analystes de bases de données. Pour qu’une application fonctionne correctement et en toute sécurité, ces équipes tentent de traiter les vulnérabilités de sécurité qui ont une base commune. Les dialogues entre ces équipes soulèvent certains problèmes avec la vraie propriété intellectuelle.

Concepts de proxy et d’IP réelle

Les applications Web d’aujourd’hui s’exécutent sur plusieurs serveurs d’applications et systèmes de bases de données. Imaginez deux serveurs d’applications partageant le même code source. Les requêtes de l’utilisateur sont prêtes à être satisfaites par l’un ou l’autre de ces serveurs en fonction de la situation de charge. Le mécanisme d’équilibrage de charge, qui gère les requêtes HTTP devant les serveurs d’application, décide quelle requête transmettre à quel serveur d’application. Cela pose une grande question aux administrateurs de systèmes middleware et aux développeurs de logiciels : quelle est la véritable adresse IP de l’utilisateur ?

Les proxys sont chargés de transmettre des données entre deux systèmes. L’équilibreur de charge est le mécanisme en charge du proxy. En d’autres termes, un seul système communique à la fois avec l’utilisateur et le serveur d’application. En termes de trafic réseau, les serveurs Web A ou Web B communiquent toujours avec l’adresse IP de l’équilibreur de charge. Il en va de même pour les utilisateurs. Pour les professionnels de la sécurité, les équilibreurs de charge causent de sérieux problèmes dans les attaques par injection SQL basées sur le temps. Mais l’objectif principal ici est l’usurpation d’adresse IP.

X-Forwarded-For et relation IP

Considérez la relation entre X-Forwarded-For, le développeur et le middleware. Par exemple, supposons que la tâche du développeur d’une application consiste à enregistrer toutes les activités, telles que les tentatives de mot de passe incorrectes par les utilisateurs, avec leurs adresses IP. Dans un premier temps, le développeur déterminera l’adresse IP de l’utilisateur lorsque la requête HTTP sera satisfaite avec l’opportunité offerte par le langage de programmation qu’il utilise et tentera de continuer à utiliser ces données dans l’application.

Étant donné que son adresse IP sera fixe tout au long du processus de développement, il verra toujours la même adresse lors des tests car généralement, les ordinateurs des utilisateurs des réseaux d’entreprise fonctionnent avec une adresse IP statique sur une adresse MAC. L’unité effectuera des tests d’acceptation ; cependant, il y aura des problèmes avec ceux-ci. L’unité de test transmettra ce problème au développeur du logiciel.

A ce stade, le développeur peut écrire un contrôleur dans l’environnement de développement et voir la requête HTTP transmise à l’application sous forme brute, puisque tout le monde a la même adresse IP. Cela se traduira par un travail avec X-Forwarded-For.

Les informations d’en-tête appelées X-Forwarded-For seront envoyées au serveur d’application. À ce stade, le développeur du logiciel verra son adresse IP, qu’il contrôle avec ipconfig, et non l’équilibreur de charge qu’il voit dans les journaux. De nombreux programmeurs pensent qu’ils peuvent résoudre ce problème avec un bloc de code comme celui-ci :

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;
}


Cela ne suffira pas : le développeur doit vérifier si la valeur entrante est une adresse IP valide.

Tout ce qui précède appartenait à la partie gérée par le développeur. Mais pour qu’une application fonctionne correctement et en toute sécurité, les équipes – travaillant ensemble en théorie, mais en réalité, à des points extrêmes les unes des autres – essaient de gérer les vulnérabilités de sécurité qui ont une base commune. Essayez maintenant d’examiner le problème du point de vue de la personne responsable de la configuration de l’équilibreur de charge.

Les administrateurs système peuvent penser que les développeurs enregistrent des informations telles que X-Forwarded-For car les données de la requête HTTP ne sont pas fiables. Ces administrateurs transmettent souvent X-Forwarded-For ; cependant, ils transmettent également l’adresse source TCP du système qui a envoyé la demande en tant que deuxième valeur d’en-tête. La structure True-Client-IP en est un bon exemple.

Lorsque vous mettez toutes ces choses ensemble, deux unités différentes suivent des chemins différents pour le même problème, connu sous le nom d’usurpation d’adresse IP client. Le résultat est un problème critique où aucune journalisation IP et aucune autorisation basée sur IP ne fonctionneront.

Comment l’usurpation d’adresse IP client est-elle détectée dans les tests d’intrusion ?

La plupart des testeurs d’intrusion utilisent Firefox pour leurs contrôles de sécurité. Ils configurent Firefox avec un module complémentaire simple, X-Forwarded-For: 127.0.0.1 pour toutes les requêtes HTTP. Et ainsi, la possibilité de détecter de telles vulnérabilités dans tous les tests d’intrusion augmente. La réalisation d’un audit selon la liste de contrôle OWASP vous permet de vérifier ces vulnérabilités. Cependant, pour détecter la vulnérabilité X-Forwarded-For, vous avez besoin d’un module dans l’application qui affiche votre adresse IP ou les actions entreprises.

Comment résoudre la vulnérabilité X-Forwarded-For

Les organisations ont besoin d’un document de développement d’applications sécurisé obligatoire pour toutes les équipes logicielles et les sociétés d’externalisation. Par exemple, si vous avez besoin d’une adresse IP utilisateur, l’entreprise doit planifier à l’avance et établir une règle sur les informations d’en-tête qu’elle utilisera ici. Sinon, différentes équipes produiront des solutions différentes. Si une telle situation ne peut être traitée, l’externalisation des applications entrera en jeu, rendant difficile la mesure des codes sources. En général, les entreprises ne veulent pas suivre une telle voie.

Mais pour résoudre ce problème, vous pouvez utiliser la règle F5 suivante :

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


Cela supprime le champ X-Forwarded-For dans la requête HTTP du monde extérieur. Ensuite, il transmet la requête en ajoutant l’adresse IP du système qui lui a envoyé la requête. De cette façon, une liste fiable est créée pour les logiciels qui agissent selon X-Forwarded-For.

Pour résumer, le plus grand objectif ici est d’effectuer quelques vérifications sur les requêtes HTTP et de créer un environnement fiable. Le bloc de code ci-dessus est un bon exemple que vous pouvez utiliser pour cela.

Cadres de cybersécurité et documentation pour les entreprises

Les unités qui semblent indépendantes les unes des autres sont en fait des parties d’un tout. C’est pourquoi tout doit fonctionner systématiquement. Les règles déterminées au préalable doivent être appliquées entre chaque unité. Si un tel système de travail n’est pas adopté, de nombreux problèmes tels que la vulnérabilité X-Forwarded-For peuvent survenir. Pour cela, tout doit être réfléchi en amont et une documentation aussi complète que possible doit être utilisée.

Et chaque unité de ce vaste système doit adopter et mettre en œuvre des cadres de cybersécurité. Votre point de départ devrait être de rechercher et d’apprendre la logique de fonctionnement de ces cadres.