LDAP est l'acronyme de Lightweight Directory Access Protocol. LDAP est un protocole pour stocker les informations sur les utilisateurs, les hôtes et de nombreux autres objets. L'injection LDAP est une attaque côté serveur, ce qui pourrait permettre à un attaquant de divulguer, modifier ou insérer des informations sensibles sur les utilisateurs et les hôtes représentés dans une structure LDAP

Ceci est fait en manipulant les paramètres d'entrée transmis à la recherche interne, pour ajouter et modifier les fonctions.

Une application Web peut utiliser le protocole LDAP afin de permettre aux utilisateurs d'authentifier ou de rechercher des informations d'autres utilisateurs à l'intérieur d'une structure.

Le but des attaques par injection LDAP consiste à injecter de filtres métacaractères de recherche LDAP dans une requête qui sera exécutée par l'application.

[RFC2254] définit une grammaire sur la façon de construire un filtre de recherche LDAPv3 et s'étend sur [Rfc1960] (LDAPv2).

Un filtre de recherche LDAP est construit en «Polish notation», également connu sous le nom [notation prefix].

Cela signifie qu'un pseudo-code condition sur un filtre de recherche comme ceci:

find("cn=John & userPassword=mypass")

sera représentée comme suit:

find("(&(cn=John)(userPassword=mypass))")

Conditions booléennes et agrégations de groupe sur un filtre de recherche LDAP peuvent être appliquées en utilisant les métacaractères suivants:

Des exemples plus complets sur la façon de construire un filtre de recherche peut être trouvée dans le RFC lié.

Une exploitation réussie d'une vulnérabilité d'injection LDAP pourrait permettre au testeur de:

• Accéder au contenu non autorisé
• Contourner les restrictions d'application
• Recueillir des informations non autorisées
• Ajouter ou modifier des objets à l'intérieur de l'arborescence LDAP.

Supposons que nous avons une application web en utilisant un filtre de recherche comme celui ci-dessous:

searchfilter="(cn="+user+")"

qui est instancié par une requête HTTP comme ceci:

http://www.example.com/ldapsearch?user=John

Si «John» est la valeur est remplacée par un '*', dans la requête:

http://www.example.com/ldapsearch?user=*

le filtre ressemblera à ceci:

searchfilter="(cn=*)"

ce qui correspond à chaque objet avec un attribut 'cn' égal à toutes choses.

Si la demande est vulnérable à l'injection LDAP, il affiche tout ou partie des attributs des utilisateurs, en fonction du flux d'exécution de l'application et des autorisations de l'utilisateur connecté à LDAP.

Un testeur peut utiliser une approche par essais et erreurs, en insérant dans le paramètre '(', '|', '&', '*' et les autres caractères.

Si une application Web utilise le protocole LDAP pour vérifier les informations d'identification utilisateur lors du processus de connexion et si LDAP est vulnérable à l'injection, il est possible de contourner la vérification de l'authentification par injection d'une requête LDAP toujours vraie (d'une manière similaire à l'injection SQL et XPath).

Supposons qu'une application web utilise un filtre pour rechercher dans LDAP la correspondance utilisateur / mot de passe.

searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))"; 

En utilisant les valeurs suivantes:

user=*)(uid=*))(|(uid=*
pass=password

le filtre de recherche retourne la résultat:

searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";

ce qui est correct et toujours vrai. De cette façon, le testeur connecté gagne le statut de premier utilisateur dans l'arborescence LDAP.

• Sacha Faust: “LDAP Injection: Are Your Applications Vulnerable?” - http://www.networkdls.com/articles/ldapinjection.pdf
• Bruce Greenblatt: “LDAP Overview” - http://www.directory-applications.com/ldap3_files/frame.htm
• IBM paper: “Understanding LDAP” - http://www.redbooks.ibm.com/redbooks/SG244986.html

• Softerra LDAP Browser - http://www.ldapadministrator.com/download/index.php