Archives pour la catégorie Ma journée

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

Jour 9 • Encore du code source

Publié le par

Cette journée a été la continuité de la veille. Le matin, j’ai continué à chercher des solutions pour pallier les vulnérabilités trouvées sur l’application de gestion des déchets.
Pour l’échappement des caractères, je n’ai pas mieux trouvé que htmlspecialchars. Néanmoins, la fonction utilisée telle quelle n’échappe pas les guillemets simples. Il faut ajouter un paramètres à la fonction pour que les caractères &, ", ', < et > soient échappés : 

htmlspecialchars('ma super donnée à échapper', ENT_QUOTES)

Néanmoins, même sans ajouter ce paramètre, ajouter cette fonction d’échappement résoudra bien des problèmes.

Petite pause le midi pour jouer à Left4Dead. Bizarrement, il a fallu quelques temps avant d’arriver à ce que nous puissions tous les trois rejoindre une même partie en réseau local alors que nous avions tous une version authentique. Ce fut bien rigolo.

L’après-midi, je me suis plus concentré sur la validation des fichiers envoyés sur le serveur. J’ai trouvé deux solutions. Elles peuvent être mises en place séparément, mais il me semblerait plus judicieux de tout le temps utiliser les deux…

  1. La première solution consiste à désactiver l’exécution de scripts PHP dans les dossiers uploads et de forcer le téléchargement des fichiers.
  2. La seconde solution consiste à vérifier le type et l’extension du fichier envoyé, et de rejeter tout fichier dont ces critères ne seraient pas autorisés.

D’une manière générale, la seconde méthode doit toujours être mise en place, car :

Ne jamais faire confiance aux données reçues.

La première solution n’est là que si la vérification aurait échouée.