Web

Adobe Commerce réduit le risque d’attaques par confusion de dépendance

by Maxime Leclercq 7 juillet 2021

Pour réduire le risque d’attaques par confusion de dépendance, la version 2.4.3 d’Adobe Commerce inclura un nouveau plugin composer pour effectuer des vérifications d’intégrité durant l’installation.

C’est quoi la confusion de dépendance ?

Lorsque l’on crée une application web, on écrit du code spécifique pour le projet. Il arrive qu’on utilise des packages pour réutiliser du code entre les projets, ou pour profiter d’un code Open Source ou d’un éditeur. En PHP, ces packages sont installés avec l’outil de gestion des dépendances composer.

Composer à besoin de référentiel, appelé repository, pour connaître la liste des packages disponibles. Par défaut, l’outil inclut un référentiel public de packages : https://packagist.org/. On peut venir ajouter nos propres référentiels privés ou ceux d’éditeurs de modules, pour étendre la liste des librairies disponibles.

Mais où est la confusion dans tout ça ?!

Quand un package est requis par notre projet, Composer va chercher, dans un premier temps sur les référentiels privés. Si il ne le trouve pas, l’outil regarde dans le référentiel public. Si les référentiels privés sont inaccessibles, Composer regarde directement sur le référentiel public si le package est disponible.

Imaginons, qu’un hacker crée un package avec du code malveillant et qu’il le déclare sur le référentiel public avec le même nom qu’une de nos dépendances. On pourrait venir installer, sans s’en rendre compte, le package du hacker via nos dépendances !

Comment me prémunir de cette attaque ?

Pour éviter d’installer un package avec du code malveillant qui viendrait d’un référentiel différent de celui attendu vous pouvez prendre quelques précautions. En tant qu’éditeur de package public ou privé, je dois publier un package sur le référentiel public pour réserver mon namespace.

En effet, la première personne qui publie un package avec un namespace non réservé en devient “propriétaire”. À partir de ce moment-là, on doit valider chaque nouveau package déposé sous ce namespace.

Pour votre application web, vous devez :

  • ajouter le fichier composer.lock dans votre gestion de versions, par exemple dans votre git ;
  • pour installer les dépendances, vous devez toujours utiliser composer install ;
  • lors des mises à jour des dépendances, vous devez vérifier les modifications de dépendances dans le fichier composer.lock après l’exécution de composer update.

On peut aussi désactiver le référentiel public en modifiant la configuration global de composer ou pour notre projet :

composer config repo.packagist false

En contrepartie, on se prive d’un large choix de packages Open Source.

Merci Adobe Commerce

Pour Adobe Commerce (ex Magento 2), l’éditeur intégrera un plugin composer dans la version 2.4.3 de la solution e-commerce dès le 10 août pour venir nous aider à contrôler nos dépendances. Ce plugin effectuera deux vérifications et lèvera une exception dès lors :

  • qu’un dépôt privé ne répond pas ;
  • qu’un package est présent sur un référentiel privé et sur le référentiel public ET que la version requise est satisfaite par le référentiel public.

Dans tous les cas, on peut continuer d’appliquer les recommandations pour se prémunir des confusions de dépendances.

Je ne code pas en PHP, je suis tranquille !

Malheureusement, non ! Comme expliqué dans l’article medium d’Alex Birsan, un grand nombre d’outils qui permettent d’installer des dépendances peuvent également être vulnérables à ce genre d’attaque : Python avec pip, Ruby avec gems, Node avec npm…

Restez donc toujours sur vos gardes et vérifiez vos dépendances.

Pour aller plus loin

Quelles nouveautés Magento pour ce trimestre ?

Lire l'article
Maxime Leclercq

Maxime Leclercq

Commentaires

Ajouter un commentaire

Votre commentaire sera modéré par nos administrateurs

Vous avez un projet ? Nos équipes répondent à vos questions

Contactez-nous