Injection SQL sur un CMS : signes dans le contenu et les comptes

Ce que vous voyez dans le contenu

Articles ou pages anciens soudain plein de liens pharmacies / casino / caractères asiatiques. Produits dont la description a gonflé. Widgets HTML. Un spam SEO « dans le CMS » sans fichier nouveau est le signe d'école. La page injection cadre le sujet ; ici, les signes pour un gérant de boutique ou de blog.

Des titres dans `site:` qui ne sont pas sur le disque : génération à la volée *ou* lignes en base. On ouvre l'admin et la table, pas seulement le FTP.

Un défacement de `index.php` est un autre dossier (fichiers). Les deux coexistent parfois. Ne diagnostiquez pas au seul écran d'accueil.

Comptes et rôles qui ne devraient pas

Utilisateurs administrateurs créés à 4 h, emails jetables, logins proches de `admin` avec un chiffre. Rôles d'abonnés passés shop manager. Dans Prestashop : employés, profils. C'est une *écriture* en base. Elle prouve l'accès SQL ou un admin déjà ouvert — le constat le dit avec les logs d'admin vs l'absence de login.

Supprimez les fantômes *après* copie de la table users (preuve). Puis sessions. Un compte recréé le lendemain : injection encore ouverte ou porte fichiers. 48 h.

Les clients boutique nés en masse : parfois du stuffing, parfois un script. Exportez avant purge. Enjeu données.

• Admins / employés fantômes.
• Changements de rôle.
• Créations de masse à horaires absurdes.

Options, menus, pieds de page

URL du site changée, page d'accueil pointant vers un ID inconnu, extraits JS dans `custom_html`, en-têtes SEO globaux réécrits, user `ID 1` dont l'email a changé. Sur WooCommerce : pages checkout pointant ailleurs. Vous « réparez la home » dans l'UI ; elle revient au chargement suivant si l'option est réécrite.

Les menus qui incluent des URL spam. Les redirections plugin stockées en base. Cherchez *où* le CMS garde la règle, pas seulement `.htaccess`.

Un pixel peut vivre en option. Même chasse, autre impact RGPD.

Ce que les fichiers ne diront pas

Un cœur WordPress *diff* propre rassure à tort. L'injection n'a pas besoin de toucher `wp-includes`. Les logs SQL, s'ils existent, et les signes ci-dessus parlent. Un Adminer public est une porte *et* un signe. Fermez-le.

Inversement, des fichiers sales + base sale : deux nettoyages. L'un ne prouve pas l'autre inutile.

Les backups `.sql` dans le webroot sont une exfiltration potentielle, pas seulement une trace d'injection. Signes d'extraction.

Ne pas restaurer à l'aveugle

La sauvegarde d'il y a trois semaines contient parfois déjà les lignes spam *et* vous fait perdre les commandes. Copiez l'état actuel. Comparez les tables (posts, options, users) à une copie plus ancienne *lue*, pas « restaurer la dernière » par réflexe.

Une restauration partielle (une table) par quelqu'un qui sait, après copie. Un import complet d'un dump trouvé « sur le bureau » est une roulette.

Après restauration, l'entrée (formulaire, module de recherche, API) est toujours là si vous n'avez pas patché. Les bots rejouent. La page métier injection SQL insiste : corriger l'entrée, pas seulement les lignes.

Borner la lecture des données

Écriture visible ≠ lecture de toute la table clients. Mais une injection *peut* extraire. Le constat dit plausible vs démontré. Logs, dumps, volume. Horloge 72 h selon le risque.

Si `users` a pu être lue : reset. Si clair : encore plus net.

N'affirmez pas « SQL injection donc tout a fuité » ni l'inverse. Les signes d'écriture sont le plancher, pas le plafond.

Fermer l'entrée applicative

Quel composant parlait à la base sans garde-fou : recherche, filtre d'URL, formulaire, plugin abandoned, API. Mise à jour ou retrait. Vous n'avez pas à « tester l'injection ». Vous avez à sortir du composant connu pour être troué, ou à le mettre au niveau du correctif éditeur.

WAF en urgence : parfois un pansement. Pas un substitut de MAJ. Il se pose après compréhension, pas comme seul geste.

Préfixes de tables, comptes SQL trop droits (`GRANT ALL` à l'utilisateur web) : durcissement à froid, avec l'hébergeur. Pas un tutoriel d'attaque.

Après : base propre, entrée fermée

Contenus nettoyés *ou* table restaurée propre, composant patché, comptes et sessions, surveillance des nouvelles écritures (journalisation). Un `site:` qui se vide lentement n'est pas une réinjection ; un nouvel article spam demain, si.

Les fichiers : quand même une passe backdoor. Les attaquants enchaînent.

Créer un espace si la base est le métier (boutique) et que vous n'osez pas toucher. Joignez les signes (captures admin, dates de users), pas un dump clients par email.

• Signes contenu / comptes / options.
• Copie avant toute restauration.
• Patch du composant, pas seulement le spam.