Archives du mot-clé sécurité

Forum PHP 2016

Cela fait maintenant un long moment que je n’ai pas eu le temps de m’occuper de ce blog, et j’espère bien pouvoir le faire plus régulièrement. Je reprends donc les publications avec mon retour sur le premier jour du Forum PHP 2016 qui s’est tenu fin octobre au Beffroi de Montrouge.

Jeudi 27 octobre 2016

Arrivé la veille de Casablanca où j’animais une formation en interne, c’est un peu fatigué mais très heureux que j’ai rejoint le Forum PHP au Beffroi de Montrouge. Habitué du quartier puisque j’y suis resté plus de huit mois pour une mission chez un client, j’ai retrouvé l’hôtel dans lequel j’avais pris mes habitudes l’an dernier, à seulement dix minutes à pieds.

Le temps de déposer mes affaires aux vestiaires et de récupérer mon badge, j’ai pu commencer de faire le tour de mes connaissances et de visiter un peu les stands des sponsors. En arrivant, on remarque tout de suite le stand de Radio France (sponsor Platine… tient, ils font du PHP ?) et celui désormais habituel, mais toujours sympathique, de Blablacar. En me promenant, je passe ensuite sur les stands de Microsoft Azure (qui a fait une démo très sympa de déploiement d’une application PHP dans leur cloud), Eleven Labs (avec leur cosmonaute… et non, faire un chemin de Kinder Schoko-bons pour attirer le monde n’était pas une super idée ;-)), Sensiolabs/BlackFire.io (et leur mini-table de ping-pong) et d’autres encore.

Rapidement, comme tout le monde, je prends la direction de l’amphithéâtre pour assister au keynote d’ouverture présenté par Cyril Pascal, de l’AFUP.

Ensuite, les conférences s’enchaînent…

Header http : un bouclier pour votre application (Romain Neutron, Blackfire.io)

Conférence très intéressante sur les entêtes HTTP à utiliser pour se prémunir d’un certain nombre d’attaques potentielles. Romain nous a présenté les principaux entêtes HTTP liés à la sécurité : X-XSS-Protection (contre les attaques XSS donc), X-Content-Type-Options (permet de désactiver l’analyse automatique du type de contenu par le navigateur), X-Frame-Options (contre le « click jacking »), Strict-Transport-Security (force l’utilisation du HTTPS pour toutes les connexions), Content-Security-Policy (prévient les attaques XSS, liste blanche de ce qui peut être exécuté sur le site)…

Je reconnais avoir découvert quelques entêtes qui mériteraient d’être positionnées systématiquement sur les sites web. Romain a ouvert une porte, reste maintenant à creuser le sujet tellement il est vaste et intéressant.

La vidéo est ici.

Industrialisation et automatisation chez M6Web Lille (Pierre Marichez et Renaud Bougre, M6Web Lille)

Pierre Marichez et Renaud Bougre, de M6Web Lille nous ont présenté l’infrastructure utilisée pour les sites gérés par leur agence de Lille et les différentes actions qu’ils ont menées depuis un an pour uniformiser les environnements de développement et de déploiements qui étaient jusque-là très hétérogènes.

Conférence intéressante là aussi pour voir de quelle façon il est possible de passer d’un environnement particulièrement hétérogène et au final peu pratique à une véritable industrialisation des développements. On y a vu notamment du Docker et du Gitlab-ci.

La vidéo est ici.

Affrontez la dette technique de votre projet en toute agilité (Maxime Thoonsen, Theodo)

En partant de la théorie de la vitre brisée (un immeuble subira plus rapidement des dégradations répétées dès lors qu’une fenêtre sera brisée qu’un immeuble intact), Maxime nous a parlé de la dette technique et de la façon de la gérer.

L’accumulation de dette technique peut conduire à une perte de vélocité dans l’équipe de développement, à des risques de sécurité et même à l’arrêt du projet. Il est donc très important de combattre dès le début du projet les mauvaises pratiques. Cela nécessite une bonne connaissance de la dette (cartographie) afin de prioriser les tâches.

Comment définir la dette technique ? Globalement, tout ce qui réduit la qualité du code et la vélocité de l’équipe peut être considéré comme de la dette technique :

  • Complexité,
  • Bugs,
  • Déploiement (si le processus est long et complexe),
  • Problèmes de sécurité,
  • Les erreurs d’architecture,
  • Le manque de tests,
  • L’environnement de développement,
  • Le manque de documentation,

Attention cependant, il peut y avoir de la bonne dette technique, avec notamment les POC, qui permettent de tester rapidement un concept et de refaire proprement si le code est conservé, et dont le coût sera toujours inférieur à une vraie dette technique.

Le combat contre la dette technique peut se structurer autour de trois principales actions :

  1. Identifier la dette : soit d’un seul coup lors d’un audit, soit au fil de l’eau grâce aux développeurs.
  2. Évaluer, décrire et communiquer autour de la dette : utilisation d’un outil comme Trello par exemple pour recenser les points de dette technique identifiés et encourager les développeurs à les traiter au fil de l’eau.
  3. Monitorer la dette : pondérer la dette (par exemple : nommage d’une variable incorrecte, 1 point, problème d’architecture, 100 points) et définir un standard, une limite à ne pas dépasser (par exemple 500 points).

Différents outils sont disponibles pour réaliser ces tâches, on notera notamment Scrutimizer, Sensiolab Insight, Sonar et bien entendu, l’intelligence des développeurs. 🙂

La lutte contre la dette technique est un combat quotidien, et le respect d’un certain nombre de règles peut la rendre moins difficile :

  • Rendre le code plus propre que lorsqu’on l’a trouvé.
  • Se focaliser sur un seul sujet à la fois et le traiter correctement.
  • Demander du temps au métier pour diminuer la dette (sans doute le plus difficile à faire ;-)).
  • Distribuer des responsabilités sur chaque dette avec un délai, de façon à plus impliquer l’équipe de développement.

Enfin, la prévention de la dette est extrêmement importante. La création d’un tableau de bord et de métriques peut permettre à l’équipe d’avoir une même vision de la dette, de maintenir l’intérêt et la motivation de tous, et surtout de rendre cette dette lisible par tous de façon à mieux la traiter. L’implication du client et sa sensibilisation à ce combat quotidien est également très bénéfique.

Prôner la simplicité des solutions, mettre en place des revues du code, et faire des choix adaptés à l’équipe (en fonction du nombre de débutants, de développeurs expérimentés…) sont autant d’actions simples permettant la diminution de la dette.

Enfin, gardez toujours en tête cette règle : écrivez toujours votre code comme s’il devait être maintenu par un psychopathe ! C’est toujours très motivant pour écrire du code propre ! 🙂

Inutile de dire que j’ai trouvé cette conférence très intéressante tant je suis confronté tous les jours à la dette technique (je travaille en effet principalement sur des TMA depuis un peu plus d’un an maintenant)…

La vidéo est ici.

Télétravail ? C’est bon, mangez-en ! (Manuel Raynaud, Wisembly)

Manuel vit à la campagne, du côté de Clermont-Ferrand, au pied des volcans d’Auvergne, et travaille pour Wisembly, située à Paris. Il nous a donc fait partager son expérience de télétravailleur, avec les avantages et les inconvénients, les outils et les processus mis en place…

Après nous avoir présenté différents types de télétravail (temps plein dans une société ne disposant pas de local, comme Automattic, temps partagé avec du travail « présentiel » classique, temps partiel), il nous a fait part des difficultés couramment rencontrées : solitude, manque de communication, difficulté de collaboration… Les solutions, être proactif et provoquer des échanges informels avec ses collègues, comme on pourrait le faire devant une machine à café, faire des rapports réguliers et mesurer le travail fournit, pas la présence.

Différents outils ont été mis en place chez Wisembly afin de faciliter l’intégration des télétravailleurs et leur participation à la vie de l’entreprise :

J’étais particulièrement intéressé par ce retour d’expérience puisque je pratique moi-même assidûment le télétravail (j’ai un contrat de travail spécifique me permettant de le faire et fixant les conditions) depuis quelques années. Je me suis tout à fait retrouvé dans l’expérience de Manuel, avec la liberté d’organiser son travail (dans certaines limites bien entendu), d’économiser énormément de temps de transport (actuellement, je dois être dans la moyenne avec entre 45 minutes et une heure de trajet matin et soir lorsque je me rends au bureau) et de pouvoir optimiser son temps de travail. Et tout ce temps gagné, c’est autant de stress et de fatigue en moins, et des moments en plus à passer en famille ! 🙂

La vidéo est ici.

Après cette matinée déjà bien chargée, il est temps de se restaurer. Cette année, l’AFUP nous propose un assortiment de petits sandwichs avec différentes garnitures (ceux au saumon étaient excellents ;-)), une boisson et un dessert. C’est toujours très sympa, ça permet de continuer de discuter avec un tas de gens intéressants tout en passant d’un stand à l’autre.

Après ce petit moment de détente, retour aux conférences !

La place de PHP dans l’architecture technique de Radio France (Rodolfo Ripado et Florent Tissot, Radio France)

J’ai redécouvert Radio France à l’occasion de cette conférence, et surtout j’ai découvert la place que PHP pouvait occuper dans une architecture dédiée à la diffusion d’autant de médias différents (radio, écoute en direct sur le web, podcast…). J’ai donc appris au final que l’équipe de développement PHP était plutôt importante (une soixantaine de personnes de mémoire, j’espère ne pas dire de bêtise) et que Radio France était particulièrement active dans le domaine du PHP (sponsor Platine cette année d’ailleurs).

La vidéo est ici.

Comment relire du code pourri sans se fatiguer (Damien Seguy, Exakat)

Les conférences de Damien Seguy sont toujours intéressantes, je vous les recommande vivement, et celle-ci n’a pas fait exception ! 🙂

A partir de métriques obtenus par différents outils qu’il nous a présentés, Damien nous a fait partager son analyse d’un code dont nous ignorions tout de la source. Tout au long de sa présentation, il a poussé son auditoire à tirer des conclusions sur le code examiné (sans jamais le voir je le rappelle), sur sa qualité, sur les éléments qu’y s’y trouvent, sur sa compatibilité avec différentes versions de PHP…

Il nous a donc parlé d’analyse statique du code et des outils disponibles. Naturellement, relire le code d’une application est humainement impossible, les tests unitaires sont peu adaptés et l’analyse dynamique revient à parcourir et à explorer le code.

Le code n’étant rien de plus qu’une donnée structurée, il existe des outils permettant de le relire automatiquement.

Parmi les outils disponibles, on peut noter :

  • PHP Lint: analyse de code statique.
  • PHPLoc, PHPMetrics : analyse et génération de métriques pour un code PHP.
  • PHP7cc, PHAN, Exakat, SonarQube : pour vérifier la compatibilité avec PHP7 et effectuer une revue de code automatisée.
  • Les diagrammes de contrôles de flux.
  • Les graphes de dépendances.
  • Deptrac : analyse des dépendances entre classes.

La vidéo est ici.

Pourquoi strlen(« « ) != 1 ? (Damien Alexandre, Jolicode)

Damien Alexandre nous a parlé du traitement des chaînes de caractères, depuis la naissance d’Unicode jusqu’à l’UTF-8, et des problèmes que sa gestion peut entraîner lors des développements (j’ai appris par exemple que MySQL ne supporte pas UTF-8 contrairement à ce que l’on croit… et ne prend en compte que les trois premiers octets au lieu de traiter les quatre octets de chaque caractère…).

Même si j’ai un peu moins accroché que sur d’autres conférences, j’ai là aussi appris plein de choses intéressantes ! 🙂

La vidéo est ici.

Ce fut une journée bien remplie, plein de belles rencontres et de notes à mettre au propre !

Merci d’avoir tenu jusque-là ! 🙂