Archives du mot-clé développement

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

Jour 8 • Un peu de code source

Publié le par

La journée a commencé avec deux voitures incendiées : en arrivant nous avons pu voir que deux voitures de fonction utilisées par la collectivité locale étaient en cendre. Une personne de la police scientifique était présente et s’adonnait à des prélèvements, photos, etc pour tenter de déterminer la cause. A priori, ce ne serait pas volontaire.

Voitures brûlées

La suite du programme a été de tester une application web1 permettant de gérer le recyclage de gros déchets.
P. s’est rapidement aperçu que les champs des formulaires n’étaient aucunement contrôlés : bonjour les failles XSS. D’autre part, l’envoi de fichiers n’était pas non plus sécurisé : nous avons pu envoyer un fichier PHP et l’exécuter. Et enfin les commandes systèmes exec, shell_exec et system n’étaient pas désactivées, ce qui nous a permis d’avoir la main mise sur le serveur…Capture faille exploitée par script PHPL’après-midi a été consacré à la recherche des lignes problématiques dans le code source que B. a pu nous fournir. Les développeurs ont utilisés le framework Zend pour leur application. Le problème, c’est que Zend n’échappe les caractères par défaut lors de réception de données2. Il faut donc qu’à chaque ligne où la méthode de Zend pour récupérer une requête est utilisée échapper les caractères avec la fonction htmlspecialchars3.
Sublime Text a su me fournir rapidement toutes les lignes à corriger. Reste maintenant à pouvoir modifier le code source du projet en intégration…

  1. Encore en développement, sur un serveur d’intégration ↩

  2. Données reçues en GET ou en POST ↩

  3. L’application est en effet codée en PHP ↩

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