ECOLE CENTRALE DES LOGICIELS LIBRES ET DE

TELECOMMUNICATIONS

INSTITUT SUPÉRIEUR DE TECHNOLOGIE DE l'UNIVERSITÉ DE

BANGUI (IST/UB)

LES INJECTIONS (SQL, LDAP) MISES EN EVIDENCE

➢ Présenté par : Sous la Direction du

Ismaïla FALL Pr Samuel OUYA
Table des matières
I. OWASP............................................................................................................................... 1
II. Définition de l’attaque par injection ................................................................................... 2
II.1. Les types d’attaques par injection ............................................................................... 2
II.2. Injection SQL – signification et définition .................................................................. 2
II.2.1. Comment fonctionnent les attaques par injection SQL ? ..................................... 2
II.2.2. Exemple d’injection SQL ..................................................................................... 3
II.2.3. Mise en évidence .................................................................................................. 3
III. ZAP : exploitation de vulnérabilités................................................................................ 8
III.1. Concepts et caractéristiques clés du scanner ZAP ....................................................... 9
III.2. Composants clés de l’interface utilisateur de bureau ................................................ 10
III.3. Test d’intrusion par injection SQL (Authentication bypass) ..................................... 13
III.4. Correctif pour éviter les attaques de types injections SQL ....................................... 15
IV. Les injections LDAP ..................................................................................................... 18
IV.1. Configuration de l'environnement ............................................................................. 18
IV.2. Filtre LDAP ............................................................................................................... 23
IV.3. Contournement de la connexion par injection ........................................................... 24
IV.4. Correctif ..................................................................................................................... 26
Conclusion ................................................................................................................................ 27
I. OWASP
De nouveaux risques numériques émergent constamment, tout comme les stratégies de
prévention et d’atténuation qui protègent les applications contre les attaques. Rester en phase
peut être difficile, mais ne pas le faire pourrait s’avérer dévastateur : sans une stratégie de
sécurité robuste, on risque des violations de données, des attaques de logiciels malveillants,
etc. Heureusement, de nombreuses excellentes ressources sont disponibles.
L’Open Worldwide Application Security Project (OWASP) est une communauté en ligne qui
produit des articles, des méthodologies, de la documentation, des outils et des technologies
disponibles gratuitement dans le domaine de la sécurité des applications Web. Il est dirigé par
une organisation à but non lucratif appelée The OWASP Foundation.
Le Top 10 de l’OWASP est une excellente option, car il fournit des informations complètes et
à jour. Cette ressource clé nous aidera à déterminer où se situent les plus grands risques de
nos jours et comment on peut les gérer.

Le Top 10 de l’OWASP change fréquemment, mais vaut toujours la peine d’être examiné.
Les préoccupations incluses dans cette liste sont parmi les plus courantes et les plus
alarmantes dans le monde numérique d’aujourd’hui.

Les 10 principaux risques liés à la sécurité des applications Web :

1. Injections (SQL, NoSQL et LDAP)
2. Défaillances cryptographiques (TP de redirection de Http vers Https)
3. Conception non sécurisée
4. Contrôle d’accès défectueux (TP élevation de privileges)
5. Mauvaise configuration de la sécurité ( Mise à jour des logiciels, utilisation de
WAF, nmap)
6. Composants vulnérables et obsolètes
7. Échecs d’identification et d’authentification ( Mot de passe non rebuste
authentication multifacteur (empreintes digitales, reconnaissance faciale))
8. Défaillances de l’intégrité des logiciels et des données (cors)
9. Échecs de journalisation et de surveillance de sécurité (fail2ban, denyhost, rsyslog,
sysmon)
10. Falsification de requêtes côté serveur (ssrf, csrf, xspa)
Dans ce guide, nous allons mettre en évidence le premier risque du Top 10 à savoir les
injections (SQL et LDAP) et montrer comment les prévenir.

1
II. Définition de l’attaque par injection
L’attaque par injection consiste en l’insertion de code dans un programme ou une application
Web. Ce faisant, le cybercriminel tente de changer le cours d’exécution de sa cible, ce qui
peut engendrer une multitude de conséquences, telle la propagation de logiciels malveillants
ou encore une attaque par déni de service.

II.1. Les types d’attaques par injection

L’injection SQL est invariablement la forme d’injection la plus répandue dans le monde de la
cybercriminalité. Cette dernière est souvent menée en exploitant des formulaires qui se
retrouvent sur les sites Web. Ainsi, en injectant des caractères ou des lignes de code dans le
formulaire, les pirates peuvent se connecter à des espaces utilisateurs. Ils peuvent ainsi
extraire des informations telles que les noms d’utilisateur, les mots de passe ou encore des
numéros de carte de crédit.
Il existe de nombreux autres types d’injections, soit l’injection CRLF, le Cross-site Scripting
(XSS), l’injection par courriel via SMTP, l’injection de commande dans un système
opérateur, l’injection LDAP et l’injection XPath.
II.2. Injection SQL – signification et définition
Une injection SQL, parfois abrégée en SQLi, est un type de vulnérabilité dans lequel un pirate
utilise un morceau de code SQL (« Structured Query Language ») pour manipuler une base de
données et accéder à des informations potentiellement importantes. C'est l'un des types
d'attaques les plus répandus et menaçants, car il peut potentiellement être utilisé pour nuire à
n'importe quelle application Web ou n'importe quel site Web qui utilise une base de données
SQL (soit la plupart).
II.2.1. Comment fonctionnent les attaques par injection SQL ?
Pour mieux comprendre ce qu'est l'injection SQL, il est important de savoir ce qu'est le
langage de requête structuré (SQL). SQL est un langage de requête utilisé en programmation
pour accéder, modifier et supprimer des données stockées dans des bases de données
relationnelles. Étant donné que la grande majorité des sites et des applications Web reposent
sur des bases de données SQL, une attaque par injection SQL peut avoir de graves
conséquences sur les organisations.

2
C'est par exemple le cas lorsque les informations de connexion sont envoyées via un
formulaire Web pour permettre à un utilisateur d'accéder à un site. Généralement, ce type de
formulaire Web est conçu pour accepter seulement des types de données spécifiques, tels que
le nom et/ou le mot de passe. Lorsque ces informations sont ajoutées, elles sont vérifiées par
rapport à une base de données et, si elles correspondent, l'utilisateur est autorisé à entrer. Dans
le cas contraire, l'accès est refusé.
Des problèmes potentiels peuvent survenir, car la plupart des formulaires Web ne disposent
d'aucun moyen pour arrêter la saisie d'informations supplémentaires sur les formulaires. Les
pirates peuvent exploiter cette faille et utiliser les boîtes de saisie du formulaire pour envoyer
leurs propres demandes vers la base de données. Cela pourrait potentiellement leur permettre
d'effectuer plusieurs types d'activités malveillantes, allant du vol de données sensibles à la
manipulation d'informations de la base de données à leurs propres fins.
II.2.2. Exemple d’injection SQL

II.2.3. Mise en évidence

Nous allons déployer une application Web en PHP qui authentifie les utilisateurs dans une
base de données MySQL.
Configuration de l'environnement
On va utiliser WAMP (Windows, Apache, Mysql, Php) sur Windows 10 pour faciliter
l'installation.

3
On va également utiliser Owasp Zap un outil pratique qui identifie automatiquement les
vulnérabilités de sécurité des applications Web pendant le développement et les tests.
➢ Configuration de notre base de données :
Démarrage de WAMP

Création de la base de données zap_test et des comptes utilisateurs

Base de données

Création des comptes des utilisateurs

Création de l’utilisateur de connexion à la base données

4
Pour héberger notre application on crée un dossier test dans C:\wamp\www

On met les codes suivant dans ce dossier

index.php

<!DOCTYPE html>
<html>
<style>
input[type=text], input[type=password]{
width: 100%;
padding: 12px 20px;
margin: 8px 0;
display: inline-block;
border: 1px solid #ccc;
border-radius: 4px;
box-sizing: border-box;
}

input[type=submit] {
width: 100%;
background-color: #4CAF50;
color: white;
padding: 14px 20px;
margin: 8px 0;
border: none;
border-radius: 4px;
cursor: pointer;
}

input[type=submit]:hover {
background-color: #45a049;
}

div {
width: 50%;
border-radius: 5px;
background-color: #f2f2f2;
padding: 20px;
}
</style>

5
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Test d'injections</title>
</head>
<body>
<h1>Formulaire de connexion</h1>
<div>
<form action="traitement.php" method="post">

<label for="username">Nom d'utilisateur :</label><br>

<input type="text" name="username" id="username" required><br>

<label for="password">Mot de passe :</label><br>

<input type="password" name="password" id="password" required>
<br>
<br>
<input type="submit" value="Se connecter">
</form>
</div>
</body>
</html>

traitement.php
<?php
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
// Code pour traiter la soumission du formulaire
$username = $_POST['username'];
$password = $_POST['password'];

// Connexion à la base de données

$host = "localhost";
$dbname = "zap_test";
$dbuser = "izolo";
$dbpass = "passer";

$conn = new PDO("mysql:host=$host;dbname=$dbname", $dbuser, $dbpass);

// Requête vulnérable aux injections SQL

$query = "SELECT * FROM zap_users WHERE username = '$username' AND password = '$password'";

// Exécution de la requête
$result = $conn->query($query);

// Vérification des résultats

6
if ($result && $result->rowCount() > 0){
// Utilisateur authentifié
echo "Bienvenue, $username !";
} else {
// Authentification échouée
echo "Nom d'utilisateur ou mot de passe incorrect.";
}

// Fermeture de la connexion
$conn = null;
?>

On ouvre maintenant un onglet pour s’authentifier avec un compte existant avec l’url :
localhost/test
On renseigne un login et un mot de passe pour se connecter.

Si les identifiants renseignés sont valides alors on accède à la page d’accueil

Maintenant tentons de fournir un mot de passe invalide.

7
On clique sur se connecter

Comme on le voit l’application nous signale une erreur : l’application fonctionne

correctement.
MAIS EST-ELLE VULNERABLE AUX INJECTIONS SQL?
C’est que nous allons tenter de savoir. Pour cela on a besoin d’installer ZAP.

III. ZAP : exploitation de vulnérabilités

OWASP Zed Attack Proxy (ZAP) est un outil de sécurité gratuit activement maintenu par des
volontaires internationaux. Il identifie automatiquement les vulnérabilités de sécurité des
applications Web pendant le développement et les tests. Les testeurs d’intrusion expérimentés
peuvent utiliser OWASP ZAP pour effectuer des tests de sécurité manuels.
Nous allons installer et lancer ZAP

8
III.1. Concepts et caractéristiques clés du scanner ZAP
Analyse active
L’analyse active utilise des attaques connues pour identifier les vulnérabilités potentielles, ce
qui signifie qu’elle ne peut trouver que des vulnérabilités spécifiques. Les analyses de
vulnérabilité actives ou automatiques ne peuvent pas trouver d’erreurs dans la logique de
l’application. Cela n’est possible que lors d’un audit manuel.
Analyse passive
Par défaut, ZAP analyse les requêtes HTTP et toutes les réponses envoyées et reçues de votre
application. L’analyse passive n’affecte pas leur contenu. On peut ajouter des balises ou des
alertes pour vous informer de toute erreur potentielle. Bien que cette option soit activée par
défaut, il est également possible de la configurer.
OWASP ZAP Fuzzer
OWASP ZAP permet d’utiliser un fuzzer qui envoie de nombreuses données inattendues ou
incorrectes à une application testée. On peut créer nos propres charges utiles, utiliser l’une des
charges utiles intégrées ou télécharger les modules complémentaires de charges utiles fournis
par la communauté ZAP.
API OWASP ZAP
OWASP ZAP fournit une API qui accepte JSON, XML et HTML. Les fonctionnalités de
l’API sont expliquées sur une page Web, en spécifiant que la valeur par défaut autorise
uniquement la machine exécutant ZAP à se connecter à l’API. Toutefois, on peut utiliser les
options de configuration pour autoriser d’autres machines à contacter l’API.
Test WebSocket
Les WebSockets sont très répandus dans toutes les applications. ZAP permet d’intercepter,
d’analyser ou de falsifier facilement le trafic WebSocket entre le client et le serveur. On peut
accéder à l’éditeur de messages WebSocket en accédant au menu ZAP, en choisissant Outils,
puis en sélectionnant Éditeur de message WebSocket. L’éditeur permet de falsifier le
message Direction, Opcodes ou WebSocket avant qu’il ne soit renvoyé au serveur.
Araignée JAX
ZAP permet d’effectuer un spidering AJAX lors d’un test d’intrusion pour identifier les
requêtes sur une application Web riche en AJAX. Cet outil inclut des paramètres de
configuration tels que la profondeur maximale d’analyse, la durée maximale, les états
d’analyse maximaux et d’autres options pour nous aider à empêcher l’analyse infinie.
Gestion des stratégies d’analyse
ZAP permet de composer une stratégie d’analyse en fonction des exigences spécifiques de
chaque application. On peut trouver le Gestionnaire de stratégies d’analyse sous la barre de
menu.
Marché ZAP

9
ZAP Marketplace comprend des add-ons gratuits et open source écrits par l’équipe ZAP ainsi
que par la communauté. Ces modules complémentaires permettent d’étendre les
fonctionnalités d’une implémentation ZAP..
III.2. Composants clés de l’interface utilisateur de bureau
L’interface utilisateur du bureau de ZAP est composée des éléments suivants :
1. Barre de menus : permet d’accéder aux outils manuels et automatisés de ZAP.
2. Barre d’outils : permet d’accéder facilement aux fonctionnalités ZAP couramment
utilisées.
3. Fenêtre de l’arborescence (Tree Window) : affiche l’arborescence Scripts
et l’arborescence Sites.
4. Fenêtre Espace de travail : affiche les réponses, les scripts et les demandes et permet
de les modifier.
5. Fenêtre d’informations : affiche les détails des outils manuels et automatisés.
6. Pied de page – affiche un résumé de toutes les alertes et l’état de tous les principaux
outils automatisés.

1
2

Maintenant lançons une analyse automatisée.

Pour cela on clique sur Automated Scan, ensuite on renseigne l’url de notre application Web,
puis on clique sur le bouton Attaquer.

10
Après avoir cliqué sur le bouton Attaquer, ZAP commence à explorer l’application Web avec
son araignée, en analysant passivement chaque page qu’elle trouve. Ensuite, ZAP utilise
l’analyseur actif pour attaquer toutes les pages, paramètres et fonctionnalités découverts.
Après avoir lancer l’attaque, on attend que la jauge de progression du scan atteigne les 100%.

Le scan terminé, on se rend dans l’onglet Alertes pour voir les vulnérabilités détectées.

Comme on le voit sur la capture ci-dessus Zap détecte plusieurs types de failles dont
l’injection SQL (2) avec un niveau d’alerte élevé ( drapeau rouge). Les autres failles seront
traitées dans d’autres supports.

11
Regardons de plus près :

En cliquant sur la faille, on accède aux détails liés au problème :

Le paramètre « password » défini dans notre code traitement.php est vulnérable à une attaque
ZAP' OR '1'='1' -- .
Il en est de même pour le paramètre « username »

12
III.3. Test d’intrusion par injection SQL (Authentication bypass)
Test d’injection avec notre formulaire de connexion.
Puisque Zap nous dit que les champs username et password sont vulnérable. Dans ce cas on
va se connecter avec le compte ‘ismaila’ et donner un mot passe « ZAP' OR '1'='1' -- »

On clique Se connecter.

13
On voit qu’on s’est connecté sans fournir de mot passe correcte (on a injecté du code ).
Recommençons le test en injectant le code dans username

Ceci montre que même si notre application fonctionne correctement, elle reste quand même
vulnérable aux injections sql.
Le problème vient de la requête utilisée pour authentifier les utilisateurs.
// Requête vulnérable aux injections SQL
$query = "SELECT * FROM zap_users WHERE username = '$username' AND password = '$password'";

14
En insérant la tautologie : ZAP' OR '1'='1' -- (injection de type "always true") dans
password.
La requete deviendra :
SELECT * FROM zap_users WHERE username = '$username' AND password = ZAP' OR
'1'='1' -- '
Cette tautologie est utilisée lors de l’évaluation de la requête SQL qui, par conséquent, est
toujours valide, quel que soit le nom d’utilisateur, ce qui permet de contourner le processus
d’authentification.
On peut également essayer d’autres requêtes : Suppression, Modification etc.
Exemple de modification de mot de passe d’un utilisateur
'; UPDATE zap_users SET password='nepasseraplus' WHERE username='ismaila'; --
Si on renseigne cette requête dans le champ nom d’utilisateur du formulaire, cela va modifier
le mot de passe de connexion de l’utilisateur « ismaila » en « nepasseraplus ».
Cela démontre le danger de construire des requêtes SQL en insérant directement des valeurs
d'entrée sans échapper correctement les caractères spéciaux.
Pour éviter cela, il est essentiel d'utiliser des requêtes préparées ou de valider les entrées. De
cette manière, les valeurs seront traitées de manière sécurisée et les attaques d'injection SQL
seront prévenues.
III.4. Correctif pour éviter les attaques de types injections SQL
Il convient d'adopter un ensemble de techniques simples pour empêcher les vulnérabilités
d'injection SQL. Ces techniques peuvent être utilisées avec pratiquement n’importe quel type
de langage de programmation avec n’importe quel type de base de données.
Défenses principales :
❖ Option 1 : Utilisation d’instructions préparées (avec des requêtes paramétrées)
❖ Option 2 : validation des entrées
❖ Option 3 : Échappement de toutes les entrées fournies par l’utilisateur

Dans l’exemple qui va suivre nous allons utiliser les requêtes préparées pour éviter les
attaques d’injections SQL.
En revoyant notre code il suffit juste d’ajouter les lignes suivantes et de supprimer l’ancienne
requête :

15
Voici le correctif
// Requête préparée :::::: Correctif injections SQL

$query = "SELECT * FROM zap_users WHERE username = :username AND password = :password";
$stmt = $conn->prepare($query);
$stmt->execute([
'username' => $username,
'password' => $password
]);

Maintenant pour s’assurer effectivement que l’applications n’est plus vulnérable aux
injections SQL on relance ZAP :

Après on regarde les alertes :

16
 Il n’a plus détecté les failles
de type injection SQL

Au niveau des alertes Zap ne signale plus que notre application est vulnérable aux injections
SQL.
Reprenons les tests d’injections

En cliquant sur

On s’aperçoit affectivement qu’il n’est plus possible d’effectuer des injections SQL sur notre
application.

17
IV. Les injections LDAP
L’injection LDAP est une attaque utilisée pour exploiter les failles des applications Web qui
construisent des instructions LDAP basées sur les entrées utilisateur. Lorsqu’une application
ne parvient pas à nettoyer correctement les entrées utilisateur, il est possible de modifier les
instructions LDAP à l’aide d’un proxy local. Cela peut entraîner l’exécution de commandes
arbitraires telles que l’octroi d’autorisations pour les requêtes non autorisées et la
modification du contenu dans l’arborescence LDAP. Les mêmes techniques d’exploitation
avancées disponibles dans l’injection SQL peuvent être appliquées de la même manière dans
l’injection LDAP
Dans ce deuxième exemple nous allons refaire la même chose mais cette fois nous allons
utiliser un annuaire LDAP à la place de la base de données MySQL pour l’authentification
des utilisateurs.
IV.1. Configuration de l'environnement
On va utiliser XAMPP (X-operating system, Apache, Mysql, Php, Perl) sur Windows 10 pour
héberger et exécuter l’application et installer notre annuaire dans une machine Ubuntu
20.04.6.
Vérifiions si Apache prend en charge l’extension ldap dans le fichier php.ini

NB nous avons déjà configuré et inséré des utilisateurs dans l’annuaire

18
Le dossier d’hébergement de site (application) de XAMPP est C:\xampp\htdocs\
Le dossier ldap est le répertoire de base de l’application

Dans ce dossier, on crée les fichiers suivants :

index.php
<!DOCTYPE html>
<html>
<style>
input[type=text], input[type=password]{
width: 100%;
padding: 12px 20px;
margin: 8px 0;
display: inline-block;
border: 1px solid #ccc;
border-radius: 4px;
box-sizing: border-box;
}

input[type=submit] {
width: 100%;
background-color: #4CAF50;
color: white;
padding: 14px 20px;

19
 margin: 8px 0;
border: none;
border-radius: 4px;
cursor: pointer;
}

input[type=submit]:hover {
background-color: #45a049;
}

div {
width: 50%;
border-radius: 5px;
background-color: #f2f2f2;
padding: 20px;
}
</style>

<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Formulaire injections LDAP</title>

</head>
<body>
<h1>Formulaire connexion</h1>
<div>
<form action="accueil.php" method="post">

<label for="username">Nom d'utilisateur :</label><br>

<input type="text" name="username" id="username" required><br>

<label for="password">Mot de passe :</label><br>

<input type="password" name="password" id="password" required>
<br>
<br>

<input type="submit" value="Se connecter">

</form>
</div>
</body>
</html>

accueil.php
<?php
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
// connexion

20
$ldapServer = 'ldap://192.168.1.153';
$ldapPort = 389;

$ldapConn = ldap_connect($ldapServer, $ldapPort);

ldap_set_option($ldapConn, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($ldapConn, LDAP_OPT_REFERRALS, 0);
if (!$ldapConn) {
die('Impossible de se connecter au serveur LDAP.');
}

// dn et mot passe de l'adimin

$ldapBindUser = 'cn=admin,dc=rtn,dc=sn';
$ldapBindPassword = 'passer';

$ldapBind = ldap_bind($ldapConn, $ldapBindUser, $ldapBindPassword);

if (!$ldapBind) {
die('Échec de l\'authentification LDAP.');
}

$username = $_POST['username'];
$password = $_POST['password'];

$ldapSearchBase = 'ou=people,dc=rtn,dc=sn';

//Filtre de recherche
$ldapSearchFilter = "(&(uid=$username)(userPassword=$password))";

// Recherche de l'utilisateur
$ldapResult = ldap_search($ldapConn, $ldapSearchBase, $ldapSearchFilter);

if ($ldapResult === false) {

die('Échec de la recherche LDAP.');
}
// recupération de l'entrée
$entries = ldap_get_entries($ldapConn, $ldapResult);

if ($entries['count']) {
$userDn = $entries[0]['dn'];

//if (ldap_bind($ldapConn, $userDn, $password))

if ($userDn = $entries[0]['dn']){
// Authentification réussie
echo "<br>";
echo "<br>";
echo 'Authentification réussie pour l\'utilisateur: ' . $username;
echo "<br>";
echo "<br>";

21
 $ii=0;
for ($i=0; $ii<$entries[$i]["count"]; $ii++){
$data = $entries[$i][$ii];
echo $data.": ".$entries[$i][$data][0]."<br>";
}

} else {
echo 'Mot de passe incorrect.';
}
} else {
echo 'Utilisateur non trouvé.';
}

// Fermeture de la connexion LDAP

ldap_close($ldapConn);
}
?>

Maintenant on va se connecter avec des identifiants valides

Après authentification, on retourne les informations de l’utilisateur :

22
L’application fonctionne correctement.

MAIS VA-T-ELLE RÉSISTER AUX INJECTIONS LDAP ?

Avant de passer à l’injection LDAP, il est important de comprendre comment effectuer des
requêtes LDAP avec les filtres.
IV.2. Filtre LDAP
Les filtres LDAP sont constitués d’un ou plusieurs critères. S’il existe un ou plusieurs critères
dans une définition de filtre, ils peuvent être concaténés par des opérateurs logiques
AND ou OR. Les opérateurs logiques sont toujours placés devant les opérandes (c’est-à-dire
les critères). C’est ce que l’on appelle la notation polonaise ou « Polish notation ».

Les critères de recherche doivent être mis entre parenthèses.

Exemples :
Avec l’opération ET :

(& (... C1...) (... C2...)) ou avec plus de deux critères: (& (... C1...) (... C2...) (... C3...) (...
C4...))

23
Avec l’opération OU :
(| (... C1...) (... C2...)) ou avec plus de deux critères: (| (... C1...) (... C2...) (... C3...) (... C4...))

Les critères de recherche consistent en une exigence pour un attribut LDAP, par exemple
(givenname=Mbaye).
Les règles suivantes devraient être prises en compte :

Égalité: (attribute=abc ) , par exemple (&(uid=ismaila)(userPassword=passer))

Négation: (!( attribut=abc)) , par exemple (!objectClass=group)
Présence: (attribut=*) , par exemple (mailNickName=*)
Absence: (!( attribute=*)) , par exemple (!proxyAddresses=*)
Plus grand que: (attribut>=abc) , par exemple (mdbStorageQuota>=100000)
Moins de: (attribut<=abc) , par exemple (mdbStorageQuota<=100000)
Proximité: (attribute~=abc) , par exemple (displayName~=ismaila)

Dans un annuaire LDAP chaque DN pointe vers exactement une entrée, qui peut être
considérée comme une ligne dans un SGBDR. Pour chaque entrée, il y aura un ou plusieurs
attributs analogues aux colonnes SGBDR. Si on veut rechercher dans LDAP certains attributs,
on peut le faire avec des filtres de recherche.
Dans notre exemple le filtre pour la vérification des utilisateurs est :
(&(uid=$username)(userPassword=$password))";

$ldapSearchFilter = "(&(uid=$username)(userPassword=$password))";

IV.3. Contournement de la connexion par injection

Dans le code, l’application ne valide pas et ne nettoie pas correctement les entrées utilisateur.
Dans ce cas, un attaquant pourrait entrer une requête malveillante dans le formulaire de
connexion (ou tout autre champ de saisie) qui serait envoyée au serveur LDAP. Par exemple,
un attaquant pourrait entrer une requête qui lui permettrait de s’authentifier sans problème et
accéder à des informations sensibles ou potentiellement de prendre le contrôle du serveur.

Liste de quelques codes d’injection LDAP

uid=*
userPassword=*
➔ (&(uid =*)( userPassword =*))

uid =*)(&
userPassword =*)(&

24
 ➔(&(uid=*)(&)( userPassword =*)(&))

user=*)(|(&
userPassword =pwd)
➔(&(uid=*)(|(&)( userPassword=pwd))

uid =*)(|( userPassword=*

userPassword=test)
➔(&(uid=*)(|( userPassword =*)( userPassword =test))

uid = mbaye)(!(&(|
userPassword = any))
➔ (&(uid = mbaye)(!(& (|) (userPassword =any))))

uid =*
userPassword =*)(&
➔ (&(uid=*)( userPassword=*)(&))

Test d’authentification

25
Tous ces codes ci-dessus confirme que l’application est vulnérable aux injections ldap.
IV.4. Correctif
Pour éviter les effets néfastes du code malveillant comme illustré ci-dessus, nous devons
nettoyer toutes les entrées utilisateur pour nous assurer que la chaîne de filtre contient des
caractères valides.
Pour cela on utilise la fonction ldap_escape() qui est une fonction de PHP qui permet
d'échapper (ou d'éviter) l'utilisation incorrecte de caractères spéciaux dans des chaînes de
caractères avant de les utiliser dans des filtres LDAP ou des DN (Distinguished Name, Nom
Distingué). Cette fonction est utile pour éviter des erreurs potentielles lors de la construction
de filtres de recherche LDAP ou de noms distingués, en veillant à ce que les valeurs soient
correctement formatées et sécurisées.
//Filtre de recherche
//$ldapSearchFilter = "(&(uid=$username)(userPassword=$password))";

// Échapper les caractères spéciaux pour le filtre LDAP

$ldapSearchFilter = "(&(uid=" . ldap_escape($username, "", LDAP_ESCAPE_FILTER)
. ")(userPassword=" . ldap_escape($password, "", LDAP_ESCAPE_FILTER) . "))";

Repronnons les tests

26
On voit qu’il plus possible d’injecter du code.
Les injections LDAP peuvent être complexes et dépendent souvent du contexte d'utilisation
des données dans les requêtes LDAP. Utiliser ldap_escape() vous aide à vous assurer que les
valeurs que vous insérez dans les filtres ou les DNs sont correctement échappées pour éviter
des erreurs potentielles. Cela peut également contribuer à prévenir les attaques d'injection
LDAP basées sur des caractères spéciaux qui pourraient être mal interprétés par le serveur
LDAP.
Cependant, pour une protection complète contre les injections LDAP, il est essentiel de suivre
les meilleures pratiques de sécurité.

Conclusion
Les injections SQL/LDAP sont des menaces très sérieuses pour la sécurité des applications
web. Les attaquants exploitent ces vulnérabilités en insérant des instructions SQL/LDAP
malveillantes dans les données d'entrée de l'application. Cela peut entraîner la divulgation de
données sensibles, la manipulation de la base de données, voire la prise de contrôle complète
du système.
Pour prévenir les injections, les développeurs doivent adopter des bonnes pratiques de
sécurité, notamment l'utilisation de requêtes préparées et la validation rigoureuse des données
entrantes.

27