[Admin Shiloh @shiloh Maître des clés]

Mini‑cours : Comprendre et se protéger des injections (SQL, OS, LDAP…)

Les injections figurent parmi les vulnérabilités les plus dangereuses du paysage numérique actuel.
Classées en tête du OWASP Top 10, elles permettent à un attaquant d’injecter du code
malveillant dans une requête destinée à un interpréteur (SQL, OS, LDAP, XML, etc.).
Cela peut compromettre la confidentialité, l’intégrité ou la disponibilité des données.

🔍 Qu’est-ce qu’une injection ?

Une injection survient lorsqu’une application accepte des données non fiables comme des commandes à exécuter.
Ces données peuvent être insérées dans :

• Des requêtes SQL (SQL Injection)
• Des commandes système (Command Injection)
• Des requêtes LDAP, XPath ou XML (XXE)
• Des scripts (XSS, bien que souvent traité séparément)

L’injection est rendue possible par le manque de validation des entrées utilisateur,
associé à une concaténation directe dans la logique applicative.

💥 Exemple d’injection SQL

Considérons une requête SQL naïve :

SELECT * FROM users WHERE username = '$user' AND password = '$pass';

Un utilisateur malveillant peut entrer :

user = admin' --

Ce qui donne la requête :

SELECT * FROM users WHERE username = 'admin' --' AND password = '';

Le commentaire SQL (--) ignore tout ce qui suit, contournant ainsi l’authentification.
L’attaquant est désormais connecté en tant qu’admin !

⚠️ Autres types d’injection

Type	Description	Conséquence possible
SQL Injection	Manipule les requêtes aux bases de données	Fuite de données, modification ou suppression de données
Command Injection	Injection de commandes dans le système d’exploitation	Exécution de commandes arbitraires sur le serveur
LDAP Injection	Manipule les requêtes d’annuaire	Contournement d’authentification ou modification de comptes
XML Injection	Modification des structures XML ou appels externes	Exfiltration de données via XXE

🛡️ Comment s’en protéger efficacement ?

• ✅ Utiliser des requêtes préparées (paramétrées)
  Elles empêchent toute interprétation directe des données utilisateur :

// Exemple en PHP avec PDO
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :user AND password = :pass");
$stmt->execute(['user' => $user, 'pass' => $pass]);

• ✅ Valider et filtrer les entrées utilisateur
  Ne jamais faire confiance aux données envoyées par le client.
• ✅ Échapper correctement les caractères spéciaux
  Quand une requête dynamique est inévitable, échapper les entrées selon le contexte (SQL, shell, XML…)
• ✅ Appliquer le principe du moindre privilège
  Le compte utilisé par l’application pour accéder à la base ne doit jamais avoir de droits d’administration.
• ✅ Surveiller les journaux
  Mettre en place une détection d’anomalies dans les logs pour identifier des patterns suspects.
• ✅ Utiliser un pare-feu applicatif (WAF)
  Il peut bloquer des requêtes suspectes avant qu’elles n’atteignent l’application.

🧩 Cas pratique à tester

Créez une page de connexion simple en PHP sans protections.
Puis, essayez d’entrer : ' OR '1'='1 comme identifiant.

Ensuite, corrigez votre code en utilisant des requêtes préparées avec PDO ou MySQLi.
Vous constaterez que l’injection ne fonctionne plus 💪.

📌 Conclusion

Les injections représentent un danger critique dans toute application connectée à une base de données
ou un service d’interprétation. En tant que développeur ou administrateur, vous devez adopter une approche
“zero trust” pour les entrées utilisateurs. Les requêtes préparées, les validations et une bonne hygiène de code
sont vos meilleures défenses.

✅ À retenir : Une seule entrée non filtrée peut suffire à compromettre tout un système.

[Auteur]

Messages