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.
