Jour 22 • Le souci du détail

Ce matin, j’ai continué à me pencher sur la copie de la fenêtre de connexion Windows. Mon poste de travail étant sous Windows 7 et la majorité du parc informatique aussi, je me suis dit que c’était la bonne version de l’OS à choisir. De même la majorité des utilisateurs utilisent Internet Explorer1 qui utilise la fenêtre habituelle de connexion Windows.
La fenêtre a donc été « optimisée » pour être la plus ressemblante à celle de Windows 7 ouverte depuis IE. Au final, voici un petit comparatif.

Windows weblogin comparaison

Pour rendre la fenêtre encore plus réaliste, j’ai ajouté un peu de JavaScript pour rendre la fenêtre déplaçable. Seul bémol, la fenêtre ne peut pas sortir du cadre d’Internet Explorer, alors que la vraie fenêtre oui. La copie n’est qu’une image, mais les champs ainsi que les boutons sont codés en HTML.

La fin de matinée a été consacrée à une réunion de synthèse avec X.2 sur le travail effectué depuis le début du mois de juillet. A., P. et moi étions présents.
Il a été donc rappelé tout le travail par chacun, et pour a part j’ai pu refaire une synthèse de ce que j’ai pu voir et faire au sein du stage :

  • Recherche et mise en place d’un outil de test de montée de charge (avec rédactions de documents)
  • Analyse du code source d’un application web vulnérable avec explications des solutions et corrections à mettre en place
  • Recherche d’un outil d’analyse de code source « statique » pour répérer dès le développement certaines failles
  • Rédaction d’un document de recommandations des bonnes pratiques de codage lors de développement d’applications web
  • Recherche d’utilisation de la vulnérabilité de l’intranet pour daire du hameçonnage3

Le midi, malgré le temps peu accueillant, nous avons pu nous régaler avec un barbecue

L’après-midi a été un peu plus calme, j’ai pu terminer la fausse fenêtre d’authentification, que je ai mise en ligne.
N’oubliez pas qu’elle est destinée à être ouverte dans une iFrame sur l’intranet de la collectivité, dans un environnement Windows 7 avec Internet Explorer, et qui s’appuie sur la naïveté des utilisateurs

Je vais tout de même lister les petits détails qui devraient mettre la puce à oreille aux utilisateurs :

  • Normalement, la session Windows de l’utilisateur connecté l’identifie par défaut sur l’intranet.
  • L’URL incluse est auth.ville.local, alors que le serveur est auth.ville.fr4
  • La fenêtre n’est pas déplaçable en dehors du navigateur, seul la barre de titre permet en réalité de la déplacer
  • Lorsqu’un champ est sélectionné, la bordure est bleue et ne reste pas grise
  • La touche « échap » ne permet pas de quitter la fenêtre, chose possible sur la vraie fenêtre
  • Le fond bleu change de couleur lors du survol des deux champs, et non pas de la fenêtre

  1. Version 9 tout de même ! 

  2. Responsable de notre branche, directeur-adjoint de la DSIT… 

  3. Ou Phishing en anglais. 

  4. d’ailleurs les champs grisés affichaient auth.ville.fr et VILLE 

Jour 17 • Persévérance

Aujourd’hui encore il a fait chaud. Autant le matin, l’atmosphère était respirable, mais alors l’après-midi, je me serai cru dans une fournaise. Je suis content que le journée se finisse, car je commençais à avoir un peu mal à la tête !

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.

SonarQube

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

Jour 12 • Calme avant la tempête

La journée a été assez calme : j’ai consacré ma matinée et mon après-midi à la rédaction des recommandations de sécurité lors de développement d’applications web. Le document est structuré en trois parties principales :

  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