Injection SQL
Une attaque qui glisse des instructions de base de données dans un champ de saisie pour lire, modifier ou effacer des données du site.
Définition
Une injection SQL est une attaque qui glisse des instructions de base de données dans un champ de saisie pour lire, modifier ou effacer des données du site. Elle ne vise pas WordPress en général, mais le code qui transmet une saisie à la base sans la contrôler.
Comment fonctionne une injection SQL ?
En faisant passer une commande pour une simple valeur.
Toutes les données d’un site WordPress vivent dans une base : les pages, les comptes, les commandes, les réglages. Pour les lire, le site envoie des requêtes écrites dans un langage appelé SQL. Quand un visiteur fait une recherche, sa saisie devient un morceau de cette requête.
Si le code colle la saisie telle quelle dans la requête, un attaquant peut écrire autre chose qu’un mot à chercher. Il ajoute des instructions, et la base les exécute comme si elles venaient du site lui-même. Il peut alors afficher des données qu’il n’aurait jamais dû voir, comme la liste des comptes, en modifier ou en supprimer.
Un exemple simple en donne le principe. Une requête demande à la base les articles dont le titre contient le mot saisi. Si l’attaquant saisit, à la place d’un mot, un fragment qui modifie la condition de la requête, la base ne cherche plus un titre : elle renvoie toutes les lignes de la table, ou celles d’une autre table. La vulnérabilité n’est pas dans la base de données, elle est dans l’application web qui a construit la requête sans séparer le texte saisi des instructions.
Qu’est-ce qu’une injection SQL met en danger ?
Tout ce que la base contient, et parfois le site entier.
| Ce que vise l’attaquant | Ce que cela signifie pour l’entreprise |
|---|---|
| Lire les comptes utilisateurs | des identifiants à changer, et des clients à prévenir si leurs données sont concernées |
| Créer un compte administrateur | une prise de contrôle complète du site, sans mot de passe à deviner |
| Modifier le contenu | des liens ou des pages injectés, souvent invisibles pour le propriétaire |
| Effacer des données | une restauration de sauvegarde, avec la perte de tout ce qui a changé depuis |
Quand la base contient des données de clients, une fuite n’est plus seulement un problème technique. Elle engage des obligations vis-à-vis des personnes concernées, qui se vérifient auprès de la CNIL.
Pourquoi les extensions sont-elles en première ligne ?
Parce que le cœur prépare ses requêtes, et que chaque extension écrit les siennes.
WordPress fournit aux développeurs un outil fait pour cela : la préparation des requêtes. La saisie y est traitée comme une valeur, jamais comme une instruction, quelle que soit la façon dont elle est écrite. Le cœur de WordPress l’utilise, et la documentation officielle impose de l’utiliser.
La même documentation demande de valider chaque entrée utilisateur, c’est-à-dire de vérifier qu’un paramètre attendu comme un nombre est bien un nombre, puis d’échapper ce qui sera affiché. Ces règles s’appliquent à toute donnée qui vient de l’extérieur : un champ de formulaire, un paramètre d’adresse, un cookie.
Le risque vient des extensions qui s’en passent. Chacune écrit ses propres requêtes, et une seule écrite trop vite suffit à ouvrir la base. C’est pourquoi les failles d’injection publiées concernent presque toujours une extension précise, dans une version précise, corrigée dans la suivante.
La protection la plus efficace n’est pas technique. Tenir les extensions à jour ferme les failles déjà connues, et en réduire le nombre réduit le code qui peut en contenir. Une extension abandonnée par son auteur ne sera jamais corrigée, même quand sa faille est publiée.
Comment protéger un site WordPress ?
Quatre gestes, dans cet ordre de priorité.
Mettre à jour
Appliquer les mises à jour de sécurité des extensions dès leur publication. Une faille corrigée n’est dangereuse que pour les sites qui ne l’ont pas encore installée.
Réduire
Supprimer les extensions inutilisées et remplacer celles qui ne sont plus maintenues. Une extension désactivée reste présente sur le serveur.
Masquer les erreurs
Un site en production n’affiche jamais les messages d’erreur de la base à ses visiteurs. Ces messages renseignent un attaquant sur la structure des tables et facilitent l’exploitation d’une faille.
Filtrer
Un pare-feu applicatif bloque une partie des tentatives connues avant qu’elles n’atteignent le site. Il complète les gestes précédents, il ne les remplace pas.
Questions fréquentes
WordPress est-il vulnérable aux injections SQL ?
Le cœur de WordPress prépare ses requêtes et n’est pas la cible habituelle. Les failles publiées portent presque toujours sur une extension ou un thème, dans une version donnée.
Comment savoir si mon site a été touché ?
Les signes sont indirects : un compte administrateur inconnu, du contenu modifié sans intervention, un avertissement de Google. Les journaux du serveur permettent ensuite de retrouver la requête en cause.
Un pare-feu suffit-il à s’en protéger ?
Non. Il arrête une partie des tentatives connues, mais la seule protection durable est une extension dont le code prépare ses requêtes, et qui est tenue à jour.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.