Exercices PHP corrigés type E6 et E7

Lignes 2, 4 et 10. L'identifiant de l'employé vient de l'URL (ligne 4) et sert directement de critère (ligne 10). En le changeant, l'employé voit les réservations de l'employé 3, et peut essayer tous les numéros. C'est une référence directe non sécurisée à un objet (IDOR), une forme de contrôle d'accès défaillant (A01 du Top 10 de l'OWASP). Et rien ne vérifie que l'utilisateur est connecté : la ligne 2 démarre la session mais ne la teste jamais, donc une personne non connectée voit aussi les réservations.

Correction : l'identifiant se lit dans la session, après avoir vérifié la connexion.

4  $utilisateur = exigerConnexion();       // redirige vers la connexion sinon
4' $id = $utilisateur['id'];               // jamais l'URL

Injection SQL, lignes 4, 10 et 11. $id vient de l'URL et est concaténé dans le texte de la requête, exécutée par query(). Une valeur qui n'est pas un nombre, mais un morceau de SQL, modifie la requête : elle peut rendre la condition toujours vraie (toutes les réservations de tous les employés) ou ajouter un UNION SELECT qui lit d'autres tables, comme utilisateur et ses empreintes de mots de passe.

 8  $stmt = $pdo->prepare('SELECT r.id, m.reference, r.date_debut, r.commentaire
 9      FROM reservation r JOIN materiel m ON m.id = r.id_materiel
10      WHERE r.id_utilisateur = :id ORDER BY r.date_debut');
11  $stmt->execute(['id' => $utilisateur['id']]);
11' $reservations = $stmt->fetchAll();

Avec l'identifiant lu en session (question 1), la valeur n'est plus une saisie ; la requête préparée reste la règle, pour toute valeur (chapitre 7).

1. Injection SQL, ligne 6 : $_GET['annuler'] est concaténé dans un DELETE. Une condition injectée peut supprimer toutes les réservations.
2. Contrôle d'accès, ligne 6 : le DELETE ne vérifie pas que la réservation appartient à l'utilisateur. N'importe qui peut annuler les réservations des autres en changeant le numéro.
3. Modification en GET et CSRF, lignes 5 et 16 : l'annulation se fait par un simple lien. Une page piégée, une image dont l'adresse pointe vers ce lien, ou un robot qui suit les liens, déclenche l'annulation au nom de l'employé connecté, sans jeton pour l'en empêcher.
4. Pas de redirection après l'action : actualiser la page relance l'annulation, et l'adresse avec annuler= reste dans l'historique.

Traitement corrigé, en tête de page :

<?php
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    verifierCsrf();
    $idReservation = filter_input(INPUT_POST, 'annuler', FILTER_VALIDATE_INT, ['options' => ['min_range' => 1]]);
    if (is_int($idReservation)) {
        $stmt = $pdo->prepare('DELETE FROM reservation WHERE id = :id AND id_utilisateur = :utilisateur');
        $stmt->execute(['id' => $idReservation, 'utilisateur' => $utilisateur['id']]);
        flash($stmt->rowCount() === 1 ? 'succes' : 'erreur',
              $stmt->rowCount() === 1 ? 'Réservation annulée.' : 'Réservation introuvable.');
    }
    header('Location: /reservations.php', true, 303);
    exit;
}

Affichage corrigé de la ligne 16, un formulaire POST avec le jeton :

<form method="post">
  <?= champCsrf() ?>
  <button name="annuler" value="<?= e($r['id']) ?>">Annuler</button>
</form>

La condition AND id_utilisateur = :utilisateur règle le contrôle d'accès dans la requête elle-même : une réservation d'un autre employé n'est tout simplement pas trouvée.

• $r['commentaire'] (ligne 15) : saisi par un employé et enregistré en base, puis affiché à chaque consultation. C'est une XSS stockée, la plus grave ici : un commentaire contenant du script s'exécute dans le navigateur de quiconque affiche la page, y compris le gestionnaire.
• $id (ligne 16) : vient de l'URL et est réinséré dans la page, dans un attribut href. C'est une XSS réfléchie (et la question 1 supprime déjà ce paramètre).
• $r['reference'] et $r['date_debut'] : viennent de la base, saisis par le gestionnaire ou produits par l'application ; risque faible, mais la règle est d'échapper toute donnée.
• $_SESSION['nom'] (ligne 13) : saisi par le gestionnaire à la création du compte ; risque faible, même règle.

13  <h1>Réservations de <?= e($utilisateur['nom']) ?></h1>
15    <p><?= e($r['reference']) ?> le <?= e($r['date_debut']) ?> : <?= e($r['commentaire']) ?></p>

e() est la fonction courte du chapitre 5, qui appelle htmlspecialchars().

« La page présente quatre vulnérabilités qui interdisent sa mise en production. Par ordre de gravité : deux injections SQL (lignes 6 et 10), qui exposent toute la base ; un contrôle d'accès défaillant (lignes 4 et 6), qui permet de consulter et d'annuler les réservations des autres employés sans même être connecté ; une XSS stockée par le commentaire (ligne 15) ; une CSRF sur l'annulation en GET (ligne 16). Les corrections sont simples : requêtes préparées, identifiant lu en session, échappement à l'affichage, annulation en POST avec jeton. Mesure générale : faire passer toutes les pages par le contrôleur frontal, qui vérifie la connexion et le jeton CSRF, et ajouter une revue de code avant chaque mise en production. »

CREATE TABLE reservation (
  id INT AUTO_INCREMENT PRIMARY KEY,
  id_materiel INT NOT NULL,
  id_utilisateur INT NOT NULL,
  date_debut DATE NOT NULL,
  date_fin DATE NOT NULL,
  commentaire VARCHAR(255) NULL,
  CONSTRAINT fk_reservation_materiel FOREIGN KEY (id_materiel) REFERENCES materiel (id),
  CONSTRAINT fk_reservation_utilisateur FOREIGN KEY (id_utilisateur) REFERENCES utilisateur (id),
  CONSTRAINT ck_reservation_dates CHECK (date_fin >= date_debut),
  INDEX idx_reservation_materiel_dates (id_materiel, date_debut, date_fin)
);

La contrainte CHECK refuse une période à l'envers ; l'index accélère la recherche des chevauchements, faite à chaque réservation. Le non-chevauchement, lui, ne s'exprime pas par une contrainte simple dans MySQL : il se vérifie dans le code, dans une transaction.

Deux périodes se chevauchent quand chacune commence avant que l'autre se termine :

SELECT COUNT(*) FROM reservation
WHERE id_materiel = :materiel AND date_debut <= :fin AND date_fin >= :debut

Cette condition couvre tous les cas (chevauchement à gauche, à droite, inclusion, englobement) d'un seul coup. Les dates de fin sont incluses (on rend le matériel le soir) : d'où <= et >=. La vérifier à la main sur les cinq demandes du tableau est un bon réflexe avant de coder.

<?php
declare(strict_types=1);

final class ReservationImpossible extends RuntimeException
{
}

function reserver(PDO $pdo, int $idMateriel, int $idUtilisateur,
                  DateTimeImmutable $debut, DateTimeImmutable $fin, ?string $commentaire): int
{
    $pdo->beginTransaction();
    try {
        // Verrou sur le matériel : deux réservations simultanées passent l'une après l'autre
        $stmt = $pdo->prepare('SELECT etat FROM materiel WHERE id = :id FOR UPDATE');
        $stmt->execute(['id' => $idMateriel]);
        $etat = $stmt->fetchColumn();
        if ($etat === false || $etat === 'reforme') {
            throw new ReservationImpossible('Ce matériel ne peut pas être réservé.');
        }

        $stmt = $pdo->prepare(
            'SELECT COUNT(*) FROM reservation
             WHERE id_materiel = :materiel AND date_debut <= :fin AND date_fin >= :debut'
        );
        $stmt->execute([
            'materiel' => $idMateriel,
            'debut' => $debut->format('Y-m-d'),
            'fin' => $fin->format('Y-m-d'),
        ]);
        if ((int) $stmt->fetchColumn() > 0) {
            throw new ReservationImpossible('Ce matériel est déjà réservé sur une partie de ces dates.');
        }

        $stmt = $pdo->prepare(
            'INSERT INTO reservation (id_materiel, id_utilisateur, date_debut, date_fin, commentaire)
             VALUES (:materiel, :utilisateur, :debut, :fin, :commentaire)'
        );
        $stmt->execute([
            'materiel' => $idMateriel,
            'utilisateur' => $idUtilisateur,
            'debut' => $debut->format('Y-m-d'),
            'fin' => $fin->format('Y-m-d'),
            'commentaire' => $commentaire,
        ]);
        $id = (int) $pdo->lastInsertId();

        $pdo->commit();
        return $id;
    } catch (Throwable $e) {
        $pdo->rollBack();
        throw $e;
    }
}

C'est la même structure que emprunter() (chapitre 8) : verrou FOR UPDATE sur la ligne du matériel, vérifications, insertion, validation. Sans le verrou, deux employés pourraient passer la vérification du chevauchement en même temps, puis insérer chacun leur réservation. Les dates (fin après début, début dans le futur) se valident avant l'appel, dans le contrôleur ; la contrainte CHECK de la table est le filet de sécurité.

<?php
public function reserver(int $id): void
{
    $utilisateur = exigerConnexion();     // le jeton CSRF est vérifié par le contrôleur frontal

    $aujourdhui = new DateTimeImmutable('today');
    $debut = lireDate($_POST, 'date_debut');
    $fin = lireDate($_POST, 'date_fin');
    $commentaire = mb_substr(texte($_POST, 'commentaire'), 0, 255);

    if ($debut === null || $fin === null || $debut < $aujourdhui || $fin < $debut) {
        flash('erreur', 'Choisis une période future, la fin après le début.');
        rediriger("/materiels/$id");
    }

    try {
        reserver(bdd(), $id, $utilisateur['id'], $debut, $fin, $commentaire === '' ? null : $commentaire);
        flash('succes', 'Réservation enregistrée.');
    } catch (ReservationImpossible $e) {
        flash('erreur', $e->getMessage());
    }
    rediriger("/materiels/$id");
}

Les tests à montrer (la recette) :

1. Une réservation valide sur un matériel libre : message de succès, ligne en base.
2. Une réservation qui chevauche une réservation existante (du 12 au 14 si le 10-12 existe) : refus avec le message.
3. Une réservation accolée (du 13 au 15) : acceptée.
4. Un matériel réformé (PC-0087) : refus.
5. Une période à l'envers ou dans le passé : refus par la validation.
6. Un commentaire contenant des balises HTML : affiché en texte sur la page des réservations.
7. Un utilisateur non connecté qui envoie la requête : redirigé vers la connexion.

Annonce les tests avant de les jouer, et montre les cas limites (3 et 2) : c'est ce qui convainc la commission que tu as compris la règle, pas seulement écrit du code (la recette de l'E6).

1. Affectation au lieu d'une comparaison : = affecte 'gestionnaire' au rôle et la condition est toujours vraie. Pire, l'affectation est enregistrée dans la session : l'utilisateur reste gestionnaire jusqu'à sa déconnexion. Écrire === 'gestionnaire'.
2. Tableau mal formé : [':id', $id] est une liste de deux valeurs, pas une association. Erreur SQLSTATE[HY093]: Invalid parameter number. Écrire ['id' => $id].
3. exit manquant après header() : la redirection est envoyée, mais le script continue et supprime le matériel. Ajouter exit; (ou utiliser rediriger(), de type never). Une réponse 403 serait d'ailleurs plus juste qu'une redirection.
4. password_verify() mal utilisé : il attend le mot de passe en clair et l'empreinte stockée. Hacher le mot de passe d'abord produit une nouvelle empreinte, avec un autre sel : la vérification échoue toujours. Écrire password_verify($motDePasse, $u['mot_de_passe']).
5. fetch() dans un foreach : fetch() renvoie une ligne, et la boucle parcourt ses colonnes. Seule la première référence s'affiche. Écrire foreach ($stmt as $m) ou foreach ($stmt->fetchAll() as $m), puis echo e($m['reference']).
6. fetch() renvoie un tableau (la ligne), pas la valeur : PHP affiche « Array matériels » avec l'avertissement « Array to string conversion ». Écrire $nb = (int) $pdo->query('SELECT COUNT(*) FROM materiel')->fetchColumn();.