Archives du mot-clé synthèse

Jour 20 • Bilan

Publié le par

Dernière journée de cette semaine. Quelle surprise quand en se levant il pleuvait et tonnait ! Une bonne grosse averse et des orages à partir de quatre heures du matin, qui ont duré au moins jusque 10 heures.
Conséquence : barbecue annulé et reporté à mardi de la semaine prochaine. En espérant qu’il fasse beau.

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 SonarQube1. Pour le reste, soit je n’ai pu pu les tester2, 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é :/ ↩

Jour 14 • Recommandations

Publié le par

Pour cet avant-dernier jour avant le weekend, je n’ai pas vu passer la matinée. Nous avons fait un rapide compte-rendu de notre réunion d’hier avec B..
J’ai ensuite continué et enfin terminé mon document sur les recommandations de sécurité lors du développement d’applications web. Il fait actuellement 9 pages1, et compte 2000 mots2.

Feuille de route recommandations sécurité applications web

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 connexion3. 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, … ↩

Jour 13 • Quand le chat n’est pas là, les souris dansent

Publié le par

Aujourd’hui A., RSSI de la collectivité locale, a pris sa journée pour faire son déménagement. J’en ai profité pour presque finaliser mes recommandations.
J’ai aussi fait quelques tests sur les cookies1, pour bien montrer qu’il ne faut jamais faire confiance aux données reçues. Il me reste un petit paragraphe sur la gestion et le stockage des mots de passe à éclaircir, et je devrais avoir terminer la partie « explications/exemples ».

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 ↩

Jour 12 • Calme avant la tempête

Publié le par

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

Jour 7 • Bouclage des rapports

Publié le par

La matinée m’a permis de finir le second rapport non terminé hier.

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 midi1. 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. ↩