Comment protéger son site WordPress d’une attaque par injections SQL ?

SQL (Structured Query Language) est un langage utilisé en programmation afin de communiquer avec les bases de données relationnelles. Les bases de données stockent les données des applications web et les livrent aux utilisateurs lorsque celles-ci sont demandées. 😇Habituellement cette interaction nécessite l’utilisation de requêtes SQL envoyées à la base de données, laquelle retourne une réponse relative.⏮️

Les injections SQL sont une forme de cyberattaque qui exploite les failles de sécurité d’un système de gestion de bases de données. L’objectif est d’exécuter des requêtes SQL malveillantes dans la base de données. Mais, comment fonctionne une attaque par injection SQL ? Quelles sont les différentes formes d’injection SQL et comment prévenir ces attaques ? Lisez cet article pour avoir toutes les réponses à ces questions ?

Objectif

Cet article vous explique les attaques par injection SQL et leur fonctionnement. Vous allez ensuite trouver différents moyens pour lutter contre cette forme de piratage et protéger votre site WordPress.🔒

Qu’est-ce que l’injection SQL ?

Une injection SQL est une attaque qui consiste à envoyer des requêtes SQL malveillantes dans votre base de données. Les buts derrière cette cyberattaque varient énormément. De même, la manière de procéder dépend de ce que veut faire l’attaquant dans votre base de données. Les pirates déclenchent cette cyberattaque lorsque des failles de sécurité s’installent dans votre système de gestion de base de données.

Le hacker peut soit voler des données sensibles pour en faire une utilisation illicite, modifier du contenu ou supprimer des données sur votre serveur. Il peut modifier les droits d’accès ou exfiltrer de données vers un autre emplacement. Il peut également envoyer des commandes et arrêter le fonctionnement de votre système de gestion de base de données (SGBD).

L’injection SQL ou encore la faille SQLi a été découverte en 1998. Elle constitue toujours une des attaques les plus fréquentes contre les sites internet, selon les rapports de la fondation OWASP. Il a été constaté que cette cyberattaque est plus courante sur les applications PHP et ASP en raison d’une utilisation remarquable et persistante d’interfaces fonctionnelles anciennes. Alors qu’elles sont moins susceptibles de survenir sur les applications J2EE et ASP.NET.

La gravité de l’attaque dépendra en pratique des compétences du pirate. Mais quelle que soit sa nature, l’attaque par injection SQL demeure un geste non anodin pour votre entreprise. Vous devez toujours la remédier lorsque vous êtes affecté, car à l’évolution, elle peut constituer un véritable goulot d’étranglement.

Comment fonctionne une attaque par injections SQL ?

Une injection SQL peut aller du simple au complexe. Cependant, le point de départ reste identique et c’est notamment quand les failles de sécurité s’installent dans votre système que cette attaque peut être lancée. Pour tenter de lancer une action invasive à votre base de données, les hackers peuvent utiliser un formulaire de connexion, de contact ou encore un formulaire d’abonnement.

Ces moyens permettent aux pirates d’identifier les vulnérabilités de votre système afin de lancer leurs attaques. Pour rendre les choses un peu faciles à comprendre, nous y allons par un exemple.

Vous souhaitez accéder à votre base de données pour y insérer des données. Vous utiliserez ainsi un formulaire de connexion. Celui-ci possède habituellement deux champs :

• Nom d’utilisateur
• Mot de passe

Lorsque vous soumettez ces informations, le système de gestion de votre base de données va analyser ces entrées et les authentifier afin de valider votre connexion. Tout ce que peut faire un pirate est de contourner cette analyse par des techniques que vous allez apprendre dans la suite de cet article.

En pratique, votre base de données s’attend à une requête dont le contenu peut ressembler à ceci :

select * from user_table 
where username = 'carter' 
and password = 'fgmkpass';

Dans un temps normal (lorsque votre SGDB est sécurisé) :

• Si les données saisies sont correctes, votre accès sera authentifié
• Si les données sont incorrectes, vous ne pouvez pas accéder à votre base de données.

À l’inverse, un attaquant va procéder en utilisant la même structure de la requête tout en y insérant des morceaux de codes non prévus pour bloquer l’analyse complète et l’authentification.

Vous le savez peut-être, dans le langage SQL, les apostrophes sont utilisées pour fermer les chaînes de requêtes. Tout ce qui est donc inséré entre les apostrophes est considéré comme du SQL par votre système.

Et pourtant, dans le même langage, la présence d’un double tiret « – – » est considéré comme le début d’un commentaire. De ce fait, tout le code, écrit après, n’est pas à interpréter, y compris le mot de passe. Pour notre exemple, voici ce que le pirate peut envoyer comme requête malveillante :

select * from user_table 
where username = 'carter';--' 
and password = 'gnexpass'

L’ordre de lignes de codes n’est pas un problème. Mais comme les tirets (–) indiquent le début d’un commentaire, votre système va simplement ignorer la partie insérée après. Donc, le mot de passe ne sera pas analysé (même s’il est faux) et l’attaquant peut ainsi avoir accès à toute votre base de données.

De la même manière, les attaquants peuvent utiliser la séquence « or » pour forcer un accès administrateur à votre base de données. Dans la pratique, deux apostrophes seront utilisées pour contourner l’analyse du système. La première permet de fermer la chaîne de requêtes et insérer « or ». La deuxième permet d’insérer une logique booléenne. Dans notre exemple, la requête aura une structure similaire à la suivante :

select * from user_table 
where username = 'carter' 
and password = 'fjmkpass' or 1=1;--';

Et comme toujours 1 = 1, en dépit du mot de passe qui est erroné, l’attaquant aura un accès de niveau administrateur. Nous vous le rappelons, cela peut être facile à faire si vous avez des failles de sécurité au niveau de votre système. Une fois qu’il a cet accès, il peut inévitablement tout faire dans votre base de données.

Quels sont les types d’injections SQL ?

Il existe plusieurs types d’injections SQL. Nous allons détailler les attaques les plus courantes dans cette partie.

1. Injections basées sur les erreurs

C’est une forme d’attaque au cours de laquelle, un hacker cherche à obtenir plus d’informations sur une base de données après validation d’une requête malveillante. Habituellement, lorsque les requêtes erronées sont envoyées à la base de données, cette dernière renvoie, en plus de l’erreur, certaines informations sur la configuration du serveur.

L’attaquant peut ainsi disposer d’informations nécessaires pour exécuter ses prochaines attaques.

2. Injections par union SQL

Elles sont utilisées pour extraire un nombre important de données au niveau du système. L’attaquant se sert ainsi de l’instruction SQL qui permet d’interroger une autre table en dehors de celui qui est interrogé initialement avec l’instruction select.

Par exemple, au lieu de se limiter sur les tables users and accounts, l’attaquant peut en plus interroger le nom de la base (database) et les noms des autres tables (table_name). Pour ce faire, les pirates joignent plusieurs résultats de multiples instructions select. Cette forme de concaténation leur donne aussi l’opportunité d’en savoir plus sur le type et les noms de colonnes de tables…

3. Injections stacked queries

Cette attaque est réputée la plus dangereuse de toutes, d’autant plus qu’au cours cette dernière, l’attaquant peut exécuter n’importe quel type de requête SQL. Il peut non seulement lire les données de la base de données, mais aussi en faire une suppression. Les systèmes cibles sont ceux ayant une mauvaise configuration du serveur.

La manœuvre consiste à remplacer une requête initiale par une sous-requête par empilement. Il peut ensuite, exécuter n’importe quelle requête SQL.

4. Injections SQL aveugles

Elles consistent à détecter le niveau de vulnérabilité d’un système en envoyant beaucoup de requêtes puis faire l’analyse de réponses. Ici l’action consiste premièrement à examiner les parties vulnérables d’un système en se servant d’une logique booléenne.

Deux closes booléennes sont habituellement utilisées : « … and 1=1 » et « … and 1=2 ».

Si la première permet d’obtenir des résultats valides alors que dans la deuxième, cela n’est pas le cas, votre système est vulnérable aux attaques.

Alternativement, les injections SQL aveugles peuvent être basées sur le temps. Dans ce contexte, un attaquant utilise une fonction temporelle qu’il associe à une requête SQL afin de contrôler la durée d’exécution d’un code. Dans le système de gestion de base de données tel que MySQL, cette fonction est représentée par la commande sleep().

Dans l’éventualité où votre système obéit à cette commande, cela est un signal qu’il peut être facilement attaqué.

5. Injection SQL Out-of-Band

Un attaquant peut également se servir de la capacité de votre serveur à traiter les données externes afin d’exécuter ses requêtes malveillantes. La manœuvre consiste ici à envoyer vos données à un endroit externe dans le but d’en faire ultérieurement un usage malicieux.

Dans ce contexte, il peut par exemple utiliser la fonction OUTFILE pour faire le transfert de données sur les systèmes classiques, notamment MySQL. Si l’attaquant recherche des données spécifiques, il peut simplement utiliser la fonction LOAD_FILE() pour lire les données avant de les transférer.

6. Injection SQL par XPath

Cette autre attaque par injection SQL procède par la manipulation d’élément XML afin d’obtenir des données au niveau du système. Habituellement, dans le langage SQL, les requêtes XPath définissent la partie de la réponse XML qui vous intéresse dans un système.

C’est généralement des valeurs contenues dans l’un des nœuds XML. Ces valeurs ainsi extraites sont analysées ou stockées pour un usage ultérieur. Dans une injection SQL XPath, tout le problème vient du fait que XPath n’est pas soumis à un contrôle d’accès en plus d’être un processus automatisé. Dans ce contexte, des chaînes XPath normales sont associées à des données non sécurisées et sont envoyées dans la base de données.

Et c’est l’attaquant qui détermine la méthode de structuration de données XML envoyées. Ce qui, à l’occasion lui donne un accès non autorisé à des données supplémentaires.

Comment détecter les attaques par injections SQL ?

Savoir détecter les attaques par injection SQL est très important lorsque vous gérez un site web ou des bases de données d’une entreprise. En ligne, vous avez plusieurs outils pour détecter les injections SQL.

La plupart de ces logiciels possèdent une version gratuite. Ce qui peut être largement suffisant pour vous donner assez une tonne d’information sur l’état de votre système. Il s’agit notamment de suIP.biz qui prend en charge la majorité de base de données classiques (MySQL, Oracle, Sybase, Microsoft SQL…). Vous avez également d’autres solutions de test telles que : invicti, Vega, Acunetix.

Si vous êtes sur WordPress, deux outils peuvent vous aider à scanner votre site pour trouver les points de vulnérabilité. Ce sont notamment WPScan ou encore ThreatPass.

Ces différents scanners de sécurité nécessitent tout de même des connaissances techniques minimums pour vous lancer.

Comment se protéger des injections SQL dans WordPress ?

WordPress est de base sécurisé contre la plupart d’attaque par injections SQL. Cependant, cela n’est pas le cas pour toutes les extensions et les thèmes que vous allez installer. Comme vous les savez, ce sont ces modules qui étendent les fonctionnalités de ce logiciel open source.

Donc, la meilleure chose à faire n’est pas de désinstaller ces modules mais d’avoir une bonne politique d’utilisation. Nous allons vous donner dans cette partie, les différentes façons de protéger votre site WordPress contre les attaques par injections SQL.

1. Bloquer les mots-clés SQL utilisés pour les attaques

Un certain nombre de mots-clés est utilisé par les hackers pour exécuter des attaques SQL malveillantes. Ainsi, en les bloquant, vous pouvez limiter des éventuelles attaques lorsque ces mots-clés sont utilisés. Cette solution n’est valable que vous déployez votre site sur un serveur Apache.

Pour ce faire, ouvrez votre fichier .htaccess et insérez les lignes de codes ci-dessous :

RewriteCond %{QUERY_STRING} [^a-z](declare¦char¦set¦cast¦convert¦delete¦drop¦exec¦insert¦meta¦script¦select¦truncate¦update)[^a-z] [NC] 
RewriteRule (.*) - [F]

Ainsi, toute attaque par injection SQL incluant ces mots-clés redirigera l’attaquant vers une erreur 404 Forbidden. La mauvaise nouvelle avec cette mesure de sécurité est que le serveur Apache vous affichera la même erreur chaque fois que votre URL contient ces mots-clés concernés.

2. S’assurer d’une bonne configuration du serveur

L’environnement d’hébergement de votre site web peut jouer un rôle crucial dans la protection contre les injections SQL. Sur un serveur, WordPress est déployé avec des milliers de fichiers qui interagissent à des niveaux différents pour livrer le contenu.

Par exemple, WordPress communique du côté serveur par le biais du langage appelé PHP (Hypertext Preprocessor). Vous devez vous assurer que vous avez la dernière version de PHP.

PHP a également ses propres composantes dont la configuration ne doit permettre aucune faille de sécurité. Une mise à jour régulière de ces fichiers peut renforcer votre sécurité. Par ailleurs, lorsque vous communiquez avec votre base de données via PHP, vous devez toujours utiliser les fonctions normales et reconnues.

Ces dernières sont testées et déclarées sécurisées contre les attaques par injections SQL. L’utilisation de fonctions tierces et non testées aux vulnérabilités peut vous exposer aux attaques de toute sorte.

3. Utiliser des requêtes paramétrables

Les requêtes paramétrables ou préparées peuvent fortement vous aider à échapper aux attaques par injections SQL. Ce processus consiste à différer la séquence d’exécution de requêtes en deux temps : la préparation et l’exécution proprement dite.

Au cours de la préparation, l’utilisateur envoie un template de requêtes à la base de données. Il s’ensuit une analyse de la syntaxe et une initialisation de ressources internes pour une utilisation ultérieure.

Et puis vient l’exécution proprement dite. Le développeur lie, les valeurs de paramètres ensuite les envoie au serveur de la base de données. Le serveur crée une requête à partir du fichier template et fait appel aux ressources précédemment préparées pour exécuter enfin votre requête. Il sera ainsi difficile aux hackers de lire facilement vos requêtes et les utiliser à des fins malicieux.

4. Sécuriser WordPress avec la bonne configuration

Comme nous l’avons mentionné précédemment, la sécurisation de WordPress suppose aussi d’utiliser des modules à jour. L’application de base WordPress, est sécurisée contre ces erreurs courantes. Le logiciel est constamment mis à jour par ses développeurs. Et les rapports de bogues corrigés sont publiés sur le site de ce logiciel open source.

Donc, autant que vous les hackers peuvent lire ces informations de correction et vous attaquer si vous utilisez encore de logiciel ancien. Vous devez toujours mettre à jour WordPress lorsqu’une nouvelle version est publiée. Et surtout, gardez un œil sur vos extensions et votre thème. Mettez-les à jour dès que les nouvelles versions sont disponibles.

Conclusion

🥳Toutes nos félicitations d’avoir lu cet article. Les injections SQL sont une forme d’attaques courantes sur internet. Avoir des connaissances sur la façon de se protéger contre cette forme de piratage est toujours recommandé. Dans cet article, nous avons parlé d’une injection SQL, son fonctionnement et les moyens pour s’en protéger. Utilisez ces mesures de sécurité et protégez votre site WordPress dès aujourd’hui.

Si vous avez des questions ou des remarques, n’hésitez pas à utiliser la section commentaires pour nous contacter.