Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Les injections SQL : ce que c’est, comment savoir si vous êtes concerné

C’est la faille la plus fréquemment exploitée contre les boutiques en ligne, parce qu’elle touche directement la base de données : commandes, clients, mots de passe. Voici ce qu’elle est réellement, sans jargon inutile.

Décrire mon problème Discuter sur WhatsApp

Le principe, sans jargon

Un site e-commerce construit en permanence des requêtes vers sa base de données : afficher une fiche produit, valider une connexion, enregistrer une commande. Ces requêtes intègrent souvent une information saisie par le visiteur, comme un identifiant de produit dans l’adresse, un terme recherché ou un champ de formulaire.

Une injection SQL survient quand cette information n’est pas suffisamment filtrée avant d’être intégrée à la requête. Le contenu saisi ne reste alors plus une simple donnée : il peut modifier le sens de la requête elle-même, et faire dire à la base de données autre chose que ce qui était prévu par le développeur du site ou du module.

C’est pour cette raison que cette faille est prise très au sérieux : elle touche directement la base de données, c’est-à-dire les commandes, les fiches clients et, selon la configuration, les mots de passe stockés.

Trois failles réelles pour comprendre le mécanisme

CVE-2022-36408 (référencée aussi sous CVE-2022-31181), divulguée le 22 juillet 2022, concernait le cœur de PrestaShop des versions 1.6.0.10 à 1.7.8.6 incluses, et est corrigée depuis la 1.7.8.7. Elle ne s’exploitait qu’en la chaînant à une injection SQL présente ailleurs sur la boutique, dans le cœur ou dans un module : le module de liste de souhaits blockwishlist en versions 2.0.0 à 2.1.0 en fournissait une (CVE-2022-31101, corrigée en 2.1.1).

CVE-2024-36680 touchait pkfacebook, un module tiers premium d’intégration Facebook pour PrestaShop. Les analystes de TouchWeb l’ont identifiée le 3 mars 2024 : elle pouvait être exploitée par un simple visiteur non connecté, et a servi à déployer des « skimmers » de paiement, c’est-à-dire du code destiné à intercepter les données de carte bancaire saisies sur le site.

CVE-2024-27956 concernait l’extension WordPress « WordPress Automatic » de l’éditeur ValvePress, publiée le 21 mars 2024. L’injection se situait dans le processus d’authentification lui-même et a été exploitée activement dès sa divulgation pour prendre le contrôle de sites.

Comment savoir si vous êtes concerné

  1. Identifier votre version de cœur

    Sur PrestaShop, la version s’affiche dans le back-office. Une boutique restée sur une version antérieure à 1.7.8.7 sans avoir vérifié ses modules mérite un contrôle, en particulier si le module blockwishlist est installé.

  2. Vérifier les modules premium installés

    Les modules tiers, notamment ceux liés à des intégrations comme Facebook, doivent être vérifiés individuellement : leur version, leur éditeur, et si une faille connue les concerne, indépendamment de la version du cœur PrestaShop.

  3. Vérifier les extensions WordPress d’automatisation

    Si votre site WordPress utilise WordPress Automatic ou une extension similaire qui manipule le contenu automatiquement, vérifiez sa version auprès de l’éditeur avant de considérer le site comme à jour.

  4. Chercher les conséquences, pas seulement la cause

    Un compte administrateur inconnu, des commandes ou des comptes clients créés en série, ou des données de paiement suspectes peuvent être la conséquence visible d’une injection SQL déjà exploitée.

Pour aller plus loin

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Qu’avez-vous constaté ?
Quelle plateforme ?
Depuis quand le problème est-il constaté ? (facultatif)

Plus l’infection est ancienne, plus elle a pu se propager dans les fichiers et la base de données.

Disposez-vous d’une sauvegarde saine ?

Une sauvegarde antérieure à l’infection change complètement la méthode de remise en état.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Une injection SQL peut-elle exposer les mots de passe de mes clients ?
Oui si les mots de passe sont mal protégés dans la base, mais la plupart des CMS récents les stockent sous forme hachée, ce qui limite l’usage direct des données récupérées. Le risque reste réel pour les autres informations : commandes, adresses, données de paiement selon la configuration.
Comment savoir si mon site a déjà été touché par une de ces failles ?
Je vérifie les traces dans les journaux d’accès au serveur, la présence de comptes administrateur ou de commandes créés en dehors de toute activité normale, et je compare les versions installées aux failles publiquement connues.
Un module payant est-il plus sûr qu’un module gratuit ?
Pas automatiquement. CVE-2024-36680 concernait un module premium. Ce qui compte est la rapidité de correction de l’éditeur et la rapidité avec laquelle la mise à jour est appliquée sur votre boutique.
Faut-il un pare-feu applicatif pour se protéger de ce type de faille ?
Un pare-feu applicatif peut filtrer une partie des tentatives, mais il ne remplace jamais la mise à jour du code vulnérable lui-même : c’est une protection complémentaire, pas une solution en soi.
Que faire si je découvre que je suis concerné par une des failles citées ?
Mettre à jour immédiatement le module ou le cœur concerné, puis vérifier si une exploitation a déjà eu lieu avant la mise à jour, ce qui nécessite un contrôle de la base de données et des fichiers du serveur.

Pages liées