Journée des programmeurs : des ressources pour vérifier votre code

Journée des programmeurs : des ressources pour vérifier votre code

Profitons de la Journée des programmeurs pour partager avec vous certains outils vous permettant d’évaluer la sécurité de votre code.

Profitons de la Journée des programmeurs pour partager avec vous certains outils vous permettant d’évaluer la sécurité de votre code.

Le 13 septembre constitue le 256e jour de l’année. Ces trois chiffres ne signifient peut-être rien pour le commun des mortels, mais les gens qui travaillent dans différents domaines de l’informatique, cela représente le nombre maximum de nombres qui peuvent être représentés avec 1 octet (de 0 à 255). Comme cette unité de mesure est fondamentale dans le calcul, cette valeur a été sélectionnée pour définir le Jour des programmeurs, qui tombe généralement le 13 septembre.

Dans cette optique, nous croyons le moment venu de reconnaître le travail des personnes qui créent des solutions par le biais de codes nous permettant de continuer à profiter des nombreuses technologies que nous utilisons au quotidien. Dans des articles précédents, nous avons abordé des sujets connexes, tels que les principes de base et les contrôles qui devraient être mis en œuvre pour un développement sûr, les mythes associés liés au développement sûr et nous avons même partagé des recommandations concernant les conseils pour un développement sûr dans iOS. Et étant donné que dans toutes ces livraisons nous avons toujours essayé d’insister sur l’importance de la vérification du code, à cette occasion, nous allons nous pencher sur certains outils très utiles pour cette étape.

Connaître les vulnérabilités : la clé d’un développement sécuritaire

Bien que de nouvelles vulnérabilités soient découvertes et publiées en permanence, dans le cas du développement d’applications, les dix principales vulnérabilités les plus courantes sont restées les mêmes au cours des cinq dernières années. C’est ce que montre le rapport publié par l’OWASP, qui compare le nombre de vulnérabilités signalées en 2017 à celui de 2013. Cela nous fait croire que de nombreux développeurs font toujours les mêmes erreurs, soit parce qu’ils ne savent pas que ces vulnérabilités existent, soit parce qu’ils ne prennent pas le temps de vérifier leur code pour de telles failles, faiblesses et vulnérabilités.

Si vous voulez que votre application soit sécurisée, vous devriez commencer par comprendre les vulnérabilités qui peuvent l’affecter; du moins les vulnérabilités potentielles plus courantes. Sur le site de l’OWASP, vous trouverez non seulement des informations détaillées sur chaque vulnérabilité, mais aussi un grand nombre d’outils et de projets qui vous permettront d’améliorer votre développement à partir de bonnes pratiques.

Vérifier votre code alors même que vous l’écrivez

Il existe de nombreux outils d’analyse du code source qui peuvent être utilisés dans le cadre du Static Application Security Testing (SAST). Les technologies SAST sont conçues pour analyser le code source afin d’identifier les vulnérabilités avant la compilation.

Les solutions SAST peuvent être intégrées directement dans l’environnement de développement et utilisent des techniques d’analyse de code statique pour alerter le développeur de tous les types d’erreurs et de vulnérabilités qui peuvent entrer le code. Cette rétroaction immédiate s’avère très utile, surtout comparé à la découverte d’une vulnérabilité plus tard dans le cycle de développement.

Ces analyses permettent aux développeurs de surveiller constamment leur code et d’identifier rapidement les problèmes. De plus, l’examen du code fournit des renseignements détaillés pouvant contribuer à une atténuation rapide et à une plus grande intégrité du code.

Bien que ces outils s’avèrent très utiles pour identifier les vulnérabilités connues, comme les injections SQL ou les débordements de tampon, ils ne constituent pas une panacée. En effet, il existe de nombreux autres types de vulnérabilités qui sont plus difficiles à détecter automatiquement, comme les erreurs de configuration, les problèmes d’authentification ou les erreurs dans la logique logicielle. De plus, en n’exécutant pas ou en ne testant pas le code, vous risquez de faire face à un autre problème majeur : les faux positifs, qui peuvent générer des distractions ou une perte de temps dans votre révision. Il est important de choisir les bons outils, en tenant compte du langage, de l’environnement de développement, du type de code qui va être analysé et des vulnérabilités qu’il va détecter.

Si vous voulez commencer à utiliser ces outils, nous vous recommandons de consulter la liste publiée par OWASP, qui comprend à la fois vos propres projets et d’autres options open source. Vous pouvez également consulter la liste disponible sur Wikipedia, où vous retrouverez des outils sont regroupés par langage de programmation et quelques options pour la vérification des codes compilés.

Inclure la sécurité dans vos tests

Tous les logiciels doivent être testés avant d’être mis en production. À l’étape des tests, en plus de vérifier que l’application adopte le comportement souhaité et ne génère pas d’erreurs inattendues, il est également important de faire de votre mieux pour vous assurer qu’elle est sûre et ne présente aucune vulnérabilité. Pour ce faire, on peut utiliser les outils DAST (Dynamic Analysis Security). Les outils DAST, au lieu d’examiner le code source, s’exécutent en dehors de l’application et lancent des requêtes malveillantes contre elle afin de découvrir les vulnérabilités en analysant les réponses qu’ils reçoivent.

Puisque l’application est testée en DAST au moment de son exécution, il n’est pas nécessaire d’avoir le code source pour faire les vérifications. De plus, à ce stade, d’autres types de vulnérabilités qui n’ont pas été détectées auparavant avec le SAST peuvent l’être. Pensons par exemple à de mauvaises configurations, des protocoles non sécurisés ou des problèmes logiques. Contrairement à l’analyse statique qui peut être utilisée immédiatement, il est cependant nécessaire dans cette analyse de personnaliser les règles contre ces scénarios possibles (mauvaises configurations, protocoles non sécurisés, etc.), de faire et d’adapter les requêtes couvrant toutes les entrées possibles selon l’application à analyser.

Il existe de nombreux outils d’analyse dynamique que vous pouvez utiliser. Cependant, la plupart d’entre eux requièrent malheureusement des licences payantes, étant donné leur maintenance élevée. Quoi qu’il en soit, si vous voulez revoir une liste complète, qui inclut à la fois des options commerciales et open source, nous vous recommandons de consulter la liste OWASP des Scanners de vulnérabilités.

Enfin, mettez toujours en œuvre toujours les bonnes pratiques de développement sûr, car aucun outil automatisé ne le fera pour vous. N’oubliez pas de toujours mettre à jour vos outils, à la fois l’EDI et les plugins, ainsi que les autres applications supplémentaires que vous gérez, et d’éliminer les modules et fichiers qui ne sont pas utilisés. N’oubliez pas d’enregistrer tous les événements dans vos journaux de sécurité et évitez d’afficher les messages d’erreur tels qu’ils sont affichés par le système.

Profitez bien de la Journée des programmeurs, et rappelez-vous : un logiciel de qualité, c’est aussi un logiciel sécurisé!

 

Discussion