Épreuve blanche E7 n° 2 : une coopérative agricole et sa boutique en ligne

A1.1. La ligne 8 est remplacée par :

8.  if (!empty($_POST['compte'])) {
8a.     $conditions[] = 'log_user = :compte';
8b.     $parametres[':compte'] = $_POST['compte'];
8c. }

Le compte est transmis comme valeur liée, jamais concaténé dans la requête : la liste déroulante peut être modifiée par l'utilisateur, la requête préparée le neutralise.

A1.2 a) Journal. Le compte se connecte depuis l'adresse 203.0.113.45 (ligne de 23:12:40), qui n'est pas le serveur local (localhost, 127.0.0.1). Il lit la table système mysql.user (23:13:02), qui contient les comptes et les empreintes de leurs mots de passe, et il supprime une table (DROP TABLE Paiement_2025, 23:14:15) : deux opérations qui dépassent la lecture et la modification de lignes.

A1.2 b) Habilitations. L'hôte % autorise la connexion depuis n'importe quelle adresse. ALL PRIVILEGES ON *.* donne tous les privilèges sur toutes les bases du serveur, y compris la base système mysql, DROP et la création de comptes.

A1.2 c) Requêtes.

RENAME USER 'vertanet_web'@'%' TO 'vertanet_web'@'localhost';
REVOKE ALL PRIVILEGES ON *.* FROM 'vertanet_web'@'localhost';
GRANT SELECT, INSERT, UPDATE, DELETE ON vertanet.* TO 'vertanet_web'@'localhost';
ALTER USER 'vertanet_web'@'localhost' IDENTIFIED BY 'nouveau_mot_de_passe_long_et_aleatoire';

Le REVOKE vise le niveau global *.*, celui où les privilèges ont été accordés. Le changement de mot de passe s'impose : l'attaquant le connaît. Il faut ensuite mettre à jour la configuration de VertaNet et restaurer la table supprimée depuis la dernière sauvegarde.

A1.3. Le mot de passe du compte est écrit en clair dans le code source (ligne 3). Il est lisible par toute personne qui accède au code : dépôt Git, poste d'un développeur, sauvegarde, ancien prestataire. Correction : le placer dans une variable d'environnement ou un fichier de configuration hors de la racine Web et exclu du dépôt, lu par getenv() ou $_ENV ; changer le mot de passe, puisqu'il a pu circuler. C'est une mauvaise configuration de sécurité (A05:2021).

A2.1. Oui. La plupart des adhérents sont des exploitants individuels : l'IBAN de leur compte se rapporte à une personne physique identifiée. C'est une donnée à caractère personnel, et une donnée financière à protéger particulièrement, même si elle ne fait pas partie des données sensibles de l'article 9 du RGPD. Autres données personnelles : nomGerant, prenomGerant, telephone, mel ; le siret, la raisonSociale, la surfaceHa et la certificationBio d'une exploitation individuelle permettent aussi d'identifier l'exploitant, donc le deviennent indirectement.

A2.2.

ALTER TABLE Adherent MODIFY iban VARBINARY(64);
UPDATE Adherent SET iban = AES_ENCRYPT(iban, 'Vrt#2027!k9');

A2.3. Ligne 2 modifiée et une ligne ajoutée :

2.  $sql = "SELECT raisonSociale, CAST(AES_DECRYPT(iban, :cle) AS CHAR) AS iban
            FROM Adherent WHERE id = :id";
4a. $stmt->bindValue(':cle', $_ENV['AES_KEY'], PDO::PARAM_STR);

L'alias AS iban conserve la clé de tableau attendue par le code appelant. La clé de chiffrement est passée en paramètre, jamais écrite dans le code.

A2.4. Le hachage est irréversible : une fois haché, l'IBAN ne pourrait plus jamais être relu, alors que la coopérative en a besoin chaque mois pour verser les paiements. password_hash() convient aux mots de passe, qu'on vérifie sans les relire. Pour une donnée qu'il faut retrouver en clair, la bonne mesure est le chiffrement, avec une clé protégée et distincte de la base.

A3.1. Une proposition, en schéma relationnel :

Delegation (id, idCompte, idFonctionnalite, idDelegant, dateDebut, dateFin)
    clé primaire : id
    idCompte : clé étrangère en référence à id de Compte (bénéficiaire)
    idFonctionnalite : clé étrangère en référence à id de Fonctionnalite
    idDelegant : clé étrangère en référence à id de Compte (qui accorde)

La table Habilitation n'est pas modifiée : les droits permanents restent séparés. Chaque délégation est une ligne datée qui n'est jamais supprimée à son expiration : l'historique est conservé. Une clé primaire technique (id) permet d'accorder plusieurs fois la même délégation à des périodes différentes. Contrôles à prévoir : dateFin >= dateDebut (contrainte CHECK), et le délégant doit lui-même posséder la fonctionnalité qu'il délègue (déclencheur ou contrôle applicatif).

A3.2.

SELECT f.libelle
FROM Habilitation h
JOIN Fonctionnalite f ON f.id = h.idFonctionnalite
WHERE h.idCompte = 2
UNION
SELECT f.libelle
FROM Delegation d
JOIN Fonctionnalite f ON f.id = d.idFonctionnalite
WHERE d.idCompte = 2
  AND CURDATE() BETWEEN d.dateDebut AND d.dateFin;

UNION supprime les doublons : si une délégation porte sur une fonctionnalité que le compte possède déjà, elle n'apparaît qu'une fois. UNION ALL la montrerait deux fois. Exemple : un compte qui possède en permanence « Consulter les adhérents » et « Saisir une collecte », avec une délégation en cours sur « Valider un paiement », une autre en cours sur « Consulter les adhérents » et une délégation expirée sur « Modifier un IBAN », obtient trois libellés : les deux permanents et « Valider un paiement ».

B1.1. C'est un XSS stocké (cross-site scripting), qui relève de l'injection (A03:2021). Le script est enregistré en base avec l'avis ; à chaque affichage de la page, il est renvoyé tel quel et le navigateur de chaque visiteur l'exécute (ici, une redirection vers un site publicitaire ; il pourrait aussi voler des cookies de session). Un XSS reflété ne touche que les personnes qui cliquent sur un lien piégé contenant le script ; le XSS stocké touche tous les visiteurs de la page produit, sans action de leur part, tant que l'avis n'est pas supprimé.

B1.2. Lignes 4 et 5 modifiées :

4.     echo '<div class="avis"><strong>' . htmlspecialchars($avis['pseudo'], ENT_QUOTES, 'UTF-8') . '</strong> ';
5.     echo (int) $avis['note'] . '/5<p>' . htmlspecialchars($avis['texte'], ENT_QUOTES, 'UTF-8') . '</p></div>';

htmlspecialchars transforme < et > en entités : le navigateur affiche <script> comme du texte au lieu de l'exécuter. Le pseudo est aussi une saisie de client : il doit être échappé. La note est forcée en entier. Il faut ensuite supprimer l'avis malveillant de la base.

B1.3. Le filtrage à l'enregistrement ne suffit pas : des données ont pu être enregistrées avant sa mise en place (c'est le cas ici), d'autres applications ou une API peuvent écrire dans la même table, et un filtre d'entrée peut être contourné par une forme d'écriture qu'il n'a pas prévue. L'échappement à l'affichage protège quelle que soit l'origine de la donnée, et il est adapté au contexte (HTML ici). Les deux mesures se complètent : c'est la défense en profondeur.

B2.1. C'est une attaque CSRF (cross-site request forgery, falsification de requête intersite). L'attaquant publie sur un autre site, ou envoie par courriel, une page contenant un formulaire caché qui envoie mel=attaquant@exemple.net vers traiter_mel.php et se soumet automatiquement. Si la victime est connectée à Panier Vertalis, son navigateur joint son cookie de session : le serveur voit une requête authentifiée et change l'adresse du compte. L'attaquant utilise ensuite « mot de passe oublié » : le lien de réinitialisation arrive dans sa boîte, il choisit un nouveau mot de passe et prend le compte (adresses, historique de commandes).

B2.2.

Dans mon_compte.php, avant la ligne 1 (ajout, 0a à 0c) et après la ligne 2 (ajout, 2a) :

0a. <?php if (empty($_SESSION['jetonCsrf'])) {
0b.     $_SESSION['jetonCsrf'] = bin2hex(random_bytes(32));
0c. } ?>
2a.     <input type="hidden" name="jeton" value="<?= htmlspecialchars($_SESSION['jetonCsrf']) ?>">

Dans traiter_mel.php, après la ligne 2 (ajout, 2a à 2c) :

2a. if (!isset($_POST['jeton']) || !hash_equals($_SESSION['jetonCsrf'] ?? '', $_POST['jeton'])) {
2b.     http_response_code(403); exit('Requête refusée');
2c. }

Le site de l'attaquant ne peut pas lire le jeton, aléatoire et propre à la session : sa requête forgée est refusée. hash_equals compare en temps constant. Mesures complémentaires : cookie de session SameSite=Lax, demande du mot de passe actuel pour modifier l'adresse, courriel d'alerte envoyé à l'ancienne adresse.

B3.1. L'algorithme est MD5 (empreinte de 32 caractères hexadécimaux, fonction md5()). C'est une défaillance cryptographique (A02:2021). MD5 est cassé et extrêmement rapide : un processeur graphique teste des milliards de mots de passe par seconde, et des tables précalculées donnent instantanément les mots de passe courants. Sans sel, deux clients qui ont le même mot de passe ont la même empreinte.

B3.2.

$stmt = $pdo->prepare("SELECT id, mdp FROM Client WHERE mel = :mel");
$stmt->execute([':mel' => $mel]);
$client = $stmt->fetch(PDO::FETCH_ASSOC);
$authentifie = false;
if ($client) {
    if (password_verify($mdp, $client['mdp'])) {
        $authentifie = true;                       // empreinte déjà migrée
    } elseif (preg_match('/^[a-f0-9]{32}$/', $client['mdp'])
              && hash_equals($client['mdp'], md5($mdp))) {
        $authentifie = true;                       // ancienne empreinte MD5 correcte
        $maj = $pdo->prepare("UPDATE Client SET mdp = :mdp WHERE id = :id");
        $maj->execute([':mdp' => password_hash($mdp, PASSWORD_DEFAULT), ':id' => $client['id']]);
    }
}
if ($authentifie) {
    session_regenerate_id(true);
    $_SESSION['idClient'] = $client['id'];
}

On ne peut recalculer une empreinte moderne qu'au moment où l'on connaît le mot de passe en clair, c'est-à-dire lors d'une connexion réussie. La colonne mdp doit être élargie (VARCHAR(255)) avant la migration.

B3.3. Les empreintes MD5 restantes sont toujours vulnérables. Il faut fixer une date limite au-delà de laquelle les comptes non migrés sont invalidés : leur empreinte est effacée et le client doit réinitialiser son mot de passe par courriel. Comme les empreintes MD5 ont pu être exposées (la base a été manipulée), il est prudent d'informer les clients et de leur conseiller de changer ce mot de passe s'ils l'utilisent ailleurs.

B4.1. C'est un contrôle d'accès défaillant (A01:2021, référence directe non sécurisée). La requête cherche la facture par son seul numéro, sans vérifier qu'elle appartient au client connecté. Comme les numéros se suivent, un client remplace F2027-00418 par F2027-00417, F2027-00416… et lit les factures des autres clients, avec leur adresse de livraison. Si la faille a été exploitée, c'est une violation de données à caractère personnel : Vertalis, responsable de traitement, doit la documenter et la notifier à la CNIL dans les meilleurs délais, si possible sous 72 heures, puisqu'elle présente un risque pour les personnes (article 33 du RGPD) ; Kodex, sous-traitant, doit l'en informer dans les meilleurs délais (article 33, paragraphe 2).

B4.2.

2a. if (!isset($_SESSION['idClient'])) { header('Location: connexion.php'); exit; }
4.                        FROM Facture WHERE numero = ? AND idClient = ?");
5. $stmt->execute([$num, $_SESSION['idClient']]);
6a. if (!$facture) { http_response_code(404); exit('Facture introuvable'); }

L'appartenance est vérifiée dans la requête, avec l'identifiant du client pris dans la session. Répondre 404 plutôt que 403 évite de confirmer l'existence d'une facture d'un autre client ; les deux réponses sont défendables.