Il est développé en Java et est sous Licence Apache.

Ce qui suit n’est qu’une copie du manuel écrit dans le cadre de mon stage.

Installation

Pré-requis

Une version récente et à jour de Java est requise. Si ce n’est pas le cas, il faut télécharger la dernière version à l’adresse suivante :
http://www.java.com/fr/download/windows_xpi.jsp

Téléchargement

Il suffit de télécharger les binaries de JMeter sur le site officiel à l’adresse :
http://jmeter.apache.org/download_jmeter.cgi

Lancement

Une fois le dossier décompressé, il suffit de lancer le fichier « ApacheJMeter.java » présent dans le dossier « apache-jmeter-2.9\bin ».

Préparation

Le but de ce scénario est de simuler une montée en charge sur différentes pages¹ d’un site web, tout en chargeant automatiquement les ressources associées (feuilles de style, images, JavaScript, …).
Note : JMeter n’est pas capable d’exécuter les scripts chargés !

Le « plan de test » est l’emplacement à partir duquel on définit ce que l’on va tester alors que le « plan de travail » est un emplacement permettant de garder les composants de test non utilisés.

Création du scénario

Il faut commencer par créer un « Groupe d’unités ».
Ce groupe d’unités peut être vu comme des clients.

Il faut ensuite ajouter les différences pages à tester en ajoutant des « Requêtes HTTP ».

Après avoir sélectionné la requête nouvellement créée, il faut la configurer.
Les paramètres importants (à compléter ou vérifier) sont :

• nom (facultatif) : nom court de la page testée
• nom ou adresse IP du serveur web : nom du serveur à tester (sans slash)
• protocole de la requête HTTP : http
• chemin de la requête HTTP : arborescence jusqu’à la page à tester
• connexion persistante : √ ou × (selon le protocole de test)
• récupérer les ressources incluses : √ ou × (selon le protocole de test)

Pour la page de recherche, il faut aussi envoyer des paramètres en URL pour simuler la page :

http://localhost/dev/search.php?search=une+recherche

Il suffit d’ajouter ces informations dans l’onglet « Paramètres ». La colonne « nom » permet d’inscrire le nom du paramètre, et la colonne « valeur » le paramètre.
Notez qu’il est possible d’encoder automatiquement le paramètre en cochant l’option « encodage ».

Une fois que le scénario est créé, il faut définir des récepteurs pour les résultats.

Rapports de résultats

Pour visualiser les résultats de la simulation, je vous propose d’ajouter trois types de rapports :

1. Arbre de résultats
2. Graphique de résultats
3. Graphique évolution temps de réponses

Résumé du scénario et des rapports :

 Simulation

Maintenant que le scénario de simulation est créé, et que les différents rapports voulus ont été ajoutés, la simulation va pouvoir être lancée.

Lancement de la simulation

Juste avant de lancer la simulation, il faut vérifier que les paramètres de simulation de montée en charge sont bien ceux définis par le protocole de tests.
Il faut sélectionner « Groupe d’unités » pour vérifier et ajuster les propriétés de la simulation.

Quand tout semble correct, il suffit de cliquer sur l’icône « play » dans la barre d’outils.

Analyse des résultats

• Le rapport « Arbre de résultats » permet de visualiser tous les détails de la requête (envoi, comme réception). Il est aussi possible de vérifier que les ressources présentes sur la page ont bien été chargées.
• Le « Graphique de résultat » permet de visualiser graphiquement les données envoyées et reçues.
• Le « Graphique évolution temps de réponse » permet, comme son nom l’indique, de suivre l’évolution du temps de réponse durant la simulation.

Arbre de résultats

Graphique de résultats

Graphique évolution temps de réponses

Voilà, à vous les tests de sites web, notamment les montées en charge

1. La page d’accueil ainsi qu’une page de recherche seront testées. Pour chaque page, une ressource (image) devra aussi être chargée. ↩

D’autant plus que j’ai continué à rechercher des solutions de scripts pour analyser du code PHP. J’ai fait un rapide bilan écrit (un peu plus complet et détaillé que celui d’hier, notamment avec des captures d’écrans) des solutions trouvées jusqu’à présent.
Sans grande surprise, je n’ai toujours pas trouvé les sources de Pixy.

Mais surtout, j’ai tenté de faire fonctionner SonarQube. Sur Windows évidemment. Alors après quelques cafouillages, des configurations bancales qui ont tout de même le mérite de ne pas tout faire planter, impossible de faire des tests pour PHP. Soit j’ai mal fait quelque chose dans les installations des différents plugins et applications nécessaires (voire j’en ai oublié un :/), soit ce n’était pas mon jour… Alors imaginez avec une chaleur pas possible.

Mon problème n’était pas le serveur central SonarQube, sorte de « dashboard ». Ce qui m’a d’abord posé problème, c’était le Sonar Runner qui permet de lancer des tests sans devoir passer par Maven ou Ant. Mais c’était trop peu pour me faire peur. Car après quelques sueurs froides chaudes, c’est l’installation de PHP qui a flanché. Et là, j’ai perdu tout espoir en Windows.

J’ai donc opté pour une machine virtuelle sous Ubuntu (j’ai d’ailleurs trouvé un tutoriel qui semble bien expliqué pour auditer du code PHP), qui j’espère sera prête d’ici demain matin. Et normalement, merveille des merveilles, je découvrirais le rapport d’audit de Sonar

Comme en début d’après-midi P. et moi nous devions présenter les vulnérabilités trouvées et les solutions pour les pallier à B., nous avons un peu retravaillé nos supports.

Le début d’après-midi a ainsi pu bien se déroulé. B. a été très à l’écoute, mais comme l’application est encore en développement et que la deadline n’est pas urgente, il fera les modifications nécessaires lorsqu’il aura un peu de temps. La réunion a été courte, mais il en a profité pour nous demander de tester d’autres internes et externes, pour voir ce que nous trouvions.

Il faudra cependant attendre demain, pour que A., notre responsable, téléphone au prestataire afin de les prévenir que nous allons faire des tests de vulnérabilité sur leurs serveurs où sont hébergés certains sites.

1. Notamment avec ce plugin jquery-cookie pour insérer et lire des cookies en JavaScript, et Firebug pour modifier les cookies enregistrés sur mon ordinateur ↩

Ce matin, programme agréable : préparation d’un court rapport et d’une petite présentation des solutions trouvées hier pour pallier les failles de sécurité trouvées, qui je le rappele, permettent l’envoi de n’importe quel fichier — et donc, au hasard un script PHP permettant de prendre la main sur le serveur —, et de nombres failles XSS permettant l’exécution de code malicieux.
Cette petite présentation devra être présentée cet après-midi avec A., mon maître de stage, et P. son premier stagiaire. P. devait s’occuper de faire la présentation concernant la recherche et présenter ce que permettent de faire les failles.

Ce midi : barbecue. Enfin, pour être exact, inauguration du barbecue. Pour l’occasion j’avais apporter une salade de nouilles/tomates/fromages/jambon. Les cuisiniers s’en sont très bien sortis ; ce fût très bon et très agréable de pouvoir discuter tous ensemble. Certains ont même commencé une partie de pétanque

Après ce petit repas, il a fallu digérer un peu, ce qui a permis de prendre son temps pour faire notre petite réunion de présentation. Tout s’est bien passé, nous avons pas mal discuté, surtout d’un sujet récurrent : comment l’application web arrive à identifier l’utilisateur sur l’Active Directory sans jamais transmettre son mot de passe.
La réponse est certainement très bête¹.

Hé puis, mine de rien, il était déjà l’heure de rentrer

1. Je verrais bien un échange de token pour authentifier l’utilisateur en fonction de sa session Windows — l’application n’est disponible qu’avec IE, les autres navigateurs ne supportant a priori pas la méthode d’authentification automatique utilisée… ↩