Les pirates peuvent-ils prendre le contrôle d'un site Web entier avec seulement quelques éléments de code ? Une injection SQL peut permettre à un pirate de saccager votre base de données et de tout voler, des informations d'identification administratives aux détails de cartes clients.
Même si votre site ou votre application ne présente que quelques points faibles dans sa programmation, un pirate pourrait en extraire toutes sortes d'informations que vous n'auriez jamais voulu rendre publiques.
Qu'est-ce que l'injection SQL et comment pouvez-vous l'empêcher ?
Qu'est-ce que le SQL ?
SQL est un langage de codage utilisé principalement pour récupérer des informations depuis des bases de données en ligne. Il est facile à utiliser, car il est intuitif et intègre des mots anglais de base sous forme de commandes.
Par exemple, imaginez qu'un client achète en ligne et saisisse le mot « chaussures » dans la barre de recherche d'une boutique. Lorsqu'il lance la fonction de recherche, un processus simple commence en arrière-plan.
Le site Web utilisera un système de gestion de base de données (SGBD) qui, à son tour, exécutera une certaine forme de SQL. Lorsque le client recherche « chaussures », une chaîne de code mobilisant ce langage est créée. C'est la requête SQL.
Cette requête contiendra certaines spécifications, telles que l'endroit où chercher et ce qu'il faut récupérer. En voici un exemple :
SELECT name, description FROM products WHERE category = “shoes”Lorsque cette requête atteint la base de données, le système SGBD lit la requête SQL et sait qu'il faut la consulter dans le tableau « produits ». Il peut ensuite récupérer les noms et les descriptions des éléments de la catégorie « chaussures » et renvoyer ces données au client. S'il trouve dix éléments, il enverra dix noms et descriptions.
Il s’agit d’une opération simple. C'est là que les ennuis commencent.
Qu'est-ce que l'injection SQL
Pour effectuer une injection, un pirate essaiera de glisser du codage supplémentaire dans la chaîne SQL. C'est l'injection.
Cela ne fonctionne pas toujours, bien sûr. Le SGBD du site lit certains caractères comme des commandes de codage (SÉLECTIONNER, par exemple) et d'autres comme des mots et des caractères normaux (« chaussures » dans ce cas particulier).
Si un site a été correctement programmé, la recherche d'une commande de codage n'entraînera pas d'injection. Au lieu de cela, le système lira la commande comme un ensemble de caractères qu'il ne reconnaît pas et renverra un message du type « aucun élément trouvé ».
Cependant, si le système n’a pas été sécurisé, il lira les caractères injectés comme une véritable commande SQL. C’est là que les choses peuvent mal tourner.
Au lieu d'utiliser le mot-clé « chaussures », le pirate pourrait rechercher des commandes SQL spécifiques. Lorsque la chaîne est formée et envoyée à la base de données, le SGBD lit le mot-clé recherché sous forme de commande et l'exécute en conséquence.
Les dommages
En utilisant une technique appelée injection SQL aveugle, un pirate peut rapidement déterminer exactement quel SGBD est exploité en arrière-plan. Sachant cela, il sera en mesure de commencer à utiliser le langage SQL approprié.
S'il recherche les bons termes de codage, il peut obliger le SGBD à renvoyer une liste complète de toutes les différentes tables de données qu'il contient. Armé de ces informations, il peut accéder à chaque table et extraire les informations qu'il souhaite. S'il trouve une table « utilisateur », il peut causer de sérieux dommages.
UNION est une commande de codage qui permet d'ajouter une requête supplémentaire à sa requête principale. Les résultats de cette sous-requête s'afficheront sous les résultats de la requête principale.
Un pirate pourrait écrire quelque chose comme ceci dans la barre de recherche :
“shoes” UNION (SELECT username, password FROM users);--"En arrière-plan, une chaîne SQL serait générée et pourrait ressembler à ceci :
SELECT name, description FROM products WHERE category = “shoes” UNION (SELECT username, password FROM users);--Désormais, en plus de récupérer les résultats du mot-clé « chaussures », le pirate pourra également afficher tous les noms d'utilisateur et mots de passe du tableau « utilisateurs ».
Les mots de passe seront probablement hachés, mais il ne faudra pas longtemps à un pirate pour les déchiffrer. S'il peut déterminer quels noms d'utilisateur appartiennent aux administrateurs, il peut utiliser un logiciel de forçage brut pour pénétrer rapidement dans le compte concerné et obtenir un accès administrateur à l'ensemble de l'application.
Les types d’injections SQL
Pour vous aider à renforcer vos défenses, nous penchons-nous sur les différents types d’attaques par injection SQL pour mieux comprendre l’environnement de cette cybermenace.
1. Injection SQL classique
L’injection SQL classique, également connue sous le nom d’injection SQL in-band, est la forme la plus répandue de cette cyberattaque. En glissant un code SQL malveillant dans les champs de saisie de l’utilisateur, les pirates obtiennent un accès non autorisé pour manipuler, supprimer ou même exécuter des commandes administratives sur la base de données concernée. Il est essentiel d’être conscient de cette menace courante et de prendre des mesures pour la prévenir.
2. Injection SQL à l’aveugle
Les attaques par injection SQL à l’aveugle, comme leur nom l’indique, obligent les attaquants à travailler à l’aveugle, sans avoir le luxe d’accéder directement à la sortie de la base de données. Dans la plupart des cas, les attaquants qui se livrent à une attaque SQL à l’aveugle s’appuient sur une série de requêtes vraies et fausses pour recueillir des informations. Ce mode de fonctionnement permet aux pirates de déduire le schéma et le contenu de la base de données, pièce par pièce.
3. Injection SQL error-based (basée sur les erreurs)
Les injections SQL error-based exploitent les messages d’erreur de la base de données pour révéler des données sensibles. Les auteurs de ces attaques soumettent intentionnellement des requêtes SQL mal formées, ce qui amène la base de données à générer des messages d’erreur contenant des informations précieuses. En analysant de près ces messages, les cyber-escrocs peuvent en apprendre davantage sur le fonctionnement interne du système et identifier ses points faibles potentiels.
4. Injection SQL temporisée
Les injections SQL temporisées, ou time-based, sont un type plus spécifique d'attaque par injection SQL à l’aveugle. Les attaquants qui se livrent à des attaques SQL temporisées se concentrent sur le temps de réponse de la base de données pour en déduire des informations. En soumettant des requêtes SQL qui entraînent des retards dans la réponse, ils peuvent découvrir des détails spécifiques sur la base de données en se basant sur le temps nécessaire pour recevoir une réponse.
5. Injection SQL out-of-band
Les attaques par injection SQL out-of-band utilisent un canal de communication distinct pour envoyer et recevoir des données, plutôt que le canal direct entre l’application et la base de données. Cette méthode d’attaque moins courante, mais très efficace, permet aux attaquants de contourner certaines mesures de sécurité, telles que les pare-feu et les systèmes de détection d’intrusion, afin d’atteindre leurs objectifs malveillants.
Quels sont les risques liés à une injection SQL ?
Les attaques par injection SQL représentent un bon nombre de menaces de sécurité pour l'organisation touchée. Une fois que les cybercriminels ont réussi à exploiter une vulnérabilité d'injection SQL, ils peuvent :
- Ajouter, supprimer ou modifier le contenu de la base de données.
- Écrire de nouveaux fichiers dans la base de données.
- Lire le code source du serveur de base de données.
De telles capacités d'accès peuvent même conduire à une prise de contrôle complète des bases de données et du serveur Web, ce qui, comme vous pouvez l'imaginer, peut être désastreux.
Comment éviter l'injection SQL ?
Une injection SQL réussie peut entraîner des problèmes colossaux. Un pirate peut voler des mots de passe et des informations de paiement, divulguer les détails de l'utilisateur en ligne et supprimer des données essentielles. Un événement comme celui-ci peut détruire de manière irréversible la confiance des consommateurs. Comment éviter que de telles choses se produisent ?
Validation des entrées
Si vous intégrez un processus de validation des entrées dans le codage du backend de votre site, cela peut contribuer grandement à réduire la menace. Vous pouvez par exemple créer une liste de caractères acceptés et programmer le SGBD pour qu’il reconnaisse un mot-clé qui ne figure pas dans la liste. Si un pirate « recherche » une commande de codage, votre système la compare à la liste des autorisations. S’il n’obtient pas de correspondance, il n’exécute pas le code.
Requêtes préparées
La création de requêtes préparées est probablement la meilleure stratégie. Un site vulnérable crée une nouvelle chaîne SQL chaque fois que le pirate effectue une recherche, mais avec une requête préparée, ce n'est pas le cas. Lors de la programmation du backend de votre site, créez vos modèles SQL à l'avance, avec un point d'interrogation à la place du mot-clé. Le SGBD peut être programmé pour lire ce point d'interrogation comme n'importe quelle donnée dans la barre de recherche, mais la requête elle-même est faite à l'avance. Cela réduit considérablement le risque qu'une commande SQL malveillante atteigne la base de données.
Séparation des données
Plus vos données sont séparées, moins un pirate informatique peut s’en emparer en une seule attaque. Dans l’exemple de la boutique en ligne dont nous avons parlé plus haut, le problème de la faiblesse du langage SQL est aggravé par le fait que les données des utilisateurs sont conservées dans la même base de données que les listes de produits de base. La séparation des différents types d’informations dans des bases de données et des serveurs distincts limite l’ampleur des dégâts produits par une attaque SQL.
Utiliser les dernières technologies
Veillez à utiliser la dernière version des outils de développement pour garantir une sécurité maximale. Les anciennes technologies de développement web peuvent manquer de protection SQL ou présenter des vulnérabilités potentielles que des acteurs malveillants peuvent exploiter. Veillez à mettre à jour les composants logiciels que vous êtes susceptible d’utiliser pour le développement, car les mises à jour sont conçues pour corriger les bugs et les problèmes de sécurité potentiels.