E7 SLAM : méthode et sujet corrigé

1. Confidentialité : 3 (important). Les fiches contiennent des données personnelles (déplacements, donc localisation et habitudes) et des données financières ; l'IBAN est chiffré, ce qui limite l'impact d'une fuite, mais les montants et les déplacements restent exposés. On peut défendre 4 si l'IBAN était en clair. Intégrité : 4 (critique). Une modification frauduleuse d'un montant ou d'un état entraîne directement un paiement indu ; les fiches sont aussi des pièces comptables. Ce qui compte est la justification liée au contexte, plus que le chiffre lui-même.
2. C'est une violation de données à caractère personnel (atteinte à la confidentialité). Le laboratoire, responsable de traitement, doit : la documenter dans son registre des violations ; la notifier à la CNIL dans les 72 heures après en avoir pris connaissance, sauf si elle n'est pas susceptible d'engendrer un risque pour les personnes (article 33), ce qui est difficile à soutenir ici ; informer les visiteurs concernés si le risque pour eux est élevé (article 34) ; et bien sûr corriger la faille. Le délégué à la protection des données (DPO), s'il existe, pilote ces démarches.

1. Par exemple :
   • Ligne 5 : la saisie $login est concaténée dans la requête : injection SQL (A05). Avec admin' -- , l'attaquant se connecte sans mot de passe ; il peut aussi lire la base.
   • Ligne 4 : empreinte SHA-1 sans sel (A04) : en cas de vol de la base, les mots de passe sont retrouvés en masse (tables précalculées, force brute rapide).
   • Ligne 12 : le login est affiché sans encodage : XSS réfléchie (A05). Le message révèle aussi que le compte existe (énumération), et la session n'est pas régénérée à la connexion (fixation de session, A07). Aucune limite de tentatives n'est visible (A07).
2. Une version corrigée :

<?php
session_start();
$login = $_POST['login'] ?? '';
$mdp = $_POST['mdp'] ?? '';
$stmt = $pdo->prepare('SELECT id, role, mdp_hash FROM utilisateur WHERE login = :login AND actif = 1');
$stmt->execute(['login' => $login]);
$utilisateur = $stmt->fetch(PDO::FETCH_ASSOC);
if ($utilisateur && password_verify($mdp, $utilisateur['mdp_hash'])) {
    session_regenerate_id(true);
    $_SESSION['id'] = $utilisateur['id'];
    $_SESSION['role'] = $utilisateur['role'];
    journaliser($pdo, $login, 'connexion', 'succes');
    header('Location: accueil.php');
    exit;
}
journaliser($pdo, $login, 'connexion', 'echec');
echo 'Identifiant ou mot de passe incorrect';

La fonction journaliser insère une ligne dans journal avec une requête préparée. On ajoute une limitation des tentatives (par compte et par adresse IP) avant la vérification.

3. Le chiffrement est réversible : avec la clé, qui doit bien se trouver quelque part sur le serveur, on retrouve tous les mots de passe. Or on n'a jamais besoin de relire un mot de passe, seulement de le vérifier. Il faut un hachage lent et salé conçu pour les mots de passe : password_hash (bcrypt, ou Argon2id avec PASSWORD_ARGON2ID).
4. À chaque connexion réussie vérifiée avec l'ancienne empreinte (hash_equals(sha1($mdp), $utilisateur['mdp_hash'])), on recalcule l'empreinte avec password_hash($mdp, PASSWORD_DEFAULT) et on l'enregistre. Au bout d'une période fixée, les comptes encore en SHA-1 sont désactivés et leurs titulaires réinitialisent leur mot de passe. On peut aussi, dès le départ, envelopper les empreintes existantes : stocker password_hash(sha1_existant), pour ne plus laisser de SHA-1 nu en base.

1. On parcourt les droits du profil et on renvoie true dès qu'un droit correspond à la table et à l'opération :

public boolean estAutorise(String uneTable, String uneOperation) {
    if (!this.actif || this.leProfil == null) {
        return false;
    }
    for (Droit unDroit : this.leProfil.getLesDroits()) {
        if (unDroit.getNomTable().equals(uneTable) && unDroit.getOperation().equals(uneOperation)) {
            return true;
        }
    }
    return false;
}

equals compare le contenu des chaînes (== comparerait les références). Le return false final applique le refus par défaut.

2. Par exemple :
   • estAutorise("fiche_frais", "update") renvoie true : droit présent ;
   • estAutorise("fiche_frais", "delete") renvoie false : table connue, opération non accordée ;
   • estAutorise("utilisateur", "select") renvoie false : table absente des droits ;
   • (quatrième cas utile) un utilisateur du même profil mais inactif : estAutorise("fiche_frais", "select") renvoie false.
3. La requête :

SELECT login, COUNT(*) AS nb_echecs
FROM journal
WHERE action = 'connexion'
  AND resultat = 'echec'
  AND date_heure >= '2026-03-14 00:00:00'
  AND date_heure < '2026-03-15 00:00:00'
GROUP BY login
HAVING COUNT(*) >= 3;

pbernard et sroux n'ont qu'un échec chacun ce jour-là.

4. Elle ne renvoie aucune ligne : comparée à un DATETIME, la chaîne '2026-03-14' vaut 2026-03-14 00:00:00. La condition ne retient que les événements survenus exactement à minuit. Il faut un intervalle semi-ouvert (>= '2026-03-14' et < '2026-03-15'), ou DATE(date_heure) = '2026-03-14' (plus lisible, mais qui empêche l'utilisation d'un index sur date_heure).
5. Depuis une adresse externe (203.0.113.9), le soir, quatre échecs en moins de deux minutes sur cpetit, puis un essai sur sroux : une tentative de force brute suivie d'un essai sur un autre compte, sans succès. La connexion réussie de cpetit le lendemain matin vient du réseau interne : c'est sans doute la vraie titulaire. Recommandations : limiter les tentatives par compte et par adresse IP, alerter sur ce type de séquence, bloquer temporairement l'adresse, prévenir les titulaires, envisager la MFA, et vérifier qu'aucune autre adresse n'a obtenu de succès sur ces comptes.

1. Elle n'effectue aucun contrôle : ni authentification, ni rôle, ni état de la fiche. N'importe qui peut supprimer n'importe quelle fiche, y compris une fiche validée ou remboursée (atteinte à l'intégrité et à la disponibilité des données, et à la preuve comptable). La méthode DELETE est irréversible. Rien n'est journalisé.
2. Une version corrigée :

public function supprimer(int $id): void {
    if (!isset($_SESSION['id'])) {
        $this->repondre(401);
        return;
    }
    if ($_SESSION['role'] !== 'comptable') {
        $this->repondre(403);
        return;
    }
    $stmt = $this->pdo->prepare("DELETE FROM fiche_frais WHERE id = ? AND etat = 'CR'");
    $stmt->execute([$id]);
    if ($stmt->rowCount() === 0) {
        $this->repondre(404, ['erreur' => 'Fiche introuvable ou non supprimable']);
        return;
    }
    $this->journaliser($_SESSION['id'], 'suppression_fiche', "fiche:$id");
    $this->repondre(204);
}

Le return après chaque refus empêche d'exécuter la suite. On peut renvoyer 409 plutôt que 404 quand la fiche existe mais n'est plus à l'état CR, au prix d'une requête de plus.

3. Une API distincte en lecture seule applique la réduction de la surface d'attaque et le moindre privilège : elle n'expose que des routes GET de statistiques agrégées, sans données personnelles, avec un compte de base qui n'a que des droits de lecture (au mieux sur une vue d'agrégats). Une faille dans cette API ne permet ni de modifier des données, ni d'atteindre les fiches individuelles. Ouvrir une route de l'API existante obligerait à gérer une exception « publique » au milieu de routes authentifiées, source d'erreurs, et exposerait sur Internet un code qui donne accès à toutes les données.

1. Une XSS stockée (cross-site scripting, A05:2025) : le libellé enregistré en base est affiché sans encodage dans la page du comptable, et le script s'exécute dans son navigateur.
2. L'encodage des sorties corrige la cause : htmlspecialchars($ligne['libelle'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8') à l'affichage (ou un moteur de gabarits qui encode par défaut). L'attribut HttpOnly sur le cookie de session empêche le script de le lire. Une CSP stricte (script-src 'self', sans 'unsafe-inline') bloque l'exécution de scripts injectés. On peut ajouter une validation du libellé à l'entrée (longueur, caractères attendus), qui réduit la surface d'attaque sans remplacer l'encodage.