lundi 24 juin 2013

Mod_JK : mélange de session utilisateur


J'ai travaillé il y a quelques semaines sur un bug particulièrement vicieux.

Certains utilisateurs de nos applications webs JEE expérimentaient un changement d'identité alors qu'ils étaient en train de travailler tranquillement.

Mieux ils se retrouvaient dans la session d'un autre utilisateur, positionné dans un contexte qui n'étaient pas le leur.

Notre architecture est basée sur Apache, Mod_JK et Glassfish.

Une piste


Après avoir googlé quelques minutes je suis tombé sur une piste sérieuse : un bug critique sur Mod_JK  toujours ouvert, intitulé Reponse mixed between users.

Le bug est ouvert en 1.2.28 alors que nous sommes en 1.2.19 mais il ne faut jamais oublier que la découverte d'un bug dans une version ne signifie pas que le bug n'existait pas avant.

Même si la fiche du bug ne mentionne pas Glassfish, je table sur le fait qu'il s'agit d'un bug Mod_JK.

Alors je décide de monter un environnement de test pour tenter de reproduire à volonté le bug.

Pour cela, quelques commandes systèmes et quelques coups de vi plus tard, je me retrouve avec un environnement prêt à l'emploi.


Echange de session: comment est-ce possible ?


Comment vérifier que des échanges de session se produisent ?

Si le bug est rare ce que laisse à penser les remontées des utilisateurs alors il y a peu de chance que des tests manuels permettent de reproduire le problème.

Il faut d'abord comprendre comment un échange de session se fait.

Pour cela il suffit qu'un utilisateur reçoive la réponse à une requête qui ne lui était pas destinée.

En effet, l'entête de réponse Set-Cookie est renvoyé pour chaque réponse émise par le serveur Glassfish. Il faut remarquer que Tomcat ne fonctionne pas de la même manière en émettant l'entête de réponse Set-Cookie que lors de la première réponse qui suit la création de la session.

Ainsi Glassfish est plus vulnérable à ce bug Mod_JK car toutes les réponses provenant de ce serveur contiennent cet entête quand le domaine est configuré avec une route JVM.

Si Mod_JK mélange les réponses alors les utilisateurs vont recevoir un cookie de session qui ne leur est pas destiné.

Comment vérifier cela ?

A la lecture des commentaires sur le bug, je me suis rendu compte que ce bug était du genre furtif voire très furtif.

La probabilité de reproduire à la main ce bug en jouant avec plusieurs navigateurs est quasiment nulle.

JMeter à la rescousse


JMeter est à mon sens un outil de premier ordre, à la fois simple et puissant pour celui qui sait l'exploiter.

Il va me permettre de générer un nombre conséquent de session utilisateur sur une application web JEE simple et de vérifier pour chaque requête si la réponse associée contient bien le même cookie de session.

Ensuite, il suffit d'un script BeanShell dans une assertion JMeter (testé avec la 2.9) pour vérifier le point crucial : y a t-il échange de session ?

Voici le script :


Loading ....

Ce script doit être utilisé pour chaque requête dans une assertion BeanShell.

Vous pouvez soit référencer un fichier qui contient ce code, soit coller le code dans la zone prévue dans l'assertion.

Grâce à ce script j'ai pu reproduire le problème. La fréquence s'établit à 0.8 échange de session pour 1000 requêtes.

Ceci est faible mais pour une application web qui connait un traffic soutenu sur une journée de travail, c'est suffisant pour constituer un risque majeur de sécurité.

Est-ce vraiment un bug Mod_JK ?


L'utilisation de mod_proxy a supprimé ce bug.

Cela ne venait donc pas de l'application. Cette observation est conforme à certains témoignages associés au bug.

Les enseignements

Cet expertise a été pour moi une confirmation d'un ressenti quant à l'évolution de nos architectures.

Plusieurs personnes avaient été mobilisées pendant un mois pour tenter d'isoler et reproduire le problème, sans succés.

Les architectures sont de plus en plus complexes :  il est devient quasi impossible de résoudre certains incidents sans méthode et sans une rigueur extrême.

Or certains professionnels continuent d'appréhender les problèmes techniques comme "avant" : pas de méthodologie bien établie, pas de gestion de configuration fiable sur les composants de l'architecture, pas de traçabilité lors des tentatives de reproduction, modification de plusieurs paramètres de l'architecture sans bien maîtriser la portée de ces changements, ...

Il y a quelques jours Michael Shallop a publié un article sur les 5 meilleures règles de débogage et de diagnostic à connaître.

Je vous conseille la lecture de cet article.





Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

Aucun commentaire:

Enregistrer un commentaire