Kirassur - SLAM, 2025 session

Mission A1 - Countering false "Glass breakage" claims

The trigger runs at DBMS level, regardless of the application or access method (interface, API, direct query). The check is therefore centralised and tamper-proof: it cannot be bypassed by attacking the application. A purely application-level check, by contrast, could be bypassed.

a) The query (lines 15-20) counts the number of "Glass breakage" claims already reported for the same policy over the reference period (90 days, nbJoursPeriode), to compare it against limit nbMaxSinistresPeriode (= 2).

b) Processing to mark the claim as "to verify":

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

c) To check only the "Glass breakage" cover (id = 3 based on the excerpt from Garantie), wrap the processing in a condition checking the new claim's cover:

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

Mission A2 - Detecting the suspicious event

Keep only "Glass breakage" claims, place those to verify first (aVerifier = 'O'), sort by declaration date, and display the policyholder's name (joins):

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) Under HTTP (plaintext), the feared event is theinterception of the API key or authentication token (network eavesdropping) -> an attacker replays these secrets to hijack access.

b) HTTPS (TLS) encrypts traffic: the key/token is no longer transmitted in plain text, protecting against eavesdropping and replay.

The API key is a permanent secret granting access to all partner resources. Sending it to the policyholder would expose it: they could access all policies managed by that partner (privilege escalation). The policyholder therefore only receives a temporary token, restricted to their own policy.

Yes: a token grants access to a policyholder's policy, and therefore to personal data (identity, vehicle, claims). The token is therefore sensitive data that must be protected (secure storage and transmission).

tokenEnregistrer hashes the token before storing it (the token is never stored in plain text in the database). tokenCharger, on the other hand, handles and compares the token in plain text instead of comparing hashes -> in the event of a database leak, the tokens could be reused directly. Best practice (hashing) must be applied on both sides.

a) The validity period check ensures that an expired token no longer grants access: even if stolen, it becomes unusable after 10 minutes -> the window of exploitation is reduced.

b) The DAO class instructions calculate the expiry date (current date + 600 s, using a date function such as DATE_ADD/SUBDATE) and store it in the database in the tokens table, under the validity/expiration date field.

Mission B2 - Unauthorised access (IDOR)

Yes. The partner increments the policy number in the URL or API call and retrieves policies they did not create: this is an IDOR vulnerability (Insecure Direct Object Reference - OWASP A01: Broken Access Control). The code does not verify resource ownership. Fix (without code): verify, on every request, that the requested policy is indeed linked to the authenticated partner or policyholder (via the token or key) before returning the data.

At network level, block the IP address on the firewall / IPS (blacklisting), for example using an automated mechanism like fail2ban that bans an IP after an abnormal number of attempts.

Tecassur must notify the CNIL within 72 hours, inform affected policyholders if the risk is high, and record the breach in the data breach register.

a) The method logAction of ActionManager must write to table Action the executed action with the user ID and timestamp (NOW()), using a prepared statement.

b) In the controller, enregistrerActionSensible must test action.estSensible and, if true, call logAction to log the action:

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

The model is extended to handle profiles, alerts, and monitoring of sensitive actions:

• table Action with attribute estSensible, and - for each sensitive action - a monitoring interval (nbJours) and a maximum number of calls within that interval;
• table Profil + Profil-Action association (a profile groups multiple authorised actions);
• one-off authorisation (user, action, start/end period) and assignment of a profile to a user (period) - without logging renewal history;
• table Alerte: user, action, trigger date/time, status ("new", "assigned", "resolved", "closed"), and handler + assignment date.

(Claims and policyholders are unaffected by these changes.)