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é :/ ↩

Ce matin, programme agréable : préparation d’un court rapport et d’une petite présentation des solutions trouvées hier pour pallier les failles de sécurité trouvées, qui je le rappele, permettent l’envoi de n’importe quel fichier — et donc, au hasard un script PHP permettant de prendre la main sur le serveur —, et de nombres failles XSS permettant l’exécution de code malicieux.
Cette petite présentation devra être présentée cet après-midi avec A., mon maître de stage, et P. son premier stagiaire. P. devait s’occuper de faire la présentation concernant la recherche et présenter ce que permettent de faire les failles.

Ce midi : barbecue. Enfin, pour être exact, inauguration du barbecue. Pour l’occasion j’avais apporter une salade de nouilles/tomates/fromages/jambon. Les cuisiniers s’en sont très bien sortis ; ce fût très bon et très agréable de pouvoir discuter tous ensemble. Certains ont même commencé une partie de pétanque

Après ce petit repas, il a fallu digérer un peu, ce qui a permis de prendre son temps pour faire notre petite réunion de présentation. Tout s’est bien passé, nous avons pas mal discuté, surtout d’un sujet récurrent : comment l’application web arrive à identifier l’utilisateur sur l’Active Directory sans jamais transmettre son mot de passe.
La réponse est certainement très bête¹.

Hé puis, mine de rien, il était déjà l’heure de rentrer

1. Je verrais bien un échange de token pour authentifier l’utilisateur en fonction de sa session Windows — l’application n’est disponible qu’avec IE, les autres navigateurs ne supportant a priori pas la méthode d’authentification automatique utilisée… ↩

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 ↩

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

Après une rapide installation sur mon poste de travail¹, j’ai pu accéder… à mes emails ! Quelle classe d’avoir une adresse email avec l’extension de la ville dans laquelle on fait son stage

La matinée a été calme. J’ai commencé par apprendre à me servir de la photocopieuse pour fournir une copie de la convention de stage aux secrétaires, avant de discuter avec le “premier” stagiaire². Il m’a montré les différentes failles et exploits qu’il a trouvés et utilisés sur un certains nombres de sites audités et liés à la collectivité locale. L’après-midi a été principalement occupée par une réunion dans laquelle A. m’a présenté — et représenté pour P. qui connaissait déjà — l’organisation de la DSIT, les différentes personnes, etc. Nous avons ensuite parlé des différents axes que je vais suivre pour mon stage. On peut donc grossièrement voir ça comme :

1. Rédiger un document de synthèse pour les développeurs : « best practices » pour le développement, et les tests automatiques à faire ;
2. Corriger les failles découvertes par mon co-stagiaire ;
3. Collaborer avec une stagiaire s’occupant d’un nouveau site web pour vérifier en parallèle la sécurité.

La journée a touchée à sa fin vers 17 heures 30, l’heure de rentrer.
Une journée remplie, qui semble en annoncer d’autres remplies et intéressantes.

1. En réalité, un portable HP connecté à une station de travail avec un second écran, ainsi que clavier et souris ↩

2. P. est arrivé avant moi, et repartira après moi… ↩