Qu'est-ce que l'injection LDAP ?
L'injection LDAP est une attaque côté serveur qui exploite les applications web construisant des requêtes Lightweight Directory Access Protocol à partir d'entrées utilisateur non assainies. Lorsque votre application ne neutralise pas correctement les caractères spéciaux avant de les intégrer dans les requêtes LDAP, les attaquants peuvent manipuler ces requêtes pour contourner l'authentification, extraire des données sensibles de l'annuaire ou modifier des entrées dans l'arborescence LDAP.
Les annuaires LDAP sont au cœur de l'infrastructure d'identité des entreprises. Ils stockent les identifiants des utilisateurs, les appartenances aux groupes, les listes de contrôle d'accès, les structures organisationnelles et les détails des comptes de service. Une seule attaque d'injection LDAP réussie peut exposer ce référentiel, donnant à un attaquant les clés de votre infrastructure d'authentification.
MITRE classe cette vulnérabilité comme MITRE CWE-90 : Neutralisation incorrecte des éléments spéciaux utilisés dans une requête LDAP. OWASP la répertorie sous OWASP Injection et la catégorie Injection mise à jour. La vulnérabilité partage sa cause racine avec l'injection SQL, mais cible un système fondamentalement différent et souvent plus critique : le service d'annuaire qui régit qui peut accéder à quoi dans toute votre organisation.
Comprendre le fonctionnement de l'injection LDAP nécessite de connaître la syntaxe des requêtes exploitées par les attaquants.
.jpg)
Comment fonctionne l'injection LDAP ?
Les filtres de recherche LDAP suivent une grammaire spécifique définie dans la syntaxe LDAP. Les filtres utilisent la notation polonaise (notation préfixe), où une requête d'authentification simple ressemble à ceci :
L'opérateur & effectue un ET booléen. Les parenthèses regroupent les conditions. Le caractère générique * correspond à n'importe quelle valeur. Ces métacaractères, ainsi que | (OU), ! (NON), =, ~=, >=, <=, et () comme opérateurs de regroupement, constituent la surface d'injection.
Lorsqu'un développeur construit un filtre en concaténant directement l'entrée utilisateur dans la chaîne de requête, ces métacaractères deviennent des armes. Si un formulaire de connexion insère le nom d'utilisateur directement dans un filtre tel que (&(uid=INPUT)(userPassword=HASH)), un attaquant qui soumet des métacaractères spécialement conçus peut modifier complètement la logique du filtre : contourner l'authentification, retourner toutes les entrées de l'annuaire ou extraire des données caractère par caractère.
La technique spécifique utilisée par un attaquant dépend du type d'injection LDAP.
Types d'injection LDAP
L'injection LDAP prend plusieurs formes distinctes, chacune ciblant un aspect différent de la façon dont les applications interagissent avec l'annuaire. Le type utilisé par un attaquant dépend du comportement de l'application, du contexte de la requête et de ce que l'attaquant peut observer dans la réponse.
| Type | Technique | Conséquence |
| Injection de filtre de recherche | Manipulation de filtre par caractère générique ou OR | Énumération complète de l'annuaire |
| Contournement de l'authentification | Injection de filtre toujours vrai | Connexion non autorisée en tant que n'importe quel utilisateur |
| Injection LDAP aveugle | Analyse différentielle caractère par caractère | Extraction silencieuse de données |
| Manipulation du DN | Mauvais contexte d'échappement appliqué aux champs DN | Injection dans des composants de requête hors filtre |
Injection de filtre de recherche
Considérez ce code Java vulnérable :
Si un attaquant soumet user=*, le filtre résultant devient (cn=*), ce qui correspond à chaque objet de l'annuaire ayant un attribut cn. Votre application retourne l'intégralité de l'annuaire des utilisateurs au lieu d'un seul enregistrement.
Contournement de l'authentification
Les flux d'authentification LDAP représentent la cible d'injection la plus critique. Un filtre de connexion vulnérable comme celui-ci :
Ce filtre peut être contourné en injectant )(uid=))(|(uid=* comme nom d'utilisateur. Le filtre résultant s'évalue toujours à vrai, accordant à l'attaquant le statut authentifié en tant que premier utilisateur de l'arborescence LDAP, souvent un compte administrateur. Le guide de test documente cela comme l'analogue direct des techniques de contournement d'authentification par injection SQL.
Injection LDAP aveugle
Lorsque les applications ne présentent pas directement les résultats des requêtes, les attaquants utilisent des réponses différentielles pour extraire des données. En injectant des conditions de filtre telles que (attribute=a*), (attribute=b*), et en observant si l'application retourne un résultat ou une page vide, ils extraient les valeurs d'attribut caractère par caractère. Des recherches présentées dans le document Black Hat ont démontré que les filtres côté client limitant l'information affichée ne préviennent pas les techniques d'injection aveugle.
Manipulation du Distinguished Name
LDAP possède des contextes d'échappement distincts, et les confondre crée des vecteurs d'injection. Les filtres de recherche nécessitent un échappement selon la RFC 4515 (*→\2a, (→\28, )→\29). Les Distinguished Names (DN) nécessitent un échappement selon la RFC 2253 (\, #, +, <, >, ,, ;, ", =). Appliquer le mauvais contexte d'échappement au mauvais champ laisse votre application vulnérable même si vous pensez avoir corrigé le problème.
Ces types d'attaques partagent des causes racines communes qui vont au-delà de la syntaxe.
Causes de l'injection LDAP
Les vulnérabilités d'injection LDAP proviennent d'une combinaison de pratiques de codage, de limitations des bibliothèques et de mauvaises configurations d'infrastructure. Chaque cause racine crée une voie indépendante vers l'exploitation.
- Concaténation directe de chaînes. La cause immédiate dans presque toutes les vulnérabilités d'injection LDAP est la concaténation de données contrôlées par l'utilisateur directement dans les chaînes de filtre LDAP au niveau de l'application. Les bibliothèques LDAP ont historiquement manqué de support intégré pour les requêtes paramétrées, obligeant les développeurs à suivre des recommandations manuelles pour une construction de requête sécurisée. Des interfaces paramétrées existent mais nécessitent une adoption délibérée.
- Mauvaise gestion des caractères spéciaux. Les applications qui tentent de valider les entrées mettent souvent en œuvre des listes de refus incomplètes qui omettent des caractères dangereux. Une liste de refus bloquant * et ( mais omettant ) ou les octets NUL laisse toujours une faille exploitable. MITRE CWE-90 identifie l'injection LDAP comme résultant de cet échec, c'est-à-dire que la vulnérabilité d'injection découle directement de la mauvaise gestion des caractères spéciaux.
- Confusion de contexte d'échappement. Le LDAP cheat sheet documente que l'application de l'échappement des filtres de recherche aux champs DN, ou de l'échappement DN aux champs de filtre de recherche, crée des vecteurs d'injection par sélection de contexte incorrecte. Si vos développeurs savent qu'ils doivent échapper mais choisissent la mauvaise fonction, votre application reste vulnérable.
- Configurations de bind anonyme et non authentifié. Les serveurs LDAP configurés pour autoriser le bind anonyme permettent aux attaquants de contourner complètement l'authentification bind.
- Utilisation généralisée de LDAP pour l'authentification. Le rôle de LDAP comme colonne vertébrale de l'authentification en entreprise signifie qu'une injection sur les flux de connexion produit la conséquence la plus critique : un accès authentifié aux ressources de l'entreprise. La surface d'attaque est conçue pour être étendue à l'échelle de l'entreprise.
Ces causes se combinent pour créer des risques qui dépassent largement une seule requête compromise.
Impact et risque de l'injection LDAP
Les attaques d'injection LDAP peuvent produire plusieurs catégories d'impact métier, chacune s'aggravant en gravité.
Contournement de l'authentification
Une injection de filtre toujours vrai accorde un accès authentifié immédiat. CVE-2023-4501 dans OpenText Enterprise Server permettait à l'authentification de réussir avec n'importe quel nom d'utilisateur valide, que le mot de passe soit correct ou non, et pouvait aussi réussir avec un nom d'utilisateur invalide et n'importe quel mot de passe. Cela affectait les environnements de développement et d'exécution COBOL d'entreprise déployés dans les services financiers, l'assurance et le gouvernement.
Exfiltration de données sensibles
Les annuaires LDAP contiennent des identifiants utilisateur, des hachages de mots de passe, des adresses e-mail, des hiérarchies organisationnelles, des appartenances à des groupes, des ACL, des comptes informatiques et des identifiants de sécurité. Un avis CISA a documenté une seule requête LDAP récupérant des informations sur les utilisateurs, ordinateurs, groupes, ACL, UO et GPO à partir d'un annuaire d'entreprise.
Élévation de privilèges
Une injection réussie peut accorder des permissions à des requêtes non autorisées et permettre la modification de contenu dans l'arborescence LDAP. CVE-2026-31828 dans Parse Server permettait à des utilisateurs authentifiés à faible privilège de s'élever à n'importe quel groupe restreint via une injection de filtre LDAP.
Déni de service
CVE-2025-12764 (pgAdmin) a démontré l'injection LDAP utilisée pour forcer le serveur DC/LDAP et le client à traiter une quantité inhabituelle de données, provoquant un déni de service sur l'infrastructure d'annuaire avec des échecs d'authentification en cascade.
Facilitation du mouvement latéral
L'énumération LDAP alimente la reconnaissance Active Directory. L'avis de l'équipe rouge CISA a documenté que les données LDAP ont permis la cartographie des utilisateurs, ordinateurs, groupes, ACL, UO et GPO, qui servent tous d'entrées pour la planification du mouvement latéral. L'entreprise évaluée n'avait aucune visibilité sur cette activité.
OWASP évalue l'exploitabilité de l'injection à 3 (Facile) et l'impact technique à 3 (Sévère) dans son cadre OWASP. L'injection LDAP entraîne également des conséquences directes en matière de conformité : PCI DSS 6.5.1 cite explicitement l'injection LDAP aux côtés de l'injection SQL et XPath comme cible d'évaluation obligatoire.
Comprendre l'impact vous aide à prioriser les défenses, mais il est également nécessaire de savoir comment les attaquants identifient et exploitent ces failles.
Comment les attaquants exploitent l'injection LDAP
Les attaquants suivent une méthodologie structurée pour trouver et exploiter les vulnérabilités d'injection LDAP, progressant de la reconnaissance à l'extraction complète des identifiants.
Étape 1 : Identifier les points d'entrée intégrés à LDAP
L'attaquant identifie les fonctionnalités applicatives susceptibles d'interroger un backend LDAP. Selon le blog SANS LDAP, LDAP peut être utilisé pour la gestion, l'authentification et l'interrogation d'objets dans une base d'annuaire. Les formulaires de connexion, pages de recherche utilisateur, flux de réinitialisation de mot de passe, annuaires d'entreprise et portails VPN sont tous des surfaces candidates.
Étape 2 : Sonder les points d'injection
Le test OWASP LDAP recommande aux testeurs d'insérer les caractères (, |, &, * pour vérifier les réponses différentielles. Les messages d'erreur, ensembles de résultats vides ou changements de comportement de l'application confirment un paramètre vulnérable.
Étape 3 : Déduire la structure du filtre
Sans code source, les attaquants déduisent la structure du filtre LDAP par fuzzing. SANS note : « Il est peu probable lors d'un test d'intrusion que vous disposiez du code source pour voir ces instructions. Dans ces situations, le fuzzing et la reconnaissance peuvent être nécessaires. »
Étape 4 : Concevoir des charges utiles d'injection
Les charges utiles courantes incluent :
- Injection par caractère générique
(*)pour récupérer toutes les entrées de l'annuaire - Filtres toujours vrais
()(uid=))(|(uid=*)pour contourner l'authentification - Injection d'attribut basée sur OR ()(department=it)(|(cn=) pour collecter des identifiants sur plusieurs attributs
- Terminaison par classe d'objet nulle
(*)(objectClass=*))(& (objectClass=void)pour établir un oracle booléen fiable pour l'extraction aveugle
La charge utile spécifique dépend de la structure du filtre déduite par l'attaquant lors de la reconnaissance.
Étape 5 : Escalader via des chaînes d'attaque
Une chaîne d'attaque typique documentée dans les sources OWASP et MITRE ATT&CK suit cette progression :
- Contourner la connexion à l'aide d'un filtre toujours vrai
- Extraire les identifiants de domaine via une injection basée sur OR
- Créer des comptes de domaine via ldapmodify (ATT&CK T1136.002)
- Extraire NTDS.dit pour un craquage d'identifiants hors ligne (ATT&CK T1003.003)
L'injection LDAP aveugle permet une chaîne parallèle où les attaquants énumèrent les attributs de schéma à l'aide de sondes (attribute=*) puis extraient les valeurs caractère par caractère, y compris les hachages de mots de passe, les appartenances à des groupes et les identifiants de sécurité.
Ces schémas d'exploitation affectent un large éventail d'organisations et de types d'applications.
Qui est concerné par l'injection LDAP ?
Toute organisation reposant sur une authentification basée sur LDAP est structurellement exposée à cette vulnérabilité. OWASP note que les vulnérabilités d'injection sont « très répandues, en particulier dans le code hérité ».
Types d'applications les plus exposés :
- Applications web avec authentification LDAP (portails de connexion, systèmes SSO)
- Applications d'entreprise héritées utilisant des requêtes LDAP concaténées en chaîne
- Portails d'annuaire d'employés et de réinitialisation de mot de passe en libre-service
- Passerelles VPN et portails d'accès à distance
- Plateformes de gestion de systèmes de contrôle industriel
- Applications de bureau (OWASP Desktop App Security Top 10 répertorie l'injection LDAP sous DA1 Injections)
Secteurs à risque élevé :
- Santé : Les systèmes EHR et cliniques adossés à LDAP sont soumis à l'application HIPAA pour les vulnérabilités non corrigées, le HHS documentant les données de violation HHS dans les grandes violations entre 2018 et 2022.
- Services financiers : L'injection reste une surface d'attaque pertinente pour les systèmes d'entreprise liés à l'identité dans ce secteur.
- Gouvernement et infrastructures critiques : CISA a documenté une exploitation active dans les environnements gouvernementaux et les plateformes ICS du secteur de l'énergie.
- Logiciels et technologies : Les backends open source, outils de base de données et plateformes de développement continuent de produire de nouveaux CVE d'injection LDAP.
L'injection LDAP affecte un large éventail de logiciels, couvrant les environnements COBOL d'entreprise, les outils d'administration de bases de données, les plateformes du secteur de l'énergie et les backends open source. Il ne s'agit pas de risques hypothétiques ; des incidents récents les confirment.
Exemples réels d'injection LDAP
Les cas suivants illustrent comment l'injection LDAP se manifeste sur les réseaux gouvernementaux, les plateformes d'entreprise et les outils open source.
CISA Red Team : Entreprise sans visibilité LDAP (2024)
Une évaluation CISA a révélé que l'entreprise évaluée « n'avait pas de surveillance pour le trafic LDAP anormal ». L'équipe a interrogé LDAPS pour collecter des informations sur les utilisateurs, ordinateurs, groupes, ACL, UO et GPO. CISA a explicitement déclaré qu'un utilisateur non privilégié interrogeant LDAP depuis un hôte de domaine Linux « aurait dû alerter les défenseurs du réseau ».
OpenText Enterprise Server : contournement complet de l'authentification (CVE-2023-4501)
Cette vulnérabilité permettait à l'authentification de réussir avec n'importe quel nom d'utilisateur valide, quel que soit le mot de passe, et pouvait aussi réussir avec un nom d'utilisateur invalide. Elle affectait les environnements de développement et d'exécution COBOL d'entreprise déployés dans les services financiers, l'assurance et l'intégration mainframe gouvernementale.
Ivanti EPMM : des acteurs malveillants extraient des identifiants LDAP (2025)
Suite à la publication d'une preuve de concept en mai 2025, des acteurs malveillants ont accédé à un serveur Ivanti EPMM et extrait des identifiants LDAP. CISA a ajouté les vulnérabilités sous-jacentes au catalogue KEV le 19 mai 2025.
Redash : injection LDAP permettant le password spraying (CVE-2020-36144)
GitHub Security Lab a documenté que le champ e-mail dans l'authentification LDAP de Redash formatte une chaîne de filtre LDAP sans échappement, permettant à un attaquant non authentifié de forcer tous les mots de passe utilisateurs en une seule requête.
Ces incidents couvrent des décennies de défis de sécurité LDAP.
Chronologie et historique de l'injection LDAP
L'injection LDAP est une classe de vulnérabilité connue depuis plus de vingt ans, avec une classification formelle et des divulgations CVE continues depuis la fin des années 1990 jusqu'à aujourd'hui.
- Origines du protocole. Le protocole X.500 Directory Access Protocol (DAP) a été développé par l'UIT-T. LDAP v1 est apparu dans la RFC 1487, v2 dans la RFC 1777, et v3 dans la RFC 2251, qui reste la version utilisée en entreprise aujourd'hui.
- Premier problème documenté. CVE-1999-0895 a documenté un problème de sécurité d'authentification LDAP précoce dans Checkpoint FireWall-1 V4.0.
- Classification formelle. OWASP a formellement documenté l'injection LDAP comme une classe d'attaque distincte. Le Top 10 OWASP 2007 l'a classée sous A2, Injection Flaws.
- Recherche sur l'injection aveugle. Alonso et al. ont présenté une recherche systématique sur l'injection LDAP aveugle à Black Hat Europe, démontrant l'extraction de données caractère par caractère.
- Priorité maximale OWASP. Le Top 10 OWASP 2017 a classé l'injection comme A1, le risque numéro un des applications web, citant explicitement l'injection LDAP.
- Ciblage ICS. CVE-2018-14805 (ABB eSOMS) a introduit l'injection LDAP dans le secteur ICS de l'énergie.
- Ciblage des plateformes d'entreprise. ForgeRock OpenAM, OpenLDAP et OpenText Enterprise Server ont démontré un impact continu en entreprise.
- Divulgation récente. De nouveaux CVE ces dernières années affectent Apache Druid, WatchGuard Fireware, WeKan, Parse Server, Dell PowerMax et pgAdmin.
De nouveaux CVE continuent d'apparaître, ce qui rend la surveillance continue indispensable.
Comment détecter l'injection LDAP
Une surveillance en couches est nécessaire à travers les niveaux application, annuaire et réseau.
Indicateurs au niveau applicatif
Surveillez les champs de saisie utilisateur pour les métacaractères LDAP : *, (, ), \, et les octets NUL dans les paramètres d'authentification et de recherche. Surveillez les ensembles de résultats LDAP anormalement volumineux qui suggèrent une injection par caractère générique retournant toutes les entrées de l'annuaire. Un succès d'authentification immédiatement après une requête malformée signale un schéma de contournement d'authentification.
Indicateurs au niveau du serveur LDAP
Recherchez des structures de filtre contenant les séquences )( ou |(, qui indiquent une manipulation de groupe de filtres. Les requêtes retournant toutes les entrées via (objectClass=*) ou (cn=*) suggèrent une énumération par caractère générique. Un bind anonyme suivi d'opérations de recherche étendues indique des tentatives de reconnaissance non authentifiées.
Surveillance SIEM et des journaux d'événements
Pour les environnements Active Directory, deux identifiants d'événement Windows sont essentiels :
- Event ID 4662 : Opérations effectuées sur les objets AD. Surveillez les actions Write Property, Control Access, DELETE, WRITE_DAC et WRITE_OWNER.
- Event ID 1644 : Requêtes LDAP coûteuses ou inefficaces, que les tentatives d'injection produisent souvent.
Selon le guide NCC Group : « Recherchez des filtres de recherche inhabituels dans les journaux. Les attaquants utilisent souvent des filtres spécifiques pour énumérer les utilisateurs, groupes et ordinateurs. »
Schémas de corrélation comportementale
Corrélez les sources de données pour identifier les campagnes d'injection :
- Volume élevé de requêtes LDAP depuis une même adresse IP source (outillage d'injection)
- Énumération séquentielle d'attributs :
uid=a*, uid=b*(extraction par injection aveugle) - Échec de mot de passe suivi d'un succès de connexion immédiat (confirmation de contournement d'authentification)
- Hôte de domaine Linux non privilégié effectuant des requêtes LDAP en masse (exactement le schéma documenté par CISA comme non détecté)
La corrélation de ces signaux à travers les sources offre une vision plus claire des campagnes d'injection actives qu'un seul indicateur isolé.
Surveillance au niveau WAF
L'OWASP ModSecurity Core Rule Set inclut la règle ID 921200 dans REQUEST-921-PROTOCOL-ATTACK.conf, qui cible l'injection LDAP avec une sévérité CRITIQUE et Paranoia Level 1 (activé par défaut). La règle inspecte les cookies de requête, les noms d'arguments, les valeurs d'arguments et les corps XML pour les motifs de métacaractères de filtre LDAP.
Détecter une activité suspecte est insuffisant sans contrôles de prévention appropriés.
Comment prévenir l'injection LDAP
La prévention nécessite une approche de défense en profondeur couvrant le code, la configuration et l'infrastructure.
Défenses au niveau du code
- Utilisez des requêtes LDAP paramétrées. La défense la plus efficace consiste à passer l'entrée utilisateur en tant que paramètre plutôt que de la concaténer dans les chaînes de filtre :
- Appliquez l'échappement approprié au contexte. Utilisez la fonction d'échappement correcte pour le contexte LDAP approprié. Pour les filtres de recherche (RFC 4515), échappez *→
\2a, (→\28, )→\29, \→\5c, NUL→\00. Pour les Distinguished Names (RFC 2253), échappez\, #, +, <, >, ,, ;, ", =, et les espaces en début/fin.
Les implémentations spécifiques aux langages incluent :
| Langage | Échappement filtre de recherche | Échappement DN |
| Java | OWASP ESAPI encodeForLDAP() | OWASP ESAPI encodeForDN() |
| .NET | Encoder.LdapFilterEncode() | Encoder.LdapDistinguishedNameEncode() |
| Perl | Net::LDAP::Util::escape_filter_value() | Manuel selon RFC 2253 |
- Implémentez une validation par liste blanche. Validez l'entrée selon les motifs attendus avant toute opération LDAP. Rejetez les entrées contenant des métacaractères non attendus dans le champ. Normalisez l'entrée (canonicalisation Unicode) avant validation selon le cheat sheet OWASP.
Renforcement de l'infrastructure
- Désactivez le bind anonyme et non authentifié. Cette seule action élimine la cause racine de plusieurs vulnérabilités critiques.
- Utilisez LDAPS (port 636). Désactivez LDAP en clair (port 389) selon NIST SP 1800-16.
- Appliquez le principe du moindre privilège aux ACL des comptes de service LDAP. Limitez-les uniquement aux opérations et sous-arborescences nécessaires.
- Segmentez l'infrastructure LDAP de l'accès réseau général selon NIST SP 1800-18B.
Ces contrôles réduisent la surface d'attaque disponible pour un attaquant ayant atteint votre infrastructure LDAP.
Intégration dans la chaîne CI/CD
Intégrez l'analyse statique (SAST) et l'analyse dynamique (DAST) dans votre pipeline de développement. Le Top 10 OWASP recommande d'inclure des outils SAST, DAST et IAST pour identifier les failles d'injection avant le déploiement en production. Le mode d'analyse de flux de données de Semgrep peut suivre les entrées non fiables des sources vers les puits sans assainissement à l'aide de règles personnalisées ciblant la construction de requêtes LDAP.
Ces mesures de prévention fonctionnent au mieux lorsqu'elles sont soutenues par les bons outils.
Outils de détection et de prévention
Une défense efficace contre l'injection LDAP nécessite une combinaison d'outils de scan, de surveillance et de protection à l'exécution.
- OWASP ZAP propose un scan actif pour l'injection LDAP via ZAP Alert 40015 (CWE-90, WASC-29). Installez via les règles de scan Alpha du Marketplace ZAP et configurez le ciblage technologique pour inclure Protocol / LDAP pour les applications intégrant LDAP.
- OWASP ModSecurity CRS fournit une protection au niveau WAF via la règle CRS 921200, activée par défaut au niveau Paranoia 1. La règle inspecte les cookies, arguments et charges utiles XML pour les signatures de manipulation de filtre LDAP. Les charges de test de régression CRS issues de CRS Issue 276 fournissent une liste de mots pour le fuzzing WAF prête à l'emploi.
- Semgrep prend en charge l'analyse statique de flux de données via des règles mode: taint qui tracent les données non fiables des sources d'entrée vers les puits de requêtes LDAP, signalant les chemins d'injection avant que le code n'atteigne la production.
- Les plateformes SIEM avec des règles d'identification personnalisées peuvent surveiller les Event ID Windows 4662 et 1644, corréler les schémas de requêtes LDAP anormaux et alerter sur des indicateurs comportementaux comme l'énumération séquentielle d'attributs ou les requêtes en masse depuis des hôtes non privilégiés.
Ces outils traitent des couches individuelles du problème. Une approche plateforme les relie entre elles.
Réduire les risques liés à l'identité dans l'ensemble de votre organisation
Détecter et répondre aux attaques en temps réel grâce à des solutions globales pour Active Directory et Entra ID.
Obtenir une démonstrationVulnérabilités associées
Plusieurs classes de vulnérabilités partagent ce schéma avec l'injection LDAP :
- Injection SQL (CWE-89) : L'analogue le plus proche. Les deux exploitent des entrées non assainies dans des langages de requête, et le contournement de l'authentification est réalisable par des techniques similaires. La syntaxe et les systèmes cibles diffèrent significativement.
- Injection de commande OS (CWE-78) : Partage le même Software Fault Pattern (SFP24, « Entrée contaminée dans une commande ») avec CWE-90 selon MITRE. Cible le système d'exploitation hôte plutôt que les services d'annuaire.
- Injection XPath (CWE-643) : Le test LDAP OWASP regroupe explicitement l'injection XPath avec l'injection LDAP comme techniques analogues de contournement de l'authentification ciblant les magasins de données XML.
- Neutralisation incorrecte des éléments spéciaux (CWE-77) : La faiblesse parente de CWE-90 dans la hiérarchie MITRE. Tous les types d'injection découlent de cet échec généralisé à neutraliser les caractères significatifs pour l'interpréteur.
- Encodage ou échappement incorrect de la sortie (CWE-116) : Documente la chaîne directe de l'échec d'échappement à l'injection. CVE-2021-41232 démontre la chaîne CWE-116 → CWE-90 où un échec d'échappement dans une application Go a directement permis l'injection LDAP.
- Validation incorrecte des entrées (CWE-20) : La cause racine lorsque les applications ne valident pas le format de l'entrée avant de construire des requêtes LDAP.
L'examen de ces faiblesses associées vous aide à appliquer les mêmes principes de défense dans l'ensemble de votre code, pas seulement dans les chemins de code spécifiques à LDAP.
CVE associés
| ID CVE | Description | Gravité | Produit affecté | Année |
| L'injection LDAP dans SuiteCRM permet à des attaquants non authentifiés de manipuler les filtres de recherche, permettant le contournement de l'authentification ou la divulgation d'informations | Critique (9.8) | SalesAgility SuiteCRM <7.15.1 / 8.0.0–8.9.2 | 2026 | |
| WeKan incorpore des noms d'utilisateur non assainis dans les filtres de recherche LDAP et les valeurs DN, permettant à des attaquants distants non authentifiés de manipuler les requêtes LDAP lors de l'authentification | Critique (9.8) | WeKan Project WeKan <8.19 | 2026 | |
| Parse Server interpole authData.id fourni par l'utilisateur directement dans les Distinguished Names LDAP et les filtres de recherche de groupe, permettant l'élévation de privilèges | Élevée (8.8) | Parse Platform parse-server <8.6.26 | 2026 | |
| L'injection LDAP dans WatchGuard Fireware OS permet à des attaquants distants non authentifiés de récupérer des informations sensibles depuis un serveur LDAP connecté | Élevée (7.0) | WatchGuard Technologies Fireware OS 12.0–12.11.6 / 12.5–12.5.15 | 2026 | |
| Kanboard substitue directement l'entrée utilisateur non assainie dans les filtres de recherche LDAP, permettant à des attaquants non authentifiés d'énumérer les utilisateurs LDAP et de découvrir des attributs sensibles | Moyenne (5.3) | Kanboard Kanboard ≤1.2.48 | 2026 | |
| Le formulaire de connexion activé LDAP de Teedy permet une injection LDAP non authentifiée via le champ nom d'utilisateur, autorisant la création de compte arbitraire et le password spraying | Critique (9.8) | Sismics Teedy 1.9–1.12 | 2025 | |
| L'injection LDAP dans Apache HertzBeat permet à un attaquant authentifié de concevoir des commandes entraînant l'exécution arbitraire de scripts | Élevée (8.8) | Apache Software Foundation Apache HertzBeat ≤1.7.2 | 2025 | |
| L'injection de caractères spéciaux LDAP dans le champ nom d'utilisateur de pgAdmin 4 provoque le traitement d'une quantité excessive de données par le serveur et le client LDAP, entraînant un déni de service | Élevée (7.5) | PostgreSQL Global Development Group pgAdmin 4 <9.10 | 2025 | |
| Le formulaire d'authentification LDAP de GLPI peut être utilisé pour effectuer une injection LDAP par des attaquants non authentifiés, corrigé en version 10.0.12 | Élevée (8.1) | GLPI Project GLPI 0.70–<10.0.12 | 2024 | |
| Les utilisateurs privilégiés peuvent injecter des chaînes de filtre LDAP dans le fournisseur de contacts LDAP optionnel d'OX App Suite, accédant au contenu de l'annuaire hors de la hiérarchie prévue | Élevée (~8.0) | Open-Xchange OX App Suite <7.10.6 | 2024 | |
| NVIDIA DGX A100 BMC contient une vulnérabilité d'injection d'utilisateur LDAP exploitable par des attaquants non authentifiés sur le réseau adjacent, entraînant une divulgation d'informations | Moyenne (~6.5) | NVIDIA DGX A100 BMC | 2024 | |
| La requête de connexion LDAP de Mastodon est non sécurisée, permettant à des attaquants authentifiés de divulguer des attributs arbitraires de l'annuaire LDAP | Élevée (7.7) | Mastodon Mastodon 2.5.0–4.1.1 | 2023 | |
| Un nom d'utilisateur forgé contourne l'authentification LDAP dans Apache Derby, pouvant entraîner une saturation disque, l'exécution de logiciels malveillants et un accès non autorisé à la base de données | Critique (9.8) | Apache Software Foundation Apache Derby ≤10.16.1.1 | 2022 | |
| La bibliothèque libsss_certmap de SSSD ne nettoie pas les données de certificat utilisées dans les filtres LDAP, permettant à un attaquant authentifié d'injecter des éléments de requête LDAP et d'obtenir un accès non autorisé | Élevée (8.8) | Red Hat / SSSD Project SSSD | 2022 | |
| Apache ManifoldCF transmet les noms d'utilisateur et de domaine aux requêtes de recherche LDAP sans validation dans ses connecteurs d'autorité ActiveDirectory | Moyenne (5.3) | Apache Software Foundation Apache ManifoldCF 0–2.23 | 2022 | |
| Thunderdome Planning Poker n'échappe pas les noms d'utilisateur avant les requêtes LDAP lorsque l'authentification LDAP est activée, permettant une injection LDAP non authentifiée | Critique (9.8) | Thunderdome Planning Poker <1.16.3 | 2021 | |
| La fonctionnalité ldapRegistry-3.0 d'IBM Open Liberty contient une vulnérabilité d'injection LDAP | Élevée (7.5) | IBM Open Liberty ldapRegistry-3.0 (v17.0.0.3–22.0.0.1) | 2021 | |
| ForgeRock OpenAM permet l'injection LDAP via le protocole Webfinger, permettant la récupération non authentifiée caractère par caractère de hachages de mots de passe ou de jetons de session | Élevée (est.) | ForgeRock OpenAM <13.5.1 | 2021 |
Conclusion
L'injection LDAP donne aux attaquants la possibilité de transformer une entrée non fiable en contrôle sur les systèmes d'annuaire dont dépend votre environnement pour l'authentification et l'accès. Pour vous, cela signifie que le risque est rarement limité à une seule requête ou application.
Si vous construisez les requêtes de manière sécurisée, échappez les valeurs dans le bon contexte, restreignez les permissions de bind et surveillez attentivement l'activité LDAP, vous réduisez à la fois l'exposition et la marge de manœuvre des attaquants.
FAQ
L'injection LDAP est une faille de gestion des entrées dans les logiciels qui construisent des requêtes LDAP à partir de données non fiables. Un attaquant peut modifier la façon dont l'annuaire interprète une requête, transformant une vérification de connexion en condition toujours vraie, élargissant une recherche restreinte à une énumération complète de l'annuaire, ou abusant des opérations d'ajout et de modification dans l'arborescence LDAP.
Oui. L'injection LDAP relève de la catégorie plus large des injections de l'OWASP, plutôt que d'être une entrée distincte du Top 10. En pratique, cela signifie que vous devez examiner le code utilisant LDAP avec la même rigueur que pour l'injection SQL, car les deux failles proviennent d'entrées non fiables atteignant un interpréteur.
Oui. Si votre formulaire de connexion exposé sur le web, page de recherche, portail ou interface de gestion transmet des entrées utilisateur à un backend LDAP, un attaquant peut commencer l'exploitation via le réseau.
Dans de nombreux cas, il n'est pas nécessaire de disposer d'identifiants valides pour commencer à sonder la manipulation des filtres.
Les applications les plus à risque sont celles qui utilisent LDAP pour les décisions d'identité : portails de connexion et systèmes SSO, outils de réinitialisation de mot de passe et de recherche d'annuaire, passerelles VPN et portails d'accès à distance, ainsi que les applications d'entreprise héritées qui construisent des requêtes LDAP par concaténation de chaînes.
Les attaquants commencent généralement par des sondes simples. Ils soumettent des métacaractères LDAP tels que (, |, & et *, puis observent les réponses modifiées, les erreurs ou des nombres de résultats inhabituels.
Une fois la structure du filtre déduite, ils passent à des charges utiles d'extraction par joker, OR ou à l'aveugle.
Les premiers signes incluent souvent des métacaractères dans les champs d'authentification ou de recherche, des ensembles de résultats LDAP inhabituellement larges, des motifs )( ou |( dans les filtres, un échec de connexion immédiatement suivi d'un succès, et des requêtes LDAP en masse depuis un hôte non privilégié.
Elle est grave car LDAP contrôle souvent l'authentification et l'autorisation au-delà d'une seule application. Une injection réussie peut exposer des données d'annuaire, contourner les contrôles de connexion ou alimenter la planification de mouvements latéraux dans l'environnement.
Cette portée rend l'impact métier plus large que de nombreuses failles limitées aux applications.
Oui, en particulier comme première étape d'une chaîne d'attaque sur l'identité. Un attaquant peut passer du contournement de connexion ou de l'énumération d'annuaire à la collecte d'identifiants, la création de comptes, l'extraction de NTDS.dit et l'accès persistant via des comptes valides.
L'injection est souvent le point d'entrée, pas l'objectif final.
Les outils aident, mais ne résolvent pas le problème à eux seuls. Les scanners et les règles WAF peuvent détecter les cas évidents, tandis que l'injection à l'aveugle et une journalisation LDAP faible restent plus difficiles à repérer.
Si vous manquez de visibilité sur le trafic LDAP et le comportement des requêtes, vous pouvez passer à côté de l'activité même lorsque l'exploitation est déjà en cours.
Les secteurs dépendant fortement d'une identité centralisée présentent la plus forte concentration de risques. L'article met en avant la santé, les services financiers, le gouvernement, les infrastructures critiques et les plateformes logicielles.
Ce qui les relie est la dépendance à l'authentification basée sur LDAP pour les utilisateurs à forte valeur, les systèmes et les flux administratifs.
