Faut-il éviter les variables de session?

Dans le passé, j’avais beaucoup misé sur les variables de session, mais j’ai récemment constaté qu’un grand nombre d’entre elles étaient inutiles, utilisant plutôt des paramètres tels que les paramètres de chaîne de requête.

Un de mes collègues refuse d'utiliser les variables de session. Est-ce un objectif réaliste et faut-il éviter les variables de session pour des raisons pratiques? Les variables de session peuvent-elles être évitées complètement (à l'exception des cookies de session pour permettre les connexions) et cela aboutirait-il à de meilleures conceptions?

Voici quelques-unes des raisons pour lesquelles mon collègue ne les a pas utilisées:

• Nature non typée des variables de session
• Expiration de session entraînant une perte d'état
• Portée globale des variables de session
• Équilibrage de la charge des serveurs perdant des sessions (spécifique .Net?)
• Redémarrage des pools d'applications / serveurs
• Ils sont inutiles

Si vous avez une variable de session dans votre application, posez-vous la question suivante:

Lorsque je clique sur le bouton Précédent de mon navigateur, quelle valeur dois-je attribuer à ma variable?

Si la réponse est "la valeur actuelle", les variables de session peuvent être utiles. Un exemple serait un panier: vous ne vous attendez pas à ce que des objets soient retirés du panier lorsque vous remontez dans l'historique. Il est toujours dans son état actuel.

Si la réponse est "une valeur précédente", vous ne devriez pas utiliser de variables de session. Les mauvaises utilisations que j'ai constatées incluent la transmission d'un paramètre entre les pages. Si je clique sur le bouton Précédent pour revenir à une page, celle-ci n'obtient pas nécessairement le paramètre correct. De plus, si j'ouvre deux onglets, comment mon site va-t-il se comporter alors?

Obtenir le bon comportement du bouton de retour n’est en aucun cas une solution simple, mais cela vous aide à penser à un site Web en tant qu’application sans état. En général, je trouve que les utilisations appropriées des variables de session sont rares.

Le protocole HTTP est sans état. Les sessions sont un moyen de préserver l’état du client lors de requêtes HTTP. Vous pouvez choisir de le faire avec la gestion de session intégrée d'une plateforme ou de le faire vous-même avec des paramètres de chaîne de requête. Dans tous les cas, un concept de session est nécessaire pour de nombreuses tâches.

Votre collègue n'aime probablement pas une implémentation spécifique, ou n'a pas utilisé de sessions pour les objectifs prévus. Si vous devez conserver des informations sur une connexion client spécifique via des requêtes HTTP, vous avez besoin d'une forme de persistance de session.

Les problèmes suivants sont spécifiques à l'implémentation:

Nature non typée des variables de session

Portée globale des variables de session

Équilibrage de la charge des serveurs perdant des sessions

Redémarrage des pools d'applications / serveurs

Par exemple, je travaille le plus souvent en PHP et stocke les informations de ma session dans une base de données relationnelle. Donc, mes variables de session sont tapées. L'équilibrage de la charge et les redémarrages du serveur ne posent aucun problème de session.

Celui-ci est plus intéressant:

Expiration de session entraînant une perte d'état

Les sessions sont le plus souvent conservées via des cookies. Ceux-ci peuvent être supprimés par le client à tout moment. Mais ils peuvent également être préservés via un paramètre de chaîne de requête et par conséquent, ne jamais expirer sur le client. Le délai d'attente du serveur est à vous. Donc, même ce problème est spécifique à la mise en œuvre.

Ne rejetons pas tout le concept de sessions simplement parce que nous n'aimons pas une implémentation particulière. Tout bon cadre d’application Web facilitera l’utilisation des sessions afin de préserver les connexions des utilisateurs ou de conserver tout ce qui est spécifique à la visite en cours de l’utilisateur. Les enregistrements de base de données d’un utilisateur peuvent (et devraient) être utilisés pour stocker des éléments qui lui sont spécifiques lorsqu’ils sont connectés. Cependant, les visiteurs anonymes peuvent avoir des informations temporaires à conserver dans leur session, telles que la liste succincte des pages visitées récemment ou la préférence donnée à. cacher un avis qu'ils ont déjà vu. Généralement, seules des informations temporaires plus petites sont appropriées pour le stockage de session.

D'autres ont soulevé beaucoup de points positifs (que je ne vais pas répéter), mais il y a un aspect de la technique de votre ami qui n'a pas encore été abordé: la sécurité .

Il est impossible de savoir quel genre de vulnérabilités vous ouvrez sans regarder le code, mais voici quelques petites choses auxquelles je peux penser spontanément.

• Fixation de session : Une attaque puissante qui est légèrement plus facile si vous pouvez simplement demander à l'utilisateur de cliquer sur un lien qui contient déjà les informations nécessaires dans l'URL (plutôt que d'essayer d'inciter l'utilisateur à utiliser une machine dont les cookies sont correctement configurés).
• Injection SQL (ou autre entrée malveillante) : ne faites jamais confiance à quoi que ce soit qui vient de l'utilisateur. Les variables de session ont l'avantage de ne jamais quitter le serveur. Par conséquent, l'utilisateur ne peut pas les modifier directement. Bien que vous deviez effacer les données avant de les insérer dans la session, vous pouvez toujours faire confiance aux valeurs que vous transmettez par la suite. Si tout est passé à travers la chaîne de requête, vous avez BEAUCOUP de validation à faire pour vous assurer que vous n'acceptez pas une entrée malveillante.
• Corruption de données à l'aide d'entrées falsifiées : Semblable à l'injection SQL, combien de données échangez-vous? Est-ce crucial? Puis-je changer le comportement de votre application en modifiant une valeur dans la chaîne de requête? Puis-je corrompre les données sur votre serveur en modifiant des valeurs? Si je parviens à corrompre les données sur le serveur, cela affectera-t-il les autres utilisateurs? (Si votre réponse était "non", ma réponse est "êtes-vous sûr? Vous avez de nombreux endroits à vérifier".)

Tout cela peut quand même arriver quand vous utilisez Sessions, mais cela peut devenir beaucoup plus facile si votre ami ne sait pas ce qu'il fait.

Les variables de session ressemblent, dans une certaine mesure, aux anciennes variables globales de base. Il incombe à l'utilisateur de les garder en mémoire, de savoir ce qu'ils contiennent, leur portée et leur utilisation. comme dans les anciennes versions de BASIC. Cela étant dit, pourquoi quelqu'un écarterait-il totalement l'utilisation d'un mécanisme qui est évidemment conçu pour faire partie intégrante et très importante du modèle de programmation (ASP, MVC, etc.)?

Le seul inconvénient que j'ai rencontré en utilisant les variables de session, c'est que cela vous impose de garder la trace de celles-ci, de vous assurer qu'elles sont remplies avec des données pertinentes et de les éliminer.

N'est-ce pas ce que nous faisons lorsque nous programmons de quelque manière que ce soit?

J'avais l'habitude de penser comme votre collègue à cause de mauvaises expériences. J'avais eu des problèmes de débogage liés aux variables de session, qui n'étaient en réalité qu'une incompétence de ma part. Oui, vous pouvez vous débrouiller dans une certaine mesure sans variables de session, en utilisant des chaînes de requête, des champs cachés dans des formulaires, etc. Cependant, il devient très rapidement fastidieux de le faire de cette façon si votre application a quelque chose de plus à déterminer le processus logique le plus élémentaire. Il existe également le risque de sécurité de montrer le fonctionnement interne de votre application via des chaînes de requête et des champs cachés, qui peuvent servir de vecteurs d’attaque.

Lorsque vous travaillez avec des variables de session, vous devez simplement savoir quand elles sont configurées et non définies, car cela déterminera le flux logique de l'application. C'est comme la gestion de la mémoire dans un langage comme le C.

Notez que cela vient de mon expérience avec PHP sur un projet relativement petit, sans framework, les choses peuvent être différentes sur d'autres plateformes, mais je pense que le principe général s'applique toujours.

Comme indiqué précédemment, HTTP est sans état et la variable de session casse cela. La conception HTTP pour être sans état facilite la mise en cache des ressources. Pour les ressources disponibles au public.

Il est possible de concevoir un site Web sans variable de session, mais c'est plus difficile. Le plus difficile (IMHO) est la connexion / déconnexion sophistiquée, les schémas d'authentification HTTP ne fournissent pas les outils nécessaires pour s'authentifier via un formulaire HTML (vous pouvez pirater quelque chose avec javascript - XHR à https: // untel: [email protected] ) et il est encore plus difficile de vous déconnecter et d'être compatible avec tous les navigateurs. Il y a eu des discussions sur les listes de distribution du W3 à ce sujet, mais si je me souviens bien, l'idée a été abandonnée.

Pour le reste, vous devriez pouvoir vivre sans variables de session. Vous aurez un état sur une base de données, des fichiers ou n’importe où, mais l’utilisation des variables de session devrait être rare.

Si votre utilisateur a un panier d'achat, il s'agit d'une session variable uniquement s'il est supposé pouvoir naviguer sur deux ordinateurs / navigateur sans partager le panier.