La sécurité de Magento nécessite un correctif supplémentaire pour corriger une vulnérabilité de nettoyage des données

Dans le monde de la technologie, nous sommes souvent soumis à une forte pression pour corriger du code déployé, mettre à jour un composant d’infrastructure ou appliquer un correctif. Souvent, nous en sommes informés au dernier moment et il aurait même fallu le faire cinq minutes plus tôt. Avec toute intervention « sans délai », il faut trouver le juste équilibre entre se précipiter pour corriger immédiatement et prendre le temps de tester et de vérifier.

Récemment, un correctif critique a été publié pour Magento Ecommerce, Magento Open Source et les versions d’Adobe Commerce de Magento, après la découverte d’un problème critique par des chercheurs en sécurité sur la plateforme de commerce électronique très répandue. CVE-2022-24086 désignait une vulnérabilité permettant à un utilisateur non authentifié d’exploiter une injection SQL ou une injection d’objet PHP au moment du paiement.

Adobe Security a alors déployé un premier correctif, en réagissant rapidement pour proposer une solution. Quelques jours plus tard, des chercheurs ont découvert que le correctif ne suffisait pas à neutraliser le code vulnérable. Un nouveau CVE-2022-24087 a alors été publié et un second correctif déployé.

Un correctif pour la vulnérabilité nouvellement identifiée est disponible dans la dernière alerte de sécurité d’Adobe. Le nouveau correctif doit être appliqué après le correctif initial pour CVE-2022-24086.

Dans le domaine de la sécurité des applications, j’aime toujours vérifier avec soin les déploiements, les bibliothèques et tout ce qui peut avoir un impact sur les utilisateurs finaux d’une plateforme. Alors, examinons le dernier correctif et voyons ce qui a changé.

Examen du correctif CVE-20220-24087

Avant d’entrer dans le détail du nouveau correctif MDVA-43443, revenons sur le correctif initial MDVA-43395 pour comprendre son rôle.

Il est important de noter que les deux vulnérabilités concernent uniquement Magento Open Source et Adobe Commerce dans les versions supérieures ou égales à 2.3.4 et antérieures à 2.4.5-p1 ou 2.3.7-p2.

Le correctif initial (MDVA-43395) a ajouté un nettoyage sécurisé des données saisies par l’utilisateur pendant le processus de paiement, dans la logique de l’application de boutique Magento. /Email/Model/Template/transDirective et VarDirective.php ont tous deux été dotés de motifs preg_replace() et preg_match() pour aider à nettoyer les types de caractères indésirables saisis par l’utilisateur.

Après le déploiement du correctif, les chercheurs en sécurité ont découvert qu’il ne suffisait pas à neutraliser le vecteur d’attaque et qu’il ouvrait même la voie à l’apparition de vulnérabilités encore plus profondes dans le framework.

Le nouveau correctif (MDVA-43443) ajoute une fonction réutilisable au framework, appelée sanitizeValue(). Celle-ci étend \Magento\Framework\Filter\Template et effectue une vérification de nettoyage à l’aide de preg_replace.

sanitizeValue() remplace ensuite le code de nettoyage preg_match() et preg_replace() ajouté par le correctif initial MDVA-43395.

La fonction sanitizeValue() est ensuite utilisée à plusieurs endroits dans la base de code, notamment pour charger les types de valeurs de configuration et personnalisées qui ont été nettoyées.

C’est dans blockDirective() qu’une nouvelle étape de nettoyage est effectuée : les correspondances de caractères et le nettoyage sont étendus dans le cœur de \Magento\Framework\FilterTemplate.

resolveBlockDirective passe d’une fonction publique à une fonction privée, et layoutDirective est remplacée par resolveLayoutDirective.

Le passage d’une fonction publique à une fonction privée est important pour la sécurité des applications PHP, car la déclaration d’une fonction privée signifie qu’elle ne peut être utilisée que depuis sa classe parente. Une fonction publique, elle, peut être appelée depuis n’importe quel endroit de l’application.

Les deux correctifs sont disponibles dans le bulletin de sécurité APSB22-12 d’Adobe. Vous pouvez les installer avec PHP Composer ou les fusionner dans une base de code issue d’un fork.

Pensez à effectuer des sauvegardes sécurisées avant d’appliquer les deux correctifs, et à tester le code avant son déploiement.

Inscrivez-vous à Snyk pour recevoir des alertes sur les nouvelles vulnérabilités

Pour les grands projets open source comme Magento, je surveille toujours le dépôt public depuis mon tableau de bord Snyk.

Cliquez sur Add Project, puis surveillez les dépôts GitHub publics.

C’est particulièrement utile pour les branches de développement d’un projet, car vous pouvez être alerté des problèmes potentiels pendant leur développement. Cela facilite aussi les contributions au projet : vous pouvez repérer les problèmes à corriger tant qu’il est encore en cours de développement.

Pour les projets de plateforme comme Magento, le processus de surveillance recherche les manifestes de packages, le code, les conteneurs et les configurations IaC afin d’analyser les problèmes potentiels et de les mettre en évidence. Mieux encore, il propose également des correctifs et vous guide dans l’examen des éléments détectés.