8. Se protéger : requêtes préparées, WAF et bonnes pratiques

Ce dernier chapitre fait la synthèse du cours en se concentrant exclusivement sur les protections concrètes à mettre en œuvre pour éliminer durablement les injections SQL, de la ligne de code jusqu’à l’infrastructure.

Les requêtes préparées : la protection de référence

La protection la plus robuste et la plus universellement recommandée consiste à utiliser des requêtes préparées (prepared statements) avec des paramètres liés. Contrairement à la concaténation, la structure de la requête est envoyée séparément des données, qui ne sont jamais interprétées comme du code SQL, quel que soit leur contenu.

Exemple avec PDO en PHP

$stmt = $pdo->prepare("SELECT * FROM utilisateurs WHERE login = :login AND mot_de_passe = :motdepasse");
$stmt->execute(array(':login' => $login, ':motdepasse' => $motdepasse));
$utilisateur = $stmt->fetch();

Même si la variable $login contient une apostrophe ou un mot-clé SQL, elle sera toujours traitée comme une simple valeur de comparaison, jamais comme une instruction exécutable. C’est cette séparation stricte entre code et donnée qui élimine la classe entière des injections SQL classiques, UNION et aveugles présentées dans ce cours.

La validation et l’échappement des entrées

Lorsqu’une requête préparée n’est pas applicable (par exemple pour un nom de colonne ou de table dynamique, que les requêtes préparées ne peuvent pas paramétrer), la validation stricte des entrées via une liste blanche de valeurs autorisées reste la meilleure alternative, bien plus fiable qu’une simple fonction d’échappement générique.

Le principe de moindre privilège

Le compte de base de données utilisé par une application ne devrait jamais disposer de droits supérieurs à ce qui est strictement nécessaire à son fonctionnement. Un compte applicatif sans droit de suppression de table, par exemple, limite considérablement l’impact d’une injection SQL qui parviendrait malgré tout à s’exécuter.

Les protections complémentaires côté infrastructure

• Déployer un pare-feu applicatif (WAF) pour détecter et bloquer les tentatives connues en amont de l’application
• Désactiver l’affichage des messages d’erreur détaillés de la base de données en production
• Maintenir à jour le moteur de base de données et le framework applicatif utilisés
• Mettre en place des tests de sécurité automatisés (SAST/DAST) dans le pipeline d’intégration continue

Mise en pratique : corriger une application vulnérable

Pour consolider les connaissances de ce cours, l’exercice recommandé consiste à installer une application volontairement vulnérable (type DVWA) en environnement isolé, reproduire les attaques classique, UNION et aveugle présentées dans les chapitres précédents, puis réécrire le code vulnérable en utilisant des requêtes préparées, et vérifier que les mêmes charges utiles échouent désormais systématiquement.