Importer un dump PrestaShop sans purger les jetons de session hérités : l’erreur silencieuse

Deux cent quatorze. C’est le nombre de jetons de session issus de l’ancienne boutique PrestaShop, retrouvés encore valides trois semaines après la mise en ligne de la nouvelle boutique WooCommerce censée la remplacer. Un audit de sécurité de routine, mené sur ce nouveau site, a mis en évidence cette anomalie en examinant une table restée présente dans la base de données après l’import du dump SQL original.

La migration du catalogue produit lui-même (fiches, images, variantes, prix) s’était bien déroulée, via un script d’import dédié qui ne fait pas l’objet de cet article. Le problème venait d’ailleurs : par souci de rapidité, l’équipe technique avait importé l’intégralité du dump SQL de l’ancienne base PrestaShop dans la nouvelle installation, y compris des tables qui n’avaient absolument aucune utilité pour WooCommerce, mais qui restaient accessibles depuis l’interface d’administration de la base de données.

Ce qu’un dump complet transporte, au-delà du catalogue

Une base PrestaShop conserve, entre autres, une table de jetons de connexion persistants (utilisée pour la fonction « se souvenir de moi ») et une table de sessions actives. Ces jetons, générés par l’ancien système, n’ont techniquement aucune valeur pour WooCommerce, qui utilise son propre mécanisme de session. Le vrai risque ne se situait donc pas dans une réutilisation directe de ces jetons sur le nouveau site, mais ailleurs : ces tables PrestaShop, laissées en place et accessibles via une extension d’administration de base de données restée installée par erreur en production, exposaient des informations que personne n’avait pensé à vérifier, dont des adresses email et des hachages de mots de passe de l’ancien système.

Le vrai problème : des identifiants réutilisables ailleurs

Le hachage de mot de passe PrestaShop, une fois exposé, ne permet pas de se connecter directement à WooCommerce, qui utilise un format de hachage différent. Mais un client ayant réutilisé le même mot de passe sur un autre service reste exposé si ce hachage venait à être cassé par un tiers ayant eu accès à la table. C’est ce scénario, bien plus réaliste qu’une réutilisation directe des jetons, qui a motivé la correction.

Ce qui aurait dû être fait avant l’import

-- Ne jamais importer ces tables telles quelles :
-- ps_customer_session
-- ps_guest
-- ps_connections
-- Extraire uniquement les tables nécessaires au catalogue :
mysqldump ancienne_boutique ps_product ps_product_lang ps_category \
  > catalogue_seul.sql

Un import ciblé, limité aux tables réellement nécessaires à la reprise du catalogue, aurait évité que ces données d’authentification héritées ne se retrouvent jamais sur le nouveau serveur.

Corriger après coup : purge et rotation

Une fois l’anomalie détectée, la correction s’est faite en deux temps. D’abord, suppression complète des tables PrestaShop devenues inutiles :

DROP TABLE ps_customer_session, ps_guest, ps_connections;

Ensuite, envoi d’un email à l’ensemble des clients historiques les invitant à modifier leur mot de passe sur le nouveau site, par précaution, sans attendre une preuve formelle d’exploitation de la fuite.

Vérifier systématiquement le contenu d’un dump avant tout import

La bonne pratique, désormais appliquée sur les projets suivants de cette équipe, consiste à lister le contenu d’un dump avant de l’importer intégralement :

grep "CREATE TABLE" dump_complet.sql | wc -l

Cette simple commande révèle en quelques secondes le nombre de tables réellement contenues dans un export, souvent bien supérieur à ce que le catalogue seul nécessite, et invite à se poser la question avant d’importer l’ensemble sans discernement.

Un dump SQL complet n’est jamais un simple fichier de contenu à recopier : il transporte tout ce que l’ancien système savait, y compris ce qui n’a plus aucune utilité fonctionnelle mais reste sensible.

En résumé

La migration d’une boutique PrestaShop vers WooCommerce ne se limite pas à transférer le catalogue produit : elle implique de faire le tri, avant tout import, entre ce qui doit réellement être repris et ce qui doit rester enterré avec l’ancien système. Sur ce site, deux cent quatorze jetons oubliés ont suffi à transformer une migration réussie en incident de sécurité tardif.