Audit manuel d'un dépôt avec une grille d'analyse¶

Objectifs pédagogiques¶

À la fin de ce TP, vous devez être capables de :

• parcourir un dépôt inconnu avec méthode, en suivant une grille d'analyse
• repérer les failles les plus fréquentes : secret codé en dur, injection, contrôle d'accès absent, dépendance vulnérable, conteneur exécuté en root, configuration HTTP
• décrire un constat de façon exploitable : emplacement, risque, gravité, piste de correction
• estimer une gravité avec une méthode simple, et la justifier
• mesurer le temps qu'un audit manuel demande, et ce qu'il apporte qu'un outil n'apporte pas

Prérequis¶

• Git, un éditeur de code et un terminal (sous Windows : Git Bash ou WSL)
• Un navigateur, pour consulter les bases de vulnérabilités
• Aucune connaissance préalable en sécurité : le vocabulaire nécessaire est donné ci-dessous
• Facultatif : jq pour lire les réponses JSON, et Node.js 20 ou plus récent pour l'atelier 3

Contexte¶

Vous rejoignez l'équipe de securepay-api, une API de paiement. Son README cite un audit externe qui a relevé cinq anomalies. Avant d'automatiser quoi que ce soit, vous menez votre propre audit, à la main : retrouver ces cinq anomalies, comprendre pourquoi ce sont des risques, et chercher ce que l'auditeur a manqué.

Le code contient des commentaires [AUDIT ANOMALY] laissés par cet auditeur : ce sont des indices, pas une liste complète, et l'un d'eux contient une erreur.

Notez l'heure de début. Le temps que vous passerez sur cet audit servira à justifier l'automatisation.

Le vocabulaire minimum¶

La méthode : estimer la gravité¶

Pour chaque constat, posez deux questions : qu'obtient l'attaquant (l'impact), et de quoi a-t-il besoin (la facilité) ?

Atelier 1 : Prendre en main le dépôt¶

Travail demandé¶

1. Clonez votre copie du dépôt et repérez sa structure :

git clone https://github.com/<votre-compte>/securepay-api.git
cd securepay-api
git ls-files
git log --oneline

1. Lisez le README.md, le package.json et le Dockerfile, puis listez les routes exposées par l'API :

grep -rnE "(router|app)\.(get|post|put|patch|delete)\(" src/

1. Créez votre tableau des constats dans audit/constats.md :

Ce que vous devez observer¶

• Six routes : /health et /api/info dans app.js, /api/auth/login dans routes/auth.js, et /api/payments/process, /calculate-tax et /recent dans routes/payments.js
• Le code métier est séparé dans src/services/paymentService.js
• Quatre dépendances directes dans package.json, dont trois en version fixe

Critère de réussite¶

Vous savez dire ce que fait l'application, quelles routes elle expose et où se trouve chaque partie du code.

Atelier 2 : Parcourir la grille¶

Suivez la grille section par section. Pour chacune, lancez les commandes, lisez le code concerné, et ajoutez un constat dans votre tableau chaque fois que la réponse à une question vous inquiète.

A. Secrets¶

• Ce que l'on cherche : des mots de passe, clés d'API ou clés de signature écrits dans le code, la configuration ou l'historique Git
• Où regarder : src/, les fichiers .env*, la configuration, le Dockerfile, l'historique

grep -rniE "secret|password|api[_-]?key|token|sk_(test|live)_" \
  --exclude-dir=node_modules --exclude-dir=.git --exclude=package-lock.json .
git log -p | grep -niE "secret|password|sk_(test|live)_"
git log --all --diff-filter=D --name-only --format="%h %s"   # fichiers supprimés depuis

• Questions à se poser :
  • Ce secret est-il réel, ou une valeur d'exemple ?
  • Que se passe-t-il si la variable d'environnement est absente au démarrage ?
  • Le secret figure-t-il dans l'historique, même s'il a été retiré depuis ?

B. Entrées utilisateur et injections¶

• Ce que l'on cherche : une donnée envoyée par l'utilisateur qui arrive, sans contrôle, dans une fonction dangereuse
• Où regarder : chaque route, de la lecture de la requête jusqu'à la réponse

grep -rnE "req\.(body|query|params)" src/
grep -rnE "eval\(|new Function|child_process|exec\(" src/

• Questions à se poser :
  • Pour chaque donnée lue dans la requête, où va-t-elle ensuite ?
  • Est-elle validée : type, longueur, format, liste de valeurs autorisées ?
  • Peut-elle être exécutée comme du code, ou insérée dans une commande ou une requête ?

C. Authentification et contrôle d'accès¶

• Ce que l'on cherche : comment un utilisateur prouve son identité, et quelles routes le vérifient
• Où regarder : la route de connexion, puis chaque route sensible

grep -rnE "jwt\.(sign|verify)" src/
grep -rn "password" src/

• Questions à se poser :
  • Comment le mot de passe est-il vérifié ? Existe-t-il une base d'utilisateurs ?
  • Comment le rôle de l'utilisateur est-il attribué ?
  • Le jeton émis est-il vérifié ? Par quelles routes ?
  • Combien d'essais de mot de passe un attaquant peut-il faire ?

D. Dépendances¶

• Ce que l'on cherche : des bibliothèques anciennes, touchées par des vulnérabilités publiques
• Où regarder : package.json pour les dépendances directes, package-lock.json pour les versions réellement installées et les dépendances indirectes

cat package.json
grep -rnE "require\(['\"](axios|lodash|jsonwebtoken|express)" src/

• Pour chaque dépendance : recherchez-la sur osv.dev ou dans la GitHub Advisory Database, et comparez la version utilisée aux versions corrigées. La même recherche en ligne de commande :

curl -s -X POST https://api.osv.dev/v1/query -H 'Content-Type: application/json' \
  -d '{"package":{"name":"jsonwebtoken","ecosystem":"npm"},"version":"8.5.1"}' \
  | jq -r '.vulns[] | (.aliases // [] | join(" ")) + " " + .summary'

• Questions à se poser :
  • La version est-elle fixée (8.5.1) ou en plage (^4.19.2) ? Qu'est-ce que cela change ?
  • Quelle est la dernière version, et quelles CVE corrige-t-elle ?
  • La bibliothèque est-elle seulement utilisée par le code ?
  • La CVE citée dans le commentaire de auth.js existe-t-elle vraiment ?

E. Conteneur¶

• Ce que l'on cherche : une image trop grosse, un processus exécuté en root, des fichiers qui n'ont rien à faire dans l'image
• Où regarder : le Dockerfile, et la présence d'un fichier .dockerignore

cat Dockerfile
ls -a

• Questions à se poser :
  • Quel utilisateur exécute le processus dans le conteneur ?
  • L'image de base est-elle minimale ? Sa version est-elle précise ?
  • Que copie COPY . . ? Un fichier .env local, le dossier .git ou les tests finissent-ils dans l'image ?
  • Les outils de test (devDependencies) sont-ils installés dans l'image de production ?

F. Configuration HTTP et gestion des erreurs¶

• Ce que l'on cherche : des en-têtes de sécurité absents, une bannière qui révèle la technologie, des messages d'erreur trop bavards
• Où regarder : src/app.js, et les blocs catch des routes

grep -rn "helmet\|x-powered-by" src/
grep -rnE "(err|error)\.message" src/

• Questions à se poser :
  • Que révèlent les en-têtes de réponse à un attaquant ?
  • Que lui apprend un message d'erreur renvoyé tel quel ?

G. Journalisation et caractère aléatoire¶

• Ce que l'on cherche : l'absence de trace des événements de sécurité, et des identifiants prévisibles
• Où regarder : tous les appels à console.log, et la création des références de transaction dans paymentService.js

grep -rn "console\.log" src/
grep -rn "Math.random" src/

• Questions à se poser :
  • Une connexion échouée ou un paiement laissent-ils une trace exploitable ?
  • Une référence de transaction peut-elle être devinée ?

Critère de réussite¶

Les sept sections de la grille sont parcourues, et chaque constat est noté avec son emplacement exact.

Atelier 3 : Prouver par l'exécution (facultatif)¶

Un constat prouvé convainc plus qu'un constat supposé. Lancez l'application sur votre poste uniquement, puis vérifiez trois constats :

npm ci --omit=dev
npm start

Dans un second terminal :

# Les en-têtes de réponse
curl -i http://localhost:3000/health

# Les transactions, sans aucun jeton
curl -i http://localhost:3000/api/payments/recent

# Un jeton pour l'utilisateur « admin » : décodez sa partie centrale, sans l'envoyer sur un site tiers
TOKEN=$(curl -s -X POST http://localhost:3000/api/auth/login -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"password123"}' | jq -r .token)
echo "$TOKEN" | cut -d. -f2 | base64 -d   # la fin peut être tronquée : c'est un effet du format base64url

# Une « formule » qui n'est pas une formule
curl -s -X POST http://localhost:3000/api/payments/calculate-tax -H 'Content-Type: application/json' \
  -d '{"amount":100,"formula":"process.version"}'

Ce que vous devez observer¶

• L'en-tête X-Powered-By: Express est présent, et aucun en-tête de sécurité (Content-Security-Policy, Strict-Transport-Security) n'est renvoyé
• /api/payments/recent répond 200 sans jeton
• Le jeton décodé contient "role":"ADMIN" : il a suffi de s'appeler admin et de connaître le mot de passe commun à tous
• La « taxe » renvoyée est la version de Node.js du serveur : le texte envoyé a été exécuté. Un attaquant pourrait exécuter n'importe quelle commande à la place

Atelier 4 : Qualifier, prioriser et comparer¶

Travail demandé¶

1. Pour chaque constat, estimez la gravité avec la matrice, et justifiez-la en une phrase.
2. Triez le tableau de la gravité la plus forte à la plus faible, et désignez les trois constats à corriger en premier.
3. Comparez avec les cinq anomalies du README : lesquelles avez-vous retrouvées, et qu'avez-vous trouvé de plus ?
4. Notez le temps passé, au total et par section de la grille.

Critère de réussite¶

Au moins cinq constats correctement qualifiés, dont les cinq anomalies du README, et un classement justifié par la matrice.

Niveau avancé¶

Ajoutez deux colonnes à votre tableau :

• Catégorie OWASP Top 10 2025 : la famille de risque à laquelle se rattache le constat

• Étape où le constat aurait dû être arrêté : poste du développeur (hook pre-commit, extension de l'éditeur), merge request (revue, analyse automatique), construction de l'image, ou déploiement

Questions de synthèse¶

• Combien de temps a pris votre audit ? Combien de temps faudrait-il pour le refaire à chaque modification du code ?
• Quels constats un outil automatique trouvera-t-il facilement ? Lesquels exigent de comprendre l'application ?
• Pourquoi la gravité d'un constat dépend-elle du contexte, alors que le score CVSS d'une CVE n'en dépend pas ?
• Pourquoi supprimer un secret du code ne suffit-il pas à régler le problème ?
• Pourquoi un commentaire de code ou un rapport d'audit doivent-ils être vérifiés à la source ?

Corrigé¶