J’en ai aussi profité pour parcourir bon nombres de page du Monde informatique, que je connaissais pas encore  :

• Un yacht piraté en détournant le signal GPS
• Les botnets adoptent de plus en plus le réseau Tor
• Chantier « zéro papier » pour la ligne LGV Tours-Bordeaux
• Barnaby Jack, le hacker informatique, est décédé
• Facebook propose une machine virtuelle PHP
• Le rôle des RSSI s’oriente vers la veille et la stratégie
• Un robot pour craquer rapidement le code PIN des mobiles

L’après-midi a été consacré à la lecture/relecture de du cahier des charges de l’offre publique concernant la gestion de hébergement et de la DMZ publique de la collectivité local.
À la différence d’une entreprise, chaque marché doit faire l’objet d’un appel d’offre public. Il faut donc rédiger le document de telle manière à exprimer les souhaites et attentes pour le projet, tout en ne délimitant pas trop le cahier des charges, car dans ce cas aucune entreprise ne répondrait. Il faut jongler intelligemment, car c’est ce document qui fera office de contrat par la suite.

Et il faut avouer que ce n’est pas facile. Car il faut en plus coordonner chaque partie ou sous-partie avec la personne responsable du service pour que ses contraintes soient respectées…

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 ↩

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

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 ↩

La journée a été très calme. Mes recommandations concernant les bonnes pratiques de développement de sites web concernant la sécurité ont été envoyées hier à mon maître de stage A.. Aujourd’hui, il a passé la journée avec un représentant CIL¹. N’ayant pas de code source à vérifier, et P. étant sur un audit de site — d’ailleurs, il a été fait avec Joomla! 1.5, c’est fou le nombre de failles que cette version possède ! — j’ai pu flâner un peu sur Internet.

Et mine de rien, ça n’a pas été si chronophage : j’ai trouvé une métaphore assez intéressante entre les mots de passe et les brosses à dents sur le site du département sécurité du CERN.

Un mot de passe c’est comme une brosse à dents : c’est personnel et ça se change régulièrement !

J’ai juste trouvé ça bien représentatif.

Lundi commencera une nouvelle semaine, la seconde moitié du stage. J’espère qu’elle sera aussi intéressante et instructive que la première partie !

1. Correspondant Informatique et Libertés, sorte de correspondant de la CNIL. ↩

La suite du programme a été de tester une application web¹ permettant de gérer le recyclage de gros déchets.
P. s’est rapidement aperçu que les champs des formulaires n’étaient aucunement contrôlés : bonjour les failles XSS. D’autre part, l’envoi de fichiers n’était pas non plus sécurisé : nous avons pu envoyer un fichier PHP et l’exécuter. Et enfin les commandes systèmes exec, shell_exec et system n’étaient pas désactivées, ce qui nous a permis d’avoir la main mise sur le serveur…L’après-midi a été consacré à la recherche des lignes problématiques dans le code source que B. a pu nous fournir. Les développeurs ont utilisés le framework Zend pour leur application. Le problème, c’est que Zend n’échappe les caractères par défaut lors de réception de données². Il faut donc qu’à chaque ligne où la méthode de Zend pour récupérer une requête est utilisée échapper les caractères avec la fonction htmlspecialchars³.
Sublime Text a su me fournir rapidement toutes les lignes à corriger. Reste maintenant à pouvoir modifier le code source du projet en intégration…

1. Encore en développement, sur un serveur d’intégration ↩

2. Données reçues en GET ou en POST ↩

3. L’application est en effet codée en PHP ↩

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 ↩