Comment un site reconnaît un utilisateur connecté, puis les attaques qui visent ce mécanisme - empoisonnement de cookie (cookie poisoning), vol de session (session hijacking), fixation de session - et les parades - données en session côté serveur, identifiant régénéré, cookies HttpOnly, Secure et SameSite, HTTPS, expiration.
Après la connexion, ce n'est plus le mot de passe qui prouve votre identité : c'est un petit identifiant rangé dans un cookie. Celui qui le possède EST vous pour le site. Les attaquants ne cherchent donc pas toujours à deviner un mot de passe : il leur suffit souvent de voler, de fabriquer ou d'imposer ce jeton.
Après la connexion, le serveur donne au navigateur un cookie PHPSESSID : c'est le badge de la session.
Rappel du module 07 : après la connexion, PHP range les informations dans une session sur le serveur, et le navigateur reçoit un cookie PHPSESSID qui contient seulement un identifiant aléatoire. À chaque requête, ce cookie est renvoyé et désigne la bonne session.
Trois attaques en découlent : fabriquer une fausse information dans un cookie, voler le jeton, ou imposer un jeton connu.
Les moyens les plus courants :
document.cookie et l’envoie au pirate (leçon A.4) ;page.php?PHPSESSID=...), donc dans l’historique et les journaux ;Parades : cookie HttpOnly (illisible par JavaScript), Secure et site entièrement en HTTPS, sessions qui expirent après inactivité, et déconnexion réelle (session_destroy()).
La parade tient en une ligne, juste après la vérification du mot de passe :
session_regenerate_id(true); // nouvel identifiant, l'ancien est supprimé
| Option | Effet | Protège contre |
|---|---|---|
HttpOnly | JavaScript ne peut pas lire le cookie | vol par XSS |
Secure | envoyé uniquement en HTTPS | écoute du réseau |
SameSite=Lax | pas envoyé par les requêtes venant d’autres sites (sauf un simple lien) | CSRF |
| durée courte + expiration côté serveur | un jeton volé ne sert pas longtemps | vol, poste partagé |
À l'entrée du festival, on montre son billet une fois et on reçoit un bracelet. Ensuite, c'est le bracelet qui ouvre les portes. Si quelqu'un vole le bracelet, ou en fabrique un faux « VIP » au feutre, les vigiles le laisseront passer, à moins de vérifier le bracelet sur leur liste.
Un inconnu vous donne une clé de casier « déjà ouverte pour vous ». Vous y rangez vos affaires... mais il a gardé un double. C'est la fixation de session : l'attaquant impose un identifiant qu'il connaît.
La page s'affichera ici.
Le navigateur demandera /connexion.php au serveur, qui exécutera le PHP et renverra du HTML.
Consignes 0 / 4
Écrivez le réglage du cookie de session pour un site en HTTPS : illisible par JavaScript, envoyé uniquement en HTTPS, pas envoyé par les requêtes venant d'autres sites (sauf liens simples), valable jusqu'à la fermeture du navigateur.
<?php session_set_cookie_params([ 'lifetime' => 0, // jusqu'à la fermeture du navigateur 'path' => '/', 'secure' => true, // uniquement en HTTPS 'httponly' => true, // invisible pour document.cookie 'samesite' => 'Lax', ]); session_start();
Déconnectez automatiquement un utilisateur inactif depuis plus de 15 minutes.
<?php session_start(); $limite = 15 * 60; if (isset($_SESSION['derniere_action']) && time() - $_SESSION['derniere_action'] > $limite) { $_SESSION = []; session_destroy(); header('Location: connexion.php?expire=1'); exit; } $_SESSION['derniere_action'] = time();
On veut garder la langue préférée dans un cookie, mais être sûr qu'il n'a pas été modifié. Proposez une méthode avec hash_hmac.
<?php const SECRET = 'une-longue-cle-aleatoire-gardee-sur-le-serveur'; function cookieSigne(string $nom, string $valeur): void { $sig = hash_hmac('sha256', $valeur, SECRET); setcookie($nom, "$valeur.$sig", ['path' => '/', 'httponly' => true, 'samesite' => 'Lax']); } function lireCookieSigne(string $nom): ?string { [$valeur, $sig] = explode('.', $_COOKIE[$nom] ?? '.', 2) + [1 => '']; return hash_equals(hash_hmac('sha256', $valeur, SECRET), $sig) ? $valeur : null; }