Une recette pour remplacer les variables de session

Le suivi des sessions Web des utilisateurs est nécessaire dans tous les scénarios Web, à l’exception des plus basiques. Par définition, les sessions de navigateur Web ont un caractère temporaire. Elles débutent lorsque l’utilisateur ouvre un navigateur. A la fermeture de ce dernier ou lorsque le délai d’inactivité de la session est écoulé, la valeur assignée à la variable de session est définitivement perdue. Un utilisateur « laissé en plan » au beau milieu d’une transaction Web à la suite d’une interruption ou de l’expiration de la session considère, dans le meilleur des cas, la situation comme désagréable. Au pire, il peut perdre tout le contenu soigneusement sélectionné de son panier et quittera le site pour ne jamais y revenir.

D’autres facteurs peuvent provoquer la destruction des variables de session. Les sites Web d’un environnement distribué sont enclins à la perte de variables de session lorsque les pages sont réparties sur les serveurs aux fins d’équilibrage de la charge. Le problème de la nature temporelle des variables de session n’est pas nouveau en soi et de nombreux substituts ont été mis au point pour y remédier. Néanmoins, nombre de ces approches de remplacement sont dépendantes du langage, de la plate-forme ou du périphérique, imposent un travail significatif ou posent des problèmes de sécurité intrinsèques.

Je propose une alternative aux variables de session, qui est indépendante du langage, de la plate-forme ou du périphérique et requiert peu de travail.

Les seules exigences pour la mise en oeuvre de cette solution sont un identificateur universellement unique (UUID), un cookie utilisateur et une base de données SQL Server principale. J’utilise ASP (Active Server Pages) pour les besoins de la démonstration, mais vous pouvez tout à fait adapter ce code à n’importe quel langage de script Web capable de traiter les cookies utilisateur et d’appeler des procédures stockées SQL.

Il est fréquent, pour les développeurs Web, de stocker les données de session dans des cookies utilisateur. Mais saviez-vous que les cookies de certains des sites Web les plus étendus et les plus populaires contiennent des données pouvant servir à identifier les utilisateurs et leurs informations personnelles ? Dans une application Web, la sécurité constitue la priorité numéro un. N’importe quel analyste de la sécurité digne de ce nom vous expliquera que la meilleure sécurité consiste à ne rien avoir à cacher. Comme toutes les sessions Web doivent stocker un petit volume de données qui sont, ou pourraient être, exposées à des utilisateurs non autorisés, la meilleure option consiste à stocker les données en toute sécurité. SQL Server s’y entend pour sécuriser les données dans la base de données, mais à moins d’établir une liaison côté utilisateur aux données sécurisées de ce dernier, vous ne pouvez pas traiter des transactions de base de données au niveau utilisateur. L’astuce consiste à rendre la liaison la plus impénétrable possible, afin d’empêcher ou, au minimum, de gêner les personnes susceptibles de s’en servir à des fins peu nobles. Si un cookie ou d’autres données de session qui identifient de manière unique un utilisateur peuvent être lus par une personne non autorisée, la raison d’être du stockage sécurisé des données se trouve remise en cause.

Une approche plus intelligente consiste à employer les cookies pour stocker des informations interprétables uniquement par SQL Server. Certains développeurs choisissent un ID utilisateur pour identifier de manière unique chaque utilisateur dans une session Web. Ils peuvent employer un identifiant globalement unique (GUID) pour générer les ID utilisateur et se sentir réconfortés par la nature non séquentielle du GUID. Néanmoins, un pirate informatique peut encore parvenir à se servir du cookie pour usurper l’identité de l’utilisateur sur les pages Web. Comme l’ID utilisateur fait partie d’un enregistrement permanent, il n’expire pas et son utilisation dans un cookie fait jouer le temps en la faveur du pirate.