Jour 8 • Un peu de code source

La journée a commencé avec deux voitures incendiées : en arrivant nous avons pu voir que deux voitures de fonction utilisées par la collectivité locale étaient en cendre. Une personne de la police scientifique était présente et s’adonnait à des prélèvements, photos, etc pour tenter de déterminer la cause. A priori, ce ne serait pas volontaire.

Voitures brûlées

La suite du programme a été de tester une application web1 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…Capture faille exploitée par script PHPL’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ées2. 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 htmlspecialchars3.
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 

Jour 3 • C’est bien parti

Pourquoi perdre les bonnes habitudes ? La matinée a été calme, j’ai avancé dans la rédaction et la synthèse du document qui servira de référence concernant la sécurité pour le développement de nouvelles applications.

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 passe1 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

logo JMeter

JMeter pemet en effet de configurer un certain nombre de requêtes HTML2, 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