HTTP étant un protocole sans état (staleless), la gestion des sessions utilisateurs est toujours un sujet important en matière de sécurité des applications Web. Parmi les propositions suivantes, laquelle ne permet pas de contenir l’identifiant de session d’un utilisateur ?
[A] Cookie de session (temporaire)
[B] Cookie persistant (permanent)
[C] Variable véhiculée via la méthode HTTP POST
[D] Variable véhiculée via la méthode HTTP GET
HTTP est un protocole non connecté et sans état cela signifie qu’aucun contexte de session n’est géré nativement par le protocole. Il convient dès lors aux applications Web d’implémenter un mécanisme de gestion des sessions utilisateurs. Pour cela, après avoir authentifié un utilisateur, l’application va générer un numéro de session (non prédictible) et maintenir en mémoire une table des sessions actives permettant de faire le lien entre les numéros de session et les utilisateurs authentifés. La question est donc de savoir par quel moyen ce numéro de session peut-il être véhiculé entre le navigateur et l’application Web.
La méthode la plus classique est de créer un cookie de session et d’y stocker le numéro de session. Un cookie de session est un cookie temporaire (géré en RAM côté navigateur). Ce qui signifie que si un utilisateur ferme son navigateur ou tout simplement l’onglet dans lequel l’application fonctionnait, le cookie de session est alors définitivement perdu et l’utilisateur devra à nouveau s’authentifier pour accéder à l’application.
Même si les cookies de session sont très utilisés pour gérer les numéros de session, rien n’empêche de faire la même chose avec un cookie persistant. Comme son nom l’indique, ce cookie est persistant. Il sera donc stocké dans une mémoire permanente côté navigateur (fichier ou mini base de données). Par conséquent, tant que la date mentionnée dans le cookie n’aura pas expiré, l’utilisateur pourra accéder à l’application sans avoir à re-authentifier. C’est bien sûr une contrainte en moins pour l’utilisateur mais clairement pas une bonne pratique de sécurité.
Une autre façon de gérer ce numéro de session est de créer une variable (par exemple sessionid) et de la préfixer à toutes les URLs envoyés au navigateur. Ainsi dès qu’un utilisateur invoquera l’application, le navigateur enverra une requête du type : https://www.mon-appli/ressource-lambda?sessionid=1e8h9aa27bc465e46d176823
Avec ce mécanisme, c’est la méthode GET du protocole HTTP qui sera utilisée. Par contre il n’est pas possible d’utiliser la même technique avec la méthode POST du protocole.
La bonne réponse est donc la proposition [C] Variable véhiculée via la méthode HTTP POST
Questions et réponses rédigées par VERISAFE selon le programme officiel du CISSP actuellement en vigueur
© VERISAFE – Utilisation ou reproduction (même partielle) strictement interdite sans l’accord écrit de VERISAFE
