La matinée a achevé mes recherches sur des outils pour auditer du code source d’applications web. J’ai préparé un joli PowerPoint de présentation et de comparatif des solutions trouvées durant la semaine.
Les outils qui ont vraiment retenus mon attentions sont RIPS, Graudit et SonarQube¹. Pour le reste, soit je n’ai pu pu les tester², soit les résultats étaient plus que médiocres, soit encore les applications ne répondaient pas au problème…

Le barbecue annulé nous a permis de faire une petite session de Left4Dead à quatre. Après cette longue pause, nous avons présenté notre travail à A. Et pris dans les discussions, il était déjà l’heure du weekend

Sinon j’ai compté, il ne me reste plus que 13 jours ouvrés de stage…

1. Même si SonarQube est un outil de mesure de qualité de code, il permet de trouver des variables non utilisées et des portions de code dupliquées. ↩

2. Impossibilité des les télécharger ou impossibilité de les exécuter, malgré tout le mal que je me suis donné :/ ↩

En début d’après-midi j’ai envoyé mon travail à A. pour qu’il y jette un coup d’œil quand il aura le temps. Une des finalités de mon stage était de produire un document analogue. J’aurais certainement d’autres occasions avant la fin du stage pour ajouter certains recommandations, si on s’aperçoit d’autres vulnérabilités « basiques » dans les futures applications auditées. Nous allons d’ailleurs commencer par auditer nos applications internes avant de nous intéresser au site internet hébergé par notre prestataire.
Il faut d’ailleurs que nous demandions à B. les codes sources de ces applications.

P. a fait des travaux pratiques : depuis quelques jours il prépare des démonstrations de sécurité — enfin de vulnérabilité — à destination des membres de la DSIT. Il nous a ainsi montré :

1. Comment créer un hotspot wifi depuis son ordinateur, en forçant la navigation de manière non sécurisé (protocole HTTP au lieu de HTTPS) pour récupérer des identifiants de connexion³. Un internaute lambda ne se doutera de rien…
2. Comment transformer son ordinateur en proxy pour ajouter du code JavaScript sur chaque page demandée et retournée, permettant ainsi de récupérer toutes les données tapées par un utilisateur…

C’est déjà assez impressionnant, mais le pire, c’est la facilité avec laquelle il met ça en place !

Il s’est aussi posé la question du VPN mis en place pour les prestataires ayant besoin d’accéder aux serveurs de production d’applications hébergés dans les locaux de la DSIT. En effet, les prestataires trouvent inadmissibles de ne pas pouvoir accéder à Internet depuis leur connexion VPN. Le problème sous-jacent, à notre avis, est qu’une fois connecté en VPN, ils ne peuvent plus accéder aux dossiers partagés sur leur propre réseau… :O

1. Dont une page de garde, une page avec les finalités du document et le sommaire, et une page pour la feuille de route. ↩

2. Exactement 2000 mots ! Bon après relecture d’A. ce nombre devrait certainement varier de quelques dizaines… ↩

3. Par exemple les pages d’authentification de Google, Facebook, Outlook, … ↩

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 ↩

1. Partie infrastructure : quelles sont les vérifications et protections à mettre en place, pour ce que qui touche de l’hébergement, des serveurs, …
2. Partie applicative : qui se concentre sur la manière de coder pour éviter toute surprise concernant la sécurité, notamment, mais on ne le répétera jamais assez, sur le traitement de TOUTES les données reçues par un utilisateur, car on ne lui fait jamais confiance !
3. Partie récapitulative avec une grille permettant de voir en un coup d’œil si on a bien respectée les principales catégories de recommandation.

Demain matin, il faudrait affiner ce document, il me reste encore quelques points à ajouter et expliquer.
Puis il faudra réviser ma présentation pour B. des failles découvertes sur application web et les solutions à apporter pour les pallier.

Car oui, demain A. n’est pas là. On va donc se débrouiller comme des grands

Avec les conseils d’A. j’ai modifié le rapport envoyé hier. Il me conseille de privilégier les tournures impersonnelles : « Une version récente et à jour de Java est requise » plutôt que « Une version récente et à jour de Java doit être installée sur votre machine ». C’est une affaire de goût, le contenu et son sens n’étant pas changé. Ces petites modifications ont rapidement été faites. Un autre conseil d’A. a été d’ajouter les erreurs courantes que les utilisateurs pourraient rencontrer. L’outil étant multiplateforme et ne nécessitant que Java, seul une version ancienne de Java pourrait poser problème.

Avant de rentrer manger à la maison, il a fallu se décider sur ce que l’on voulait amener pour le barbecue de vendredi midi¹. Les collègues se sont cotisés pour acheter un nouveau barbecue. Il va donc falloir l’étrenner

L’après-midi a permis de finir et de faire relire mon second rapport, celui sur les tests de montée en charge effectués la semaine dernière.
N’ayant toujours pas reçu les codes sources d’application car B. est malheureusement bien trop occupé en ce moment, j’ai essayé de continuer mes recommandations en matière de sécurité pour le développement d’applications web…

1. Notre midi-LAN risque donc d’être déplacé à jeudi midi. ↩

N’ayant pas encore reçu les codes sources des différentes applications web de la collectivité, j’ai pu mettre à la rédaction des deux rapports : l’un concernant les tests de montée en charge effectués du 4 juillet dernier, et l’autre sur l’utilisation de l’outil JMeter ayant permis de mener ces tests¹.

La matinée et le début d’après-midi ont été nécessaires pour réaliser le rapport/manuel sur l’outil JMeter. Mon reponsable A. doit maintenant le lire pour valider ce que j’ai dit, et on devrait ensuite voir comment le partager sur le système de fichiers commun.

L’après-midi a donc été ensuite occupée par la réduction du premier rapport, celui sur le cas des tests. Le problème avec ce genre de rapport, c’est qu’il n’existe pas encore de documents types permettant de s’occuper essentiellement du contenu. Alors que pour l’instant, il faut non seulement s’occuper du contenu, mais aussi de la forme… Pour rendre ça le plus digeste et agréable

1. Il s’agit donc plus d’un manuel d’utilisation que d’un rapport à proprement parlé ↩

Il nous a été demandé la permission d’envoyer une table de la base de données à la société s’occupant du service technique d’une application. Le problème est qu’il s’agissait de la base de production, contenant des informations utilisateurs personnelles, et dans des commentaires, des mots de passe stockés en clair !
Notre réponse a été négative pour l’envoi de la table en l’état. Si la table envoyée était nettoyée de ces informations aucun souci.

Pendant la pause de midi, j’ai pu découvrir le midi-LAN. Nous avons joué à Blur, un jeu de voitures, dans l’esprit de Mario Kart. Il est possible d’obtenir des « bonus » permettant de ralentir ou faire ralentir ses adversaires. Nous avons fini avec une course-arène par équipe, où le but est de toucher le plus d’adversaire pour faire gagner des points à son équipe.

L’après-midi a été occupé pour continuer la rédaction du fameux document de référence pour les bonnes pratiques de sécurité pour les développeurs.

Ainsi s’est achevée la première semaine de stage

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