Journalisation et tests de sécurité

La journalisation consiste à enregistrer les actions des utilisateurs et des programmes pour détecter une attaque, en comprendre le déroulement et en établir la responsabilité ; les tests de sécurité vérifient qu'une protection fonctionne vraiment. Les sujets demandent de compléter une méthode qui écrit dans un journal, de lire un journal pour y repérer une attaque, de modéliser un système d'alertes et d'expliquer ou d'écrire des tests unitaires. Ce chapitre couvre ces quatre situations.

Ce qu'un journal doit contenir

La CNIL a publié en 2021 une recommandation sur la journalisation (délibération n° 2021-122). Elle dit ce qu'une trace doit contenir et comment la conserver ; c'est la référence attendue quand un sujet parle de « bonnes pratiques ».

Compléter une méthode de journalisation

Le sujet 2025 faisait ajouter l'adresse IP à une méthode Java qui écrit dans un fichier de traces. Le même exercice en PHP, sur le modèle du sujet Kirassur, avec la superglobale $_SERVER :

1. /**
2.  * Écrit une action sensible dans le journal du jour
3.  * @param Utilisateur $util l'utilisateur connecté
4.  * @param Action $action l'action réalisée
5.  * @param int $idDossier le dossier concerné
6.  */
7. public function logAction(Utilisateur $util, Action $action, int $idDossier): void {
8.     $ligne = date('Y-m-d H:i:s')
9.            . ';util:' . $util->getId()
10.           . ';action:' . $action->getCode()
11.           . ';dossier:' . $idDossier
12.           . ';ip:' . $_SERVER['REMOTE_ADDR'];
13.    $fichier = '/var/log/toutassur/actions' . date('Ymd') . '.log';
14.    file_put_contents($fichier, $ligne . PHP_EOL, FILE_APPEND | LOCK_EX);
15. }

$_SERVER['REMOTE_ADDR'] donne l'adresse IP du client vue par le serveur (derrière un proxy inverse, c'est l'adresse du proxy : il faut alors lire l'en-tête transmis par le proxy, configuré pour être fiable). FILE_APPEND ajoute à la fin sans écraser, LOCK_EX évite que deux requêtes simultanées mélangent leurs lignes.

Lire un journal et repérer une attaque

Chaque attaque laisse une signature reconnaissable dans les journaux d'un serveur Web.

Voici un extrait de journal à analyser :

185.22.14.9 - - [08/Mar/2027:02:14:01 +0100] "POST /login HTTP/1.1" 401 512
185.22.14.9 - - [08/Mar/2027:02:14:02 +0100] "POST /login HTTP/1.1" 401 512
185.22.14.9 - - [08/Mar/2027:02:14:02 +0100] "POST /login HTTP/1.1" 401 512
185.22.14.9 - - [08/Mar/2027:02:14:03 +0100] "POST /login HTTP/1.1" 200 1840
185.22.14.9 - - [08/Mar/2027:02:14:09 +0100] "GET /api/patients/2201 HTTP/1.1" 200 2210
185.22.14.9 - - [08/Mar/2027:02:14:10 +0100] "GET /api/patients/2202 HTTP/1.1" 200 2187
185.22.14.9 - - [08/Mar/2027:02:14:10 +0100] "GET /api/patients/2203 HTTP/1.1" 200 2304

Lecture : trois échecs de connexion en deux secondes, puis une réussite (un mot de passe deviné ou issu d'une fuite), puis des fiches patients lues dans l'ordre des identifiants, toutes en 200. Deux failles se cumulent : aucune limite de tentatives de connexion, et une API qui ne vérifie pas que le compte connecté a le droit de lire chaque fiche. Comme des données de santé ont été consultées, c'est aussi une violation de données à notifier.

Modéliser un système d'alertes

Le sujet Kirassur demandait de compléter un schéma de données pour déclencher une alerte quand une action sensible est répétée trop souvent (par exemple, « modifier les coordonnées bancaires d'un tiers », alerte à la troisième occurrence en cinq jours). Les informations à stocker, et où les mettre :

• sur l'action sensible : l'intervalle de surveillance (en jours) et le nombre maximal d'appels sur cet intervalle ;
• pour chaque exécution : l'utilisateur, l'action et l'horodatage ;
• pour chaque alerte : l'utilisateur, l'action, la date et l'heure de déclenchement, l'état (nouvelle, affectée, résolue, classée), le responsable qui l'a prise en charge et la date d'affectation.

Action (id, libelle, estSensible, intervalleJours, nbMaxAppels)
Execution (id, idUtilisateur, idAction, dateHeure)
Alerte (id, idUtilisateur, idAction, dateHeureDeclenchement, etat,
        idResponsable, dateHeureAffectation)
    idResponsable et dateHeureAffectation : vides tant que l'alerte n'est pas affectée

Les tests unitaires dans les sujets

Un test unitaire vérifie automatiquement le comportement d'une petite unité de code (une méthode) sur un cas précis. Les sujets en donnent pour faire expliquer « les différents cas testés », ou demandent d'en écrire.

Pour expliquer un test, réponds à trois questions : quelle situation est préparée (souvent dans setUp), quel appel est fait, quel résultat est attendu et ce qu'il prouve. En 2025, trois tests de possedeDroit couvraient une table absente des droits (refus), une table et une opération autorisées (accord), une table connue avec une opération non autorisée (refus).

Un bon jeu de tests de sécurité couvre au moins : le cas autorisé, le cas refusé, et les cas limites (valeur vide, identifiant d'un autre utilisateur, jeton expiré). Un test qui ne vérifie que le cas qui marche ne prouve pas qu'un contrôle d'accès fonctionne.

Les autres tests de sécurité

Le cours Tests traite l'écriture de tests unitaires et d'intégration en détail, et ses tests de sécurité prolongent cette section.

Pour aller plus loin. Le cours Journalisation et réponse à incident dit quoi journaliser et comment lire des logs ; les outils de test (SAST, DAST, SCA) sont présentés dans le chapitre Tests de sécurité du cours Sécurité applicative.

Exercices

@BeforeEach
void setUp() {
    compta = new Utilisateur(1, "comptable");
    salarie = new Utilisateur(2, "salarie");
    noteSalarie = new Note(10, salarie);
    noteCompta = new Note(11, compta);
}
@Test void test1() { assertTrue(compta.peutValider(noteSalarie)); }
@Test void test2() { assertFalse(salarie.peutValider(noteSalarie)); }
@Test void test3() { assertFalse(compta.peutValider(noteCompta)); }

77.140.3.18 - - [12/Apr/2027:10:02:11 +0200] "GET /produits.php?cat=3 HTTP/1.1" 200 4120
77.140.3.18 - - [12/Apr/2027:10:02:19 +0200] "GET /produits.php?cat=3%27 HTTP/1.1" 500 310
77.140.3.18 - - [12/Apr/2027:10:02:31 +0200] "GET /produits.php?cat=3%20OR%201=1 HTTP/1.1" 200 98410
77.140.3.18 - - [12/Apr/2027:10:03:02 +0200] "GET /produits.php?cat=3%20UNION%20SELECT%20login,mdp%20FROM%20client HTTP/1.1" 500 310
77.140.3.18 - - [12/Apr/2027:10:03:20 +0200] "GET /produits.php?cat=3%20UNION%20SELECT%20login,mdp,null%20FROM%20client HTTP/1.1" 200 15200