Rappel théorique
Une application moderne repose sur de nombreuses bibliothèques tierces (paquets npm, dépendances Composer, images de base...). Si l'une de ces dépendances contient une vulnérabilité connue (CVE) et qu'elle n'est pas mise à jour, l'application hérite directement de cette faille - même si le code écrit par l'équipe est lui-même irréprochable.
Causes principales
- Dépendances jamais mises à jour après le démarrage du projet.
- Absence d'inventaire des composants utilisés et de leurs versions (SBOM).
- Pas de veille sur les vulnérabilités publiées (CVE, advisories GitHub).
- Dépendances transitives (les dépendances de vos dépendances) hors de contrôle.
Conséquences
- Exploitation de vulnérabilités publiques et documentées, parfois avec un exploit prêt à l'emploi.
- Effet "domino" : une faille dans une dépendance transitive profonde peut affecter des centaines de projets.
Mesures de protection
- Maintenir un inventaire des dépendances et de leurs versions.
- Exécuter régulièrement
npm audit/composer audit(ou Dependabot, Snyk...) et corriger les vulnérabilités signalées. - Mettre à jour les dépendances régulièrement, retirer celles qui ne sont plus utilisées.
- Vérifier la provenance et la réputation des paquets installés.
Démo 1 : npm audit (Node.js, exécution réelle)
Le fichier package.json de ce dossier déclare volontairement des versions anciennes de paquets très utilisés :
"dependencies": {
"lodash": "4.17.4",
"express": "4.16.0",
"minimist": "1.2.0"
}
Node.js est installé dans le conteneur applicatif : vous pouvez exécuter l'audit vous-même et obtenir le rapport à jour (les CVE détectées évoluent dans le temps) :
docker exec php_app sh -c "cd /var/www/html/OWASP/A09-Vulnerable-Components && npm install && npm audit"
Exemple de sortie obtenue (extrait, capturé lors de la rédaction de ce TP) :
# npm audit report
lodash <=4.17.23
Severity: critical
Prototype Pollution in lodash - GHSA-fvqr-27wr-82fm
Command Injection in lodash - GHSA-35jh-r3h4-6jhm
Regular Expression Denial of Service (ReDoS) in lodash - GHSA-29mw-wpgm-hmr9
... (8 advisories au total)
fix available via `npm audit fix --force`
Will install lodash@4.18.1, which is outside the stated dependency range
minimist 1.0.0 - 1.2.5
Severity: critical
Prototype Pollution in minimist - GHSA-vh95-rmgr-6w4m
Prototype Pollution in minimist - GHSA-xvch-5gv4-984h
fix available via `npm audit fix --force`
express <=4.21.0
Depends on vulnerable versions of body-parser, cookie, path-to-regexp, qs, send, serve-static
...
9 vulnerabilities (3 low, 4 high, 2 critical)
lodash@4.17.4 est par exemple concerné par
GHSA-35jh-r3h4-6jhm (Command Injection) et plusieurs
Prototype Pollution - corrigées dans des versions ultérieures. La
correction recommandée (npm audit fix) met simplement à jour les versions
dans package.json / package-lock.json.
Démo 2 : composer audit (PHP, exemple illustré)
Composer n'est pas installé dans l'image PHP de ce TP (pour ne pas alourdir le conteneur). Le fichier composer.json de ce dossier déclare deux versions anciennes connues pour leurs vulnérabilités :
"require": {
"symfony/http-kernel": "5.3.0",
"guzzlehttp/psr7": "1.8.3"
}
Avec Composer installé, la commande composer audit (ou même
composer install depuis Composer 2.10) refuse ces versions car elles sont
couvertes par des avis de sécurité publiés sur Packagist. Sortie réelle obtenue en
tentant un composer install sur ce composer.json :
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires symfony/http-kernel 5.3.0, found symfony/http-kernel[v5.3.0]
but these were not loaded, because they are affected by security advisories
("PKSA-hr4y-jwk2-1yb9", "PKSA-ftqt-8gzv-r53t").
Go to https://packagist.org/security-advisories/ to find advisory details.
Problem 2
- Root composer.json requires guzzlehttp/psr7 1.8.3, found guzzlehttp/psr7[1.8.3]
but these were not loaded, because they are affected by security advisories
("PKSA-jj5t-2zs1-dcfm", "PKSA-gm5x-j3mz-71n9", "PKSA-hn62-zkx4-1y5q", "PKSA-gvzg-s447-b5b5").
Composer bloque ici par défaut l'installation de versions connues comme
vulnérables : c'est exactement le rôle de composer audit appliqué à un
composer.lock existant - lister les dépendances installées concernées par
un avis de sécurité publié, pour planifier leur mise à jour.