Pourquoi une mauvaise gestion des sessions peut-elle compromettre une application ?
D’après Sécurité informatique
Flou entre couche Session et couche Application
Dans beaucoup d’implémentations actuelles, la logique de session se confond avec la couche Application.
Par exemple, HTTP/2 gère la multiplexation et une forme de session (streams), SSH encapsule la session interactive, etc.
Du point de vue OSI, on peut dire que des fonctions de couche Session sont intégrées dans ces protocoles “de plus haut niveau”.
Conséquence : L’architecte réseau doit parfois scruter la documentation du protocole (ou de l’application) pour comprendre où est gérée la session, comment elle s’établit, et quels mécanismes de sécurité sont intégrés ou absents.
Montée en puissance des standards “sécurisés” par défaut
De nombreux protocoles évoluent pour intégrer nativement du chiffrement et une meilleure gestion de session :
SMB 3.1.1 : Chiffrement AES, authentification renforcée, signature obligatoire.
TLS 1.3 : Handshake plus rapide, ciphers modernes, réduction de la surface d’attaque.
HTTP/3 (QUIC) : La session n’est plus strictement TCP, mais un transport custom au-dessus d’UDP, avec chiffrement dès le départ.
L’aspect session y est géré via un identifiant de connexion QUIC.