Bug, non grossière erreur #DLink

software bugDévelopper rapidement ne signifie pas faire n’importe quoi. Quand on répète que l’écriture de code informatique exige de la qualité dans le test et la documentation, ce n’est pas juste pour embêter les développeurs, c’est bien pour apporter de la valeur au produit final. L’affaire D-Link ne fera peut-être pas beaucoup de mal à la marque, mais cela met en lumière que de mauvaises pratiques sont présentes partout, même lorsque les sociétés sont grosses et disposent de moyens.

En quelques messages sur twitter avec le hashtag #dlink cette fin de semaine et le monde (en tout cas une petite partie) était informé de la faille dans l’authentification sur les équipements de la marque et l’analyse très bien documentée était rendue disponible (publiée le 12 octobre). Non pas un bug classique, mais bien une bidouille de développeur ne voulant pas se casser la tête lors de ses tests. Il suffit en effet d’un navigateur avec un user-agent bien positionné pour ne pas avoir à s’authentifier sur l’appareil avec un classique identifiant et mot de passe. On peut se demander pourquoi quelqu’un a tenté de trouver cette faille, mais de nos jours ceci est fait en permanence sur tout et n’importe quoi.

Ce qui me choque le plus n’est pas qu’il y ait un bug dans un logiciel, de plus il sera très rapidement corrigé à n’en pas douter, c’est que ce type de code puisse être dans la nature sans que le contrôle qualité ne fasse son travail. Les outils existent aujourd’hui pour coder propre, faire du test systématique et en continu. Encore plus choquant lorsqu’il s’agit d’un logiciel ayant un lien direct avec de la sécurité. Il est clair que le temps passé à écrire du code de test n’est pas immédiatement converti en production, mais la qualité est primordiale et revenir sur du code après coup pour le corriger est bien plus consommateur en temps que celui pour écrire convenablement la documentation et les scénarios de test.

Ceci lève également la question de la quantité d’outils que nous utilisons au quotidien et qui contiennent ce genre de code. Dans le cas présent, ce n’est pas très grave, mais imaginez dans une voiture pour le système de maintien des distances ou de vitesse, ou une centrale nucléaire, plus embêtant non ?

Pour avancer sur le sujet les mots clés sont : intégration continue, Jenkins, Hudson ou encore PHPUnit.

A vos claviers messieurs les développeurs !

Image: www.webapptesting.com

Et aussi

  • 2 décembre 2013 Piloter les projets d’infrastructure IT par la documentation Avez-vous remarqué, comme moi, que le niveau des documentations fournies par les intégrateurs, fournisseurs de service et autres infogérants est de plus en plus bas ? Floues, basées sur le copier/coller, pas adaptées, pas didactiques, pas simples à lire par des exploitants. Difficile de faire avancer des projets de cette façon, tout peut être remis en cause à tout moment, […]
  • 4 novembre 2013 Améliorer la sécurité réseau avec RPF Non, pas de police des frontières ou autre parti politique, derrière l'acronyme RPF on trouve « Reverse Path Forwarding ». En substance, on s'autorise à ne pas laisser entrer une trame IP sur son réseau si l'adresse source n'est pas routable via l'interface d'arrivée. Bien connue des ISP, préconisée dans la majorité des cas, on peut imaginer que si tout le monde appliquait une telle […]
  • 8 octobre 2013 Authentification des utilisateurs, peut-on avancer ? Authentifier des utilisateurs est aujourd’hui un vrai enjeu de sécurité. Tout le monde connait la faiblesse des mots de passe utilisés et sait combien il est compliqué de faire évoluer les choses dans ce domaine (cf  Born to be breached: the worst passwords are still the most common  [en]). Néanmoins, la sécurité de l’information est un réel sujet d’actualité qu’il faut en permanence […]