Archives de l’auteur : Nicolas

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 11 • Nouvelle semaine !

Publié le par

Pour commencer cette troisième semaine de stage, j’ai commencé par mettre sous forme de rapport la présentation de l’audit de vendredi dernier. En parallèle, j’ai essayé de planifier une réunion avec B., responsable du développement pour qu’on puisse lui exposer les failles trouvées, et les solutions à mettre en place pour pallier ces vulnérabilités. Ça n’a pas été si facile car B. est très pris en ce moment, mais nous avons rendez-vous mercredi après-midi.

Ce qui a été intéressant de constater, c’est que dans la version du framework Zend utilisée — la version 1.2 —, l’échappement des caractères  n’est pas fait par défaut lors de la récupération des données reçues (POST ou GET).

L’après-midi a été un peu plus calme. J’ai pu me concentrer sur les recommandations de sécurité lors du développement d’applications web. Cela m’a permis aussi de revoir un peu l’objet PDO en PHP, très pratique pour se prémunir des injections SQL.

A. a aussi du plancher sur la déclaration d’un avis pour la CNIL (au dessus d’un déclaration CNIL), car il est vrai que certaines rubriques ne sont pas très claires… Il est assez difficile de faire rentrer son application dans les cas prévus. Surtout dès qu’il s’agit de servies externes ou hébergés par un prestataire : il n’est pas toujours facile d’obtenir comment la sécurité a été mise en place, ou quels matériels ils possèdent…

Jour 10 • Fin de semaine

Publié le par

Nous voilà vendredi, cela va faire deux semaines que mon stage à commencer. Le tiers est déjà fait, c’est fou comme je n’ai pas vu le temps passé.

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ête1.

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