Invalider cookies et sessions après un piratage

Pourquoi le mot de passe ne suffit pas

La session est un jeton déjà émis. Tant qu'il est valide, le navigateur de l'attaquant (ou le plugin voleur) continue. Changer le mot de passe sans invalider, c'est changer la serrure et laisser la porte ouverte. C'est le cousin des règles de transfert côté mail.

Les dossiers de reprise le montrent : « on a tout changé » le dimanche, l'admin fantôme encore là le mardi via un cookie. Cherchez aussi le compte, pas seulement le cookie. Mais tuez les sessions dans tous les cas. Un ordinateur de l'agence encore ouvert dans un café, le lundi, suffit à tout rouvrir si le jeton vit. Prévenez les prestataires : se reconnecter n'est pas optionnel.

Une XSS stockée a pu voler le cookie. Nettoyer le stockage *et* expirer les sessions. L'un sans l'autre recommence.

Sessions admin et « se souvenir de moi »

Déconnectez tous les utilisateurs depuis l'outil du CMS s'il existe, ou videz la table des sessions / les fichiers de session PHP. Les cases « remember me » durent des semaines. Ciblez-les.

Les applications mobiles et les clients API avec un jeton long : révoquez. Liste écrite, comme pour les clés.

Reconnectez-vous ensuite, 2FA allumée (double authentification). Vérifiez la liste des sessions actives si le plugin le montre — après nettoyage, pas comme seul outil pendant l'attaque.

• Tous les rôles, pas seulement « administrateur » affiché.
• Remember-me et jetons d'app.
• Comptes inconnus : supprimer, pas seulement déconnecter.

Clés WordPress et cousins

Les clés et sels dans `wp-config` invalident les cookies d'auth quand on les régénère. C'est un geste prévu, à faire après copie du fichier. Tous les utilisateurs devront se reconnecter — c'est le but. Prévenez l'équipe.

Prestashop, Magento, Laravel : chaque stack a son « secret d'app » ou cookie key. Même intention. Ne le faites pas trois fois dans la nuit « pour être sûr » : une fois, documenté, après la porte trouvée.

Gardez l'ancien fichier dans l'archive preuve, pas en production. Un rollback de clés réouvre les vieux cookies.

Boutique : paniers, jetons, stay-logged

WooCommerce, Prestashop : sessions clients, cookies de panier, jetons de recuperation de mot de passe déjà envoyés (invalidez-les), sessions d'employé. Un reset forcé sans ça laisse des tunnels ouverts.

Les « login as customer » des supports : révoquez ces privilèges le temps de l'incident. Trop pratiques, trop dangereux.

Paiement : si un skimmer a tourné, le cookie n'est pas le sujet principal — le PSP l'est. Ne vous rassurez pas avec un simple logout global.

Cookies tiers et pixels

Un pixel ou un chat injecté pose ses propres cookies. Retirer le script coupe la pose *nouvelle*. Les cookies déjà chez l'utilisateur vivent chez lui. Vous ne les « videz » pas à distance. Dites-le si vous informez : nous avons retiré l'outil non autorisé.

GTM, Hotjar, Clarity ajoutés sans vous : même chasse que le fichier PHP, côté front.

Ne confondez pas avec votre bandeau cookies RGPD. Ce n'est pas le chantier du jour J, sauf si l'attaquant a modifié le bandeau pour injecter. Vérifiez le plugin de consentement.

Ordre avec reset clients

Porte fermée (fichiers, comptes fantômes) → secrets admin et panel → invalidation sessions → reset clients si table lue → 2FA. Inverser reset et porte, c'est offrir les nouveaux secrets. L'ordre est le même que dans le guide fuite côté comptes.

Un email de reset qui part pendant que les sessions admin pirates vivent : ils voient les jetons dans les boîtes ou dans le CMS. D'où panel et sessions *avant* le mailing de masse.

Si le mail est en rade, le bandeau « veuillez vous reconnecter » + expiration à la prochaine action peut précéder l'email.

Vérifier que c'est mort

Un ordinateur de test qui avait une session ouverte doit être rejeté. Un téléphone « rester connecté » aussi. Faites-le en interne avant de crier victoire.

Journaux de connexion : plus de hits admin hors de vos IP habituelles dans les 48 h. Si ça continue, il reste un compte, une clé, ou une réinfection.

Search Console et le site visiteur n'ont rien à dire sur les cookies admin. Ne les utilisez pas comme preuve.

Trente jours derrière

Surveillez les nouvelles sessions admin, les nouveaux utilisateurs. Journalisation. C'est moins cher qu'un second incident.

Documentez l'heure d'invalidation dans le registre. Mesure concrète, datée.

Créer un compte si vous ne maîtrisez pas clés et tables de sessions. Mieux vaut un geste propre qu'un `TRUNCATE` au hasard qui casse les paniers trois jours. Annoncez aux vendeurs : les clients devront se reconnecter, les paniers anonymes peuvent sauter. Une heure de questions au support vaut mieux qu'un admin pirate encore logué.

• Invalider, puis reset, pas l'inverse.
• Sels / secrets d'app une fois, documentés.
• Contrôle 48 h sur les logins admin.