Après une installation réussie hier de l’outil SonarQube, j’ai pu tester différents sites avec différents types de configurations (tests basiques, sur tels critères, etc). L’outil est vraiment complet pour la qualité de code, mais absolument rien concernant la sécurité… Or le but de mes recherches est de trouver des applications capables de déceler dans le code source des vulnérabilités. Donc malgré l’intérêt que j’ai pour cet outil, il ne convient malheureusement pas…
Néanmoins, j’ai appris à lancer ces différents tests, jongler avec cet outil parfois capricieux. J’ai enfin pris ma revanche

J’ai donc continué ma recherche, et je suis tombé sur un petit logiciel pour Windows capable de scanner du code statique, et aussi dynamiquement¹ : PHP Vulnerability Hunter.
Je reste assez septique. Le logiciel n’a trouvé qu’une seule petite faille mineur sur le code testé, et dont un essai sur deux de scan se solde par une sorte de plantage. Peut-être faut-il un nombre restreint de fichiers à tester ?

Demain matin, P. a demandé à A. s’il pouvait l’accompagner pour une réunion concernant le marché d’hébergement pour voir comment ça se déroule. Je pense finir ma présentation des outils trouvés jusqu’à présent, car après le barbecue, petite réunion de synthèse.

1. Dans ce cas, un serveur web sur lequel le code est exécuté est nécessaire ↩

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. ↩

Deuxième surprise : Windows a fait des mises à jour cette nuit¹, et a donc redémarrer l’ordinateur : la machine virtuelle d’Ubuntu a planté en plein installation.
Me voilà donc à recommencer l’installation. Problème, après redémarrage problèmes graphiques empêchant le lancement de toute fenêtre. Bref, j’étais bon pour refaire une installation. Et alors là, plantage en plein installation. Que du bonheur. J’ai même tenté une installation « dual-boot » avec Wubi depuis Windows, là encore patatra…

Vint de l’heure de se restaurer pendant que le téléchargement d’Ubuntu serveur est en cours. Car j’ai fondé mon espoir sur cette version sans interface graphique, et fort heureusement, je n’ai pas été déçu.
En suivant scrupuleusement l’article de Dupot² — après quelques configurations pour accéder au proxy ! —, SonarQube pour PHP et tous les dépendances nécessaires ont été installées

Et il faut dire, que l’outil semble assez puissant. Je n’ai pour l’instant que fait un test sur un exemple proposé par SonarQube, l’ensemble du code est passé en revu. Je n’ai encore pu voir si cela avait un intérêt concernant la sécurité, car la majorité des alertes se font sur la qualité du code (nombre classes, méthodes, fonctions, complexité, etc).
Je vais pouvoir demain passer l’ensemble des projets à travers cet outil

1. Habituellement, Microsoft sort ses patchs de sécurité tous les deuxièmes mardi de chaque mois. ↩

2. http://dupot.org/post-10.html ↩

Il s’agit de faire des recherches pour trouver des logiciels ou scripts open-source permettant d’analyser le code source d’une application PHP.
Parmi ceux trouvés¹, il y en a un qui me résiste encore pour le télécharger : Pixy
Le script a été conçu par des membres d’une université en Autriche, et l’ancien site du projet, facilement trouvable, renvoie vers le nouveau site, qui lui est injoignable…

J’ai tenté vainement jusqu’à présent de trouver un autre site sur lequel trouver le script. Peut-être que j’aurais plus de chance demain !

Voici une courte liste de ce qui a retenu mon attention jusqu’à présent :

• Pixy : on va attendre de trouver un lien de téléchargement valide :/
• Graudit² : tout en ligne de commande, mais a du mal avec les framework…
• Rips Scanner : il suffit de copier les fichiers php dans un répertoire web, et on peu lancer les scans. Ne supporte pas pour l’instant PHP orienté objet. C’est bien dommage, car la solution s’annonçait intéressante !
• SonarQube : ça l’air d’une grosse usine à gaz, et c’est nativement plus pour Java.

Sinon, il fait chaud. Très chaud. Et même si le bâtiment est en général très frais, ça commence à ne plus devenir tenable…

1. Certains grâce au site du département sécurité CERN, le même qui m’avait permis de découvrir l’analogie mot de passe et brosse à dents. ↩

2. Contraction de grep et de Audit ↩

Nous avons procédé par étapes pour vérifier la robustesse du serveur. Deux ordinateurs lançait conjointement la simulation, répétée jusqu’à un arrêt manuel, chargeant les pages suivantes : page d’accueil ; galerie photos ; galerie vidéos ; recherche du mot « marchés ».
Les simulations étaient les suivantes :

1. Simulation de 10 utilisateurs faisant 4 requêtes¹ à la seconde
   (10×4×2 = 80 requêtes à la seconde)
2. Simulation de 30 utilisateurs faisant 4 requêtes à la seconde
   (20×4×2 = 160 requêtes à la seconde)
3. Simulation de 50 utilisateurs faisant 4 requêtes à la seconde et de 20 utilisateurs faisant 2 requêtes à la seconde
   (50×4×2+20×2×2 = 480 requêtes à la seconde)

Le serveur a tenu la charge pour les deux premières simulations (lors de la deuxième simulation, le temps de réponse est monté jusqu’à une quarantaine de secondes…). Par contre, la troisième simulation a fait tomber la base de données au bout d’une dizaine de secondes.
Relancer le service a suffit pour retrouver un site opérationnel (la simulation étant arrêtée).

Après une matinée bien chargée, l’après-midi a été consacré au document de recommandations pour la sécurité des applications web. Je sais quels points je veux aborder, mais il reste maintenant à organiser ça et à rendre ça digeste pour tout développeur…

La fin de journée a été consacrée à la résolution d’un petit problème pour D., stagiaire de B. migrant un ancien Joomla sur la dernière version. Il lui était impossible d’accéder à l’administration de Joomla, une requête SQL d’un utilisateur et de son mot de passe² a permis de résoudre le problème.

1. Notons qu’une requête correspond au chargement de la page demandée, en chargeant aussi tous les éléments (fichiers CSS, javascript, images, …), ce qui en réalité représente plusieurs requêtes… ↩

2. Hashé dans la BDD, mais connu au préalable ↩

Nous avons aussi eu la problématique d’un prestataire qui demandait un compte administrateur sur l’Active Directory pour son application. L’Active Directory est une sorte de base de données centralisée sur un serveur de tous les utilisateurs d’un domaine et de leur mot de passe. L’utilité d’un tel service est que chaque service nécessitant d’authentifier un utilisateur le fera en interroger cet Active Directory.
Or ce prestataire demandait un tel compte pour pouvoir importer l’intégralité des utilisateurs et mots de passe¹ pour authentifier les utilisateurs de l’application. Nous avons donc demandé des détails pour mieux comprendre ce qu’il souhaitait faire, car sa demande en l’état aurait été refusée !

L’après-midi a été un peu plus mouvementé ! B., qui s’occupe de mettre en ligne deux nouveaux sites institutionnels, nous a demandé de mettre en place un petit logiciel pour simuler une montée en charge sur ces deux nouveaux sites.
Nous avons donc cherché sur Internet des outils permettant de simuler un certain nombre d’utilisateurs se connectant aux sites et simulant des actions : aller sur la page d’accueil, faire une recherche, etc

Je suis tombé sur l’outil JMeter d’Apache qui répond bien au cahier des charges. Nous avons donc mis en place un petit scénario, que nous exécuterons demain matin

JMeter pemet en effet de configurer un certain nombre de requêtes HTML², de spécifier les paramètres POST ou GET à envoyer, … Il permet aussi de générer différents types de rapport pour ensuite traiter les résultats de la simulation.
Nous verrons donc demain si les serveurs tiennent la montée en charge.

1. Les mots de passe sont stockées de manière chiffrée à sens unique, et sans la clef de cryptage, on voit mal à quoi cela servirait… ↩

2. Mais il y a un nombre fou d’autres possibilités ↩

P. m’a ensuite montré plus en détail les différents outils qu’il a pu utilisé pour faire ses tests de vulnérabilité. J’ai notamment été bufflé par deux outils :

1. Nessus qui permet de lancer une batterie de tests sur une IP et de générer un rapport très complet³. On peut ainsi récupérer les ports ouverts, l’OS de la machine, les différentes versions de logiciels utilisés, les failles connues à partir de ses éléments, la découverte du réseau, etc ;
2. Social-Engineer Toolkit qui permet, entre autre, de copier une page web pour récupérer les identifiants envoyés par un utilisateur. L’exemple que P. m’a montré est assez puissant je trouve : en une petite commande, la page d’accueil du site de Facebook était copiée au pixel près ! Le formulaire envoyait de manière transparente les données au serveur pirate, puis renvoyait vers le vrai site Facebook : un utilisateur lambda n’y verrait que du feu, et aurait pourtant compromis son compte  J’essayerais de reproduire l’exemple ici.

J’ai pu découvrir de nombreux autres outils, certains plus spécialisés que d’autres.

Nous sommes ensuite allés manger ensemble dans un restaurant chinois pas très loin. Le buffet à volonté ne fut pas mauvais du tout !

L’après-midi a commencé par une réunion avec B. et sa stagiaire D. concernant les actions communes que nous pouvions mettre en place. B. s’occupe du développement de nombreuses applications web, et sa stagiaire D. doit faire évoluer deux anciens sites existants sur de nouvelles plateformes. Il est à noter que D. a pour formation initiale une formation beaucoup plus réseau que développement web.
J’ai ainsi pu aider D. à configurer son logiciel Wamp pour faire fonctionner un des anciens sites qui était sous Joomla 1.5. Il a aussi fallu importer une base de données SQL par l’intermédiaire de phpMyAdmin. Je crois que ces petites configurations lui ont rendu un grand service pour qu’elle puisse continuer à avancer dans son projet.

En fin de journée, nous avons dû nous pencher activement sur une partie du futur site Internet de la ville — qui doit être mis en production en fin de semaine. En effet sur le site actuel, il est possible par l’intermédiaire d’un formulaire de demander des papiers officiels pour l’état civil. Le nouveau site ne permettant pas cette fonctionnalité, il faut absolument qu’elle y soit présente. Nous devons donc déterminer si la fonctionnalité développée précédemment présente des risques majeurs, car l’idée serait de greffer ce formulaire sur le nouveau site⁴. Évidemment, autant en profiter pour vérifier que tout va bien !

Voilà comment s’achève cette deuxième journée, tout aussi intéressante que la première !

1. Vous remarquerez que le document a été écrit en LaTeX  ↩

2. J’y vois pour l’instant les rubriques « pendant le développement » et « avant la mise en production » ↩

3. J’en ai profité pour faire un test  complet sur mon Raspberry Pi. J’avais oublié que Fail2Ban était installé, l’IP attaquante a donc été vite bannie, ce qui m’a permis de m’en sortir de bons résultats ! ↩

4. Le site doit être opérationnel en fin de semaine, et avec cette fonctionnalité, et à quoi bon réinventer la roue ? ↩