18. Cycle de session, fixation et élévation de privilèges

Comprendre le mécanisme

La session associe un identifiant à un contexte accepté par le serveur. Sa création, son renouvellement, son expiration et sa révocation forment un cycle de vie. Une fixation exploite l’acceptation d’un identifiant connu ou contrôlé avant que la victime obtienne un contexte authentifié. Après authentification ou changement de privilège, une stratégie de renouvellement évite de prolonger une ancienne association de confiance.

Raisonner et vérifier

La rotation doit tenir compte des requêtes concurrentes et des erreurs réseau. Une suppression précipitée peut perdre un état légitime ; conserver indéfiniment l’ancien contexte peut laisser un accès indésirable. Définissez durées d’inactivité et absolues, comportement de l’ancien identifiant et événements d’audit minimisés. La déconnexion de la page courante n’est pas automatiquement la révocation de tous les appareils.

Transition de connexion

La connexion constitue une transition sensible de session. La politique doit empêcher une fixation utilisable. Un identifiant connu avant connexion ne doit pas devenir silencieusement une capacité privilégiée pour un tiers. Définissez rotation et reprise des données au moment où l’identité change.

Continuité contrôlée

Une rotation doit préserver les données nécessaires selon le contrat. Le changement d’identifiant doit rester cohérent avec le parcours. La rotation peut devoir préserver panier ou préférences tout en changeant la capacité d’authentification. Listez ce qui doit suivre la transition et ce qui doit être réinitialisé, puis testez les deux.

Instances

La révocation doit être testée sur les instances concernées. La propagation et les caches font partie du système. Un retrait stocké sur une seule instance peut laisser une autre accepter l’ancienne session. Vérifiez le backend partagé, caches et délais de propagation sur tous les nœuds inclus dans le contrat.

Demandes simultanées

La concurrence peut affecter la rotation. Des requêtes parallèles peuvent observer des transitions. Une requête ancienne peut arriver pendant la rotation. Définissez le traitement de ce chevauchement et vérifiez qu’il ne restaure pas une référence retirée ou ne fait pas perdre un état nécessaire.

Durées serveur

Le serveur impose des limites de durée. La durée doit suivre une politique de confiance serveur. Fixez durée maximale et éventuelle durée d’inactivité selon le risque. L’expiration du cookie ne suffit pas : le backend doit refuser une valeur conservée au-delà de la politique d’acceptation.

Élévation

Une élévation de privilège demande une politique explicite. Le changement de contexte peut exiger une vérification adaptée. Passer d’un compte ordinaire à une opération sensible peut demander une réauthentification et une nouvelle capacité. Une simple mise à jour de rôle ne traite pas automatiquement le risque des anciennes références.

Logout

Un logout doit avoir un contrat de retrait défini. Les effets dépendent de l’implémentation et du périmètre. Annoncez si la déconnexion retire seulement cette session ou toutes les sessions du compte. Vérifiez une copie conservée après l’action ; l’absence du cookie dans l’interface ne prouve pas le refus serveur.

Ancienne référence

Les anciens identifiants doivent suivre une politique de refus. Une compatibilité sans limite peut conserver le risque. Le contrat doit dire quand l’ancien identifiant cesse d’autoriser les demandes privilégiées. Testez cette borne et évitez une période de grâce indéfinie introduite pour contourner des problèmes de concurrence.

Stockage protégé

Le stockage de session doit être protégé. Le contenu et les identifiants restent sensibles. Le store de sessions contient des capacités ou des données sensibles. Limitez accès, sauvegardes et visibilité des outils d’exploitation ; une protection de cookie ne répare pas un stockage exposé.

Avant et après

Un test doit essayer l’identifiant avant et après transition. Il faut vérifier les capacités de l’ancienne référence. Présentez l’identifiant initial avant connexion, après connexion puis après retrait. Cette chronologie démontre les transitions, au lieu de vérifier seulement qu’un nouvel identifiant a été généré.

Atelier guidé : lire, expliquer et vérifier le code

before_login: session_id=lab-old
login: success
privileged_request_with_lab_old: accepted
rotation_policy: old_id_must_stop_authorizing_privileged_requests

La politique exige que lab-old cesse d’autoriser les demandes privilégiées, mais la trace montre encore une acceptation. La transition est donc incorrecte dans ce contrat. Vérifiez rotation, invalidation et propagation, puis ajoutez un test concurrent qui conserve la continuité des données autorisées.

L’interface ne retire pas une capacité serveur. Changer la représentation ne résout pas l’état de confiance. La taille du corps ne démontre pas le retrait. Le comportement contredit la politique de transition annoncée.

Travail pratique : Simulez deux requêtes parallèles lors d’une connexion puis lors d’une déconnexion. Définissez le sort de chaque identifiant.

Critères de correction : Utilisez un environnement isolé et des comptes fictifs. Vérifiez qu’un identifiant obsolète ne récupère pas les nouveaux privilèges ; contrôlez les faux refus liés à la concurrence et documentez la stratégie de reprise.