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

Conséquences

Mesures de protection

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.