Elle survient lorsqu'une application construit des instructions de base de données en combinant le texte de la commande avec des valeurs influencées par l'attaquant sans préserver une frontière fiable entre code et données. Une attaque réussie peut lire ou modifier des données, contourner des contrôles applicatifs ou invoquer des capacités de la base de données disponibles au compte de l'application.
La défense principale est de garder la structure de la requête fixe et de passer les valeurs via des interfaces paramétrées. La validation des entrées peut imposer les attentes métier, mais ne remplace pas la paramétrisation ; les permissions de la base de données doivent aussi limiter les conséquences si un autre contrôle échoue.
Points clés
Construction sûre des requêtesUtiliser des instructions préparées ou des interfaces de base de données correctement paramétrées sur chaque chemin d'accès aux données, y compris tâches de fond, fonctionnalités d'administration, données importées et entrées indirectes.
Éléments de requête dynamiquesLes paramètres ne peuvent souvent pas représenter noms de table, noms de colonne ou sens de tri. Mapper ces choix à une liste d'autorisation fixe ou reconcevoir la requête plutôt que d'insérer du texte non fiable.
Réduction des conséquencesDonner aux identités applicatives seulement les privilèges de base de données nécessaires, séparer les rôles lorsque c'est pratique, protéger les identifiants de connexion, éviter les capacités de base de données inutiles et superviser le comportement de requêtes anormal.
Limite importanteL'échappement, les procédures stockées, le mapping objet-relationnel, la validation des entrées ou un pare-feu d'applications web n'empêchent pas automatiquement l'injection SQL ; la sûreté dépend de la façon dont chaque requête est finalement construite et exécutée.