Puces'in — SLAM, session 2025

Mission A1 — VerifColis (client lourd)

Un employé a validé des prix de rachat supérieurs au prix de revente : Puces’in rachète plus cher qu’elle ne revend → perte financière directe (achat à perte) sur chaque livre concerné.

Ajouter un contrôle (côté applicatif/serveur) avant l’enregistrement : n’enregistrer le prix de rachat proposé que si le livre est dans un état « acceptable » et que ce prix ne dépasse pas 10 % du prix de revente ; sinon, refuser/bloquer l’enregistrement et signaler. La règle ne doit pas reposer sur l’interface seule (contournable) mais être vérifiée à l’enregistrement.

Mission A2 — Puces’in Rachète (mobile / API REST)

1. Coûts logistiques inutiles : Puces’in traite des colis vides (réception, tri, manutention) sans aucun livre à racheter.
2. Détournement/abus du service : les concurrents obtiennent des bordereaux d’expédition gratuits et faussent le fonctionnement — perte de temps et atteinte à la disponibilité du service pour les vrais vendeurs.

Avant de valider le colis, appeler getNbBordereauDuMois(idVendeur) ; si le résultat est ≥ 4, refuser la validation (retourner false/erreur) ; sinon valider. Le contrôle est fait côté API (serveur), pas seulement dans l’application mobile.

Mission A3 — API REST et jetons JWT

a/b/c) Les deux tests en vulnérabilité révèlent typiquement : un accès sans authentification à une ressource (la requête aboutit alors qu’elle ne devrait pas → atteinte à la confidentialité), et un défaut de contrôle d’accès / d’intégrité (une écriture non autorisée passe → atteinte à l’intégrité). On qualifie chaque test selon le critère touché (confidentialité, intégrité ou disponibilité).

Elle ne l’est que si elle compare des empreintes (mots de passe hachés avec sel) via une requête préparée. Si elle compare des mots de passe en clair ou construit la requête par concaténation (injection SQL possible), elle n’est pas sécurisée.

Mettre en place un rate limiting (limitation de débit) : on compte les requêtes par utilisateur/URI sur une fenêtre de temps et on rejette au-delà d’un seuil (réponse HTTP 429). (Sa mise en œuvre n’est pas demandée.)

La signature du jeton est calculée avec HMAC à partir d’une clé secrète connue du seul serveur. Toute modification du contenu du jeton (en-tête ou charge utile) invalide la signature : le serveur recalcule le HMAC et détecte l’altération. Un attaquant ne peut pas forger un jeton valide sans la clé → l’intégrité (et l’authenticité) du jeton est assurée.

Le JWT prouve l’identité mais ne chiffre pas son transport : en HTTP, un attaquant peut intercepter le jeton (écoute) et le rejouer pour usurper la session. HTTPS (TLS) chiffre le canal → il protège le jeton (et les données) contre l’écoute et le vol.

Le second test échoue parce que le jeton n’est pas valide au moment de la requête : typiquement un jeton expiré (durée de vie dépassée), absent, ou dont la signature ne correspond pas (jeton modifié / mauvaise clé) — l’API le rejette donc.

a) Deux droits manquants : le droit de rectification et le droit à l’effacement (« droit à l’oubli »).

b) Mme Mathy dispose d’un délai réglementaire d’un mois pour répondre (extensible à trois mois pour les demandes complexes, avec information de la personne) — son délai actuel de 2 mois est hors délai.

Non, ce n’est pas conforme. Le RGPD impose une limitation de la durée de conservation : les copies des pièces d’identité ne doivent être conservées que le temps nécessaire au traitement de la demande, puis supprimées. Les garder indéfiniment « par précaution » est une conservation excessive (manquement au principe de minimisation/limitation).

Le traitement de saisie des demandes d’exercice de droits doit être décrit dans le registre des activités de traitement (registre RGPD tenu par le responsable de traitement).

Compléter le schéma pour gérer le délai, les statistiques et la traçabilité :

• une table Demande avec son type de droit et ses dates (date de saisie, dates de changement d’état) → permet le calcul du délai et des statistiques par type ;
• une table Echange (date, description, origine = D demandeur ou P DPO), reliée à la demande → conserve la trace des échanges.

Mission C1 — Attaques et contre-mesures

a) L’attaquant a utilisé une technique d’ingénierie sociale (par exemple un hameçonnage / phishing : message frauduleux incitant l’employé à cliquer ou à divulguer ses identifiants).

b) L’employé a donc été victime d’une attaque par hameçonnage (phishing).

1. Formations et campagnes de simulation d’hameçonnage régulières.
2. Diffuser des réflexes simples : vérifier l’expéditeur et les liens, ne jamais communiquer ses identifiants, signaler tout message suspect au service informatique.

Selon l’attaque décrite par le ticket, deux mesures préventives adaptées — par exemple mises à jour/correctifs des composants exposés et filtrage/durcissement des accès (politique « tout interdit par défaut », authentification forte) — afin d’empêcher la réédition de l’incident.

Ajouter, en plus des alertes à 3 mois et 1 mois avant l’expiration, un rappel supplémentaire à 1 semaine avant la date d’expiration : on ajoute une condition testant si la date courante atteint « date d’expiration − 7 jours » et, le cas échéant, on déclenche l’alerte.

Mission C2 — Analyse de traces

L’analyse du fichier auth.log (nombreuses tentatives d’authentification échouées puis une réussie) révèle une attaque par force brute (brute force) sur l’authentification.

1. Des mots de passe faibles (devinables).
2. Aucun verrouillage du compte après échecs répétés (et pas de MFA) → l’attaquant peut essayer indéfiniment.

• Confidentialité : accès et fuite des données (clients, ventes) une fois le compte compromis.
• Intégrité : modification frauduleuse des données (privilèges, contenus).
• Disponibilité : blocage/altération du service (suppression de données, indisponibilité du site).

a) Doivent être informés : la CNIL (sous 72 h) et les personnes concernées si le risque est élevé.

b) La fuite doit être consignée dans le registre des violations de données.

c) Pour préserver l’intégrité des preuves : conserver les journaux sans les modifier (copie en lecture seule, horodatage/empreinte/hachage des fichiers) et isoler les systèmes concernés en l’état pour l’enquête.

REVOKE ALL PRIVILEGES, GRANT OPTION
ON pucesin.* FROM 'compte_compromis'@'%';

(On retire ensuite/recrée le compte avec les seuls droits légitimes.)

Mission C3 — Sécuriser l’accès à la base

a) Créer le compte statistiques, limité à l’adresse 95.10.2.54, en lecture seule sur les seules tables utiles aux statistiques :

CREATE USER 'statistiques'@'95.10.2.54' IDENTIFIED BY '<mot_de_passe_fort>';
GRANT SELECT ON pucesin.Livre        TO 'statistiques'@'95.10.2.54';
GRANT SELECT ON pucesin.Publication  TO 'statistiques'@'95.10.2.54';
-- (uniquement les tables nécessaires aux statistiques)

b) Solution technique différente : exposer aux statistiques une vue SQL (ou un rôle) ne contenant que les colonnes/tables utiles → le compte n’accède qu’à cette vue, jamais aux données complètes.