Boutique en ligne et faille PHP : protéger clients et paiements

La faille permet à un attaquant d'exécuter son propre code sur votre serveur sans mot de passe, avec un score CVSS de 9,2 sur 10 selon Tenable. Sur un site ordinaire, il peut modifier vos pages. Sur une boutique en ligne, il peut aussi extraire des données clients et des commandes de votre base de données, ou modifier votre étape de paiement pour que vos clients atterrissent sur une fausse page de paiement.

Quelques règles simples :

• WooCommerce, PrestaShop, Magento : toujours PHP. Toutes les versions à partir de PHP 5 sont touchées, indique Help Net Security.
• Shopify et les autres plateformes entièrement hébergées : la plateforme gère les serveurs. Vous n'avez pas à mettre PHP à jour.
• Une boutique hébergée avec, à côté, votre propre blog ou site WordPress : cette partie-là tourne bien sur PHP et doit être mise à jour.

En cas de doute, vous le voyez en dix secondes avec la vérification PHP gratuite de Marketing Scan.

Demandez à votre hébergeur ou à votre webdesigner la version exacte de PHP et une mise à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Si votre boutique tourne sur PHP 8.1 ou plus ancien, aucun correctif ne viendra et une mise à niveau vers au moins 8.2 est nécessaire.

Une telle mise à niveau peut casser d'anciennes extensions ou d'anciens modules. Prévoyez donc :

1. une sauvegarde complète des fichiers et de la base de données ;
2. un test sur une copie de votre boutique si c'est possible ;
3. un moment calme, par exemple le soir, pour que peu de commandes arrivent en même temps.

Parcourez cette liste, ou faites-le faire par votre webdesigner :

• Passez une commande test et payez-la réellement, avec un petit montant. L'e-mail de confirmation arrive-t-il ?
• Regardez les administrateurs de votre boutique. Y a-t-il des comptes que personne ne reconnaît ?
• Vérifiez où mène le bouton de paiement. Arrivez-vous sur la page de votre vrai prestataire de paiement ?
• Comparez vos commandes avec les paiements chez votre prestataire de paiement. Les écarts sont un signal.
• Demandez s'il y a des fichiers nouveaux ou modifiés sur le serveur auxquels personne ne s'attend.

Cela dépend de la façon dont vous traitez les paiements. La plupart des petites boutiques en ligne redirigent les clients vers un prestataire de paiement externe. Les données de carte ne se trouvent alors pas sur votre serveur. Le risque principal est alors qu'un attaquant remplace le lien vers cette page de paiement par un faux.

Si vous traitez les paiements directement sur votre propre site, le risque est plus grand. Parlez-en avec votre webdesigner et votre prestataire de paiement, et envisagez de mettre votre boutique temporairement hors ligne si la mise à jour ne peut pas se faire rapidement. Un pare-feu peut freiner temporairement les attaques, mais selon Patchstack, la mise à jour est la seule solution complète.

Une vulnérabilité en soi n'est pas encore une fuite de données. Vous ne devez la signaler que si des données personnelles de clients ont effectivement pu tomber entre de mauvaises mains, par exemple parce que vous trouvez des traces d'intrusion.

Si c'est le cas, vous devez, selon le RGPD, signaler la fuite de données dans les 72 heures à l'Autorité de protection des données. Ce délai court à partir du moment où vous la découvrez. Notez donc immédiatement ce que vous avez constaté, quand, et quelles données ont pu être touchées.

• Changez tous les mots de passe des administrateurs, de l'hébergement, de la base de données et du prestataire de paiement.
• Demandez de nouvelles clés API à votre prestataire de paiement et aux autres services connectés.
• Faites rechercher par votre webdesigner les fichiers laissés par un intrus. Une mise à jour ferme la porte, mais ne fait pas sortir un intrus qui est déjà entré.
• Restaurez une sauvegarde d'avant l'intrusion si ce qui a été modifié n'est pas clair.

Le 21 octobre, le CCB ne signalait encore aucune attaque réussie en Belgique, selon VRT NWS.