Kirassur — SLAM, session 2025

Mission A1 — Contrer la fausse déclaration « Bris de glace »

Le déclencheur s’exécute au niveau du SGBD, quelle que soit l’application ou la voie d’accès (interface, API, requête directe). Le contrôle est donc centralisé et inviolable : on ne peut pas le contourner en attaquant l’application. Un contrôle uniquement applicatif serait, lui, contournable.

a) La requête (lignes 15-20) compte le nombre de sinistres « Bris de glace » déjà déclarés pour le même contrat sur la période de référence (90 jours, nbJoursPeriode), afin de le comparer à la limite nbMaxSinistresPeriode (= 2).

b) Traitement pour placer le sinistre « à vérifier » :

IF v_nbSinistres > v_nbMax THEN
    SET NEW.aVerifier = 'O';   -- O = à vérifier (N sinon)
END IF;

c) Pour ne contrôler que la garantie « Bris de glace » (id = 3 d’après l’extrait de Garantie), on encadre le traitement par une condition sur la garantie du nouveau sinistre :

IF NEW.idGarantie = 3 THEN   -- 3 = « Bris de glace »
    -- ... (comptage + mise à 'O' si dépassement)
END IF;

Mission A2 — Détecter l’évènement suspect

On ne garde que les « Bris de glace », on place en premier ceux à vérifier (aVerifier = 'O'), on trie par date de déclaration, et on affiche le nom de l’assuré (jointures) :

SELECT s.idContrat, s.numero, s.dateDeclaration, s.aVerifier,
       a.nom, a.prenom
FROM Sinistre s
JOIN Contrat c ON s.idContrat = c.id
JOIN Assure  a ON c.idAssure  = a.id
WHERE s.idGarantie = 3                       -- Bris de glace
ORDER BY s.aVerifier DESC, s.dateDeclaration ASC;  -- 'O' avant 'N'

a) En HTTP (clair), l’évènement redouté est l’interception de la clé API ou du jeton d’authentification (écoute du réseau) → un attaquant rejoue ces secrets pour usurper l’accès.

b) HTTPS (TLS) chiffre les échanges : la clé/le jeton ne circulent plus en clair, ce qui protège contre l’écoute et le rejeu.

La clé API est un secret permanent qui donne accès à toutes les ressources du partenaire. La transmettre à l’assuré l’exposerait : il pourrait accéder à tous les contrats gérés par ce partenaire (élévation de privilèges). L’assuré reçoit donc seulement un jeton temporaire, limité à son propre contrat.

Oui : un jeton permet d’accéder au contrat d’un assuré, donc à des données à caractère personnel (identité, véhicule, sinistres). Le jeton est par conséquent une donnée sensible à protéger (stockage et transmission sécurisés).

tokenEnregistrer hache le jeton avant de le stocker (le jeton n’est jamais conservé en clair en base). tokenCharger, lui, manipule/compare le jeton en clair au lieu de comparer des empreintes → en cas de fuite de la base, les jetons seraient directement réutilisables. La bonne pratique (hachage) doit être appliquée des deux côtés.

a) Le contrôle de durée de validité garantit qu’un jeton expiré ne donne plus accès : même volé, il devient inutilisable au bout de 10 minutes → la fenêtre d’exploitation est réduite.

b) Les instructions de la classe DAO calculent la date limite (date courante + 600 s, via une fonction de date type DATE_ADD/SUBDATE) et la stockent en base dans la table des jetons, champ date de validité/expiration.

Mission B2 — Accès illicite (IDOR)

Oui. Le partenaire incrémente le numéro de contrat dans l’URL/l’appel API et obtient des contrats dont il n’est pas à l’origine : c’est une faille IDOR (Insecure Direct Object Reference — OWASP A01 : Broken Access Control). Le code ne vérifie pas la propriété de la ressource. Correction (sans coder) : contrôler, à chaque accès, que le contrat demandé est bien rattaché au partenaire/assuré authentifié (par le jeton/la clé) avant de renvoyer les données.

Au niveau réseau, bloquer l’adresse IP sur le pare-feu / IPS (mise en liste noire), par exemple via un mécanisme automatique de type fail2ban qui bannit une IP après un nombre anormal de tentatives.

Tecassur doit notifier la CNIL dans les 72 heures, informer les assurés concernés si le risque est élevé, et consigner la violation dans le registre des violations de données.

a) La méthode logAction de ActionManager doit écrire dans la table Action l’action exécutée avec l’identifiant de l’utilisateur et l’horodatage (NOW()), via une requête préparée.

b) Dans le contrôleur, enregistrerActionSensible doit tester action.estSensible et, si vrai, appeler logAction pour journaliser :

si uneAction.estSensible == true :
    actionManager.logAction(utilisateurConnecté, uneAction, maintenant)

On complète le modèle pour gérer profils, alertes et surveillance des actions sensibles :

• table Action avec l’attribut estSensible, et — pour chaque action sensible — un intervalle de surveillance (nbJours) et un nombre maximal d’appels sur cet intervalle ;
• table Profil + association Profil–Action (un profil regroupe plusieurs actions autorisées) ;
• habilitation ponctuelle (utilisateur, action, période début/fin) et affectation d’un profil à un utilisateur (période) — sans historisation des reconductions ;
• table Alerte : utilisateur, action, date/heure de déclenchement, état (« nouvelle », « affectée », « résolue », « classée »), et responsable ayant pris en charge + date d’affectation.

(Les sinistres et assurés ne sont pas concernés par ces évolutions.)