Archives du mot-clé outil

Jour 19 • Maitrise

Publié le par

Aujourd’hui A. était en déplacement sur Paris pour le marché d’hébergements. Ce qui ne nous a pas empêche de travailler !

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 dynamiquement1 : 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 ↩

Prise en main rapide de JMeter

Publié le par

JMeter est un outil permettant d’effectuer des tests de performance d’applications et de serveurs. Il permet de simuler le comportement de plusieurs utilisateurs agissant de manière si-multanée sur une application web. Il mesure, entre autre, le temps de réponse de chaque re-quête et produit des statistiques de ces temps de réponse.
Il permet aussi de simuler une montée en charge.

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

logo JMeter

Lire la suite →

Jour 18 • C’est qui le chef ?

Publié le par

Quel bonheur de commencer la journée avec un peu de frais dans le bureau !

Deuxième surprise : Windows a fait des mises à jour cette nuit1, 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 Dupot2 — après quelques configurations pour accéder au proxy ! —, SonarQube pour PHP et tous les dépendances nécessaires ont été installées

SonarQube résultat
SonarQube résultat

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 ↩

Jour 16 • À la recherche du lien perdu

Publié le par

Cette nouvelle semaine a commencé avec de nouveaux objectifs, qui tombaient à pic, car le document que j’avais rédigé sur les recommandations de sécurité pour le développement d’applications web est en train d’être relu par A., nous n’avons toujours pas reçu de nouveaux codes sources pour y jeter un coup d’œil…

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és1, 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 :/
  • Graudit2 : 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 ↩

Jour 4 • Montée en charge

Publié le par

Suite à la demande de B. pour simuler une montée en charge sur les deux futurs sites Internet de la collectivité locale, nous avons commencé notre matinée par vérifier que l’outil choisi la veille marchait bien, et effectuait bien ce que l’on souhaitait. Il nous a en effet donné satisfactions suite à des tests en interne. Nous avons donc pu dès 10 heures et demi lancer le test de montée en charge.

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êtes1 à 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 passe2 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 ↩