Utilisez des déclarations préparées avec des requêtes paramétrées
Cette méthode d’assainissement des entrées de la base de données oblige les développeurs à définir d’abord tout le code SQL, puis à ne passer que des paramètres spécifiques à la requête SQL : les données saisies ont explicitement une portée limitée qu’elles ne peuvent pas dépasser. Cela permet à la base de données de faire la distinction entre les données qui sont saisies et le code qui doit être exécuté, quel que soit le type de données fournies dans le champ de saisie. Certaines bibliothèques de mappage objet-relationnel sont couramment utilisées à cette fin car certaines versions nettoient automatiquement les entrées de la base de données.
Échappez à toutes les entrées fournies par l’utilisateur
Lors de l’écriture du langage SQL, certains caractères ou mots ont une signification particulière. Par exemple, le caractère « * » signifie « tout ». Pour éviter que les utilisateurs ne saisissent ces caractères par accident ou par malveillance dans une demande d’API adressée à la base de données, les données fournies par l’utilisateur peuvent être échappées. L’échappement d’un caractère est un moyen d’indiquer à la base de données de ne pas l’analyser comme une commande ou une condition mais de le traiter comme une entrée littérale.
Utilisez des procédures stockées
Bien qu’il ne s’agisse pas d’une stratégie de sécurité solide en soi, les procédures stockées peuvent contribuer à limiter le risque associé à l’injection SQL. En limitant correctement les autorisations du compte de la base de données qui exécute les requêtes SQL, même le code d’application non robuste qui est vulnérable à l’injection SQL n’aura pas les autorisations nécessaires pour manipuler des tables de base de données non liées. Les procédures stockées peuvent également vérifier le type des paramètres d’entrée, empêchant ainsi la saisie de données qui ne correspondent pas au type que le champ est censé recevoir. Dans les cas où les requêtes statiques sont insuffisantes, les procédures stockées sont généralement à éviter.
Appliquez le principe du moindre privilège
En règle générale, dans tous les cas où un site Web doit utiliser du SQL dynamique, il est important de réduire l’exposition à l’injection SQL en limitant les autorisations à la portée la plus étroite possible pour exécuter la requête concernée. Dans sa forme la plus évidente, cela signifie qu’un compte administratif ne devrait en aucun cas exécuter des commandes SQL à la suite d’un appel API provenant d’une requête non autorisée. Si les procédures stockées sont mieux utilisées pour les requêtes statiques, l’application du principe du moindre privilège peut contribuer à réduire les risques des requêtes SQL dynamiques.
Au-delà de toutes ces recommandations, vous pouvez utiliser des outils pour vous protéger. Souvent développés par des sociétés spécialisées comme Cloud Protector, ces outils vous seront très utiles pour déceler les attaques avant qu’elles ne vous impactent. Pour découvrir un aperçu de ces outils, vous pouvez naviguer sur le net ou bien vous rendre sur les pages dédiées des entreprises professionnelles du secteur.
