Archives du mot-clé outil

Jour 3 • C’est bien parti

Publié le par

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 ↩

Jour 2 • Mise en route

Publié le par

Ce matin, pour mon deuxième jour, j’ai commencé par le document de synthèse des bonnes pratiques et marche à suivre concernant la sécurité lors de développements (principalement d’application web), en suivant les différentes recommandations trouvées sur Internet, notamment les « Recommandations pour la sécurisation des sites web »1 de l’ANSSI.
Bonnes nouvelles : dans ma pratique personnelle et avec l’expérience que j’ai pu acquérir en développement web, je suivais déjà la plupart de ces recommandations. Il va falloir maintenant les formaliser par écrit pour les développeurs de la DSIT pour les rendre automatiques. Je pense ajouter une annexe au document, qui serait comme une feuille de route avec pour chaque élèment à vérifier une case à cocher2.

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 complet3. 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 site4. É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 ? ↩