Les développeurs auraient du mal à implémenter correctement des bibliothèques de chiffrement
Les développeurs auraient du mal à implémenter correctement des bibliothèques de chiffrement,
parce qu'ils n'ont pas reçu de formation spécifique
VeraCode, une entreprise spécialisée dans la sécurité des applications, a publié le sixième volume de son état des lieux de la sécurité des logiciels. Cette sixième édition s’est concentrée sur l’industrie verticale. Pour établir ses statistiques, Veracode s’est appuyé sur des milliers d’applications (208 670) et plus d’un trillion de lignes de code qui ont été analysés par sa plateforme cloud.
La qualité du code s’est avérée être le vecteur de vulnérabilité le plus observé dans les industries. Avec 56 %, l’industrie de construction observe le pourcentage le moins élevé de ce type de vecteur tandis que l’industrie de la santé observe 80 %.
Les problèmes liés au chiffrement ont occupé la seconde place du classement des catégories de vulnérabilité par industrie verticale. Ces problèmes incluent par exemple des informations sensibles stockées en clair, une force de chiffrement inadéquate, une entropie insuffisante, une vérification des signatures numériques inadéquate, etc.
Les développeurs rajoutent beaucoup de bibliothèques de chiffrement à leur code, en particulier dans des secteurs comme la santé ou les services financiers, mais ils le font mal, explique Chris Wysopal, le Directeur technique de VeraCode. De nombreuses organisations ont besoin d’utiliser le chiffrement en raison des règlements de protection des données, mais le rapport suggère que leurs développeurs ne possèdent pas la formation nécessaire pour le mettre en œuvre correctement.
« Ceci va montrer combien il est difficile de mettre en œuvre le chiffrement correctement », a déclaré Wysopal. « Il s’agit en quelque sorte d’un problème endémique auquel beaucoup de gens ne pensent pas », estime-t-il. Beaucoup de développeurs croient qu'ils savent comment mettre en œuvre un chiffrement, mais n’ont pas reçu de formation spécifique en chiffrement et ont un faux sentiment de sécurité, estime-t-il. Par conséquent, même s’ils finissent avec des applications où le chiffrement est présent, les attaquants sont toujours en mesure d'obtenir des données sensibles. Et cela ne concerne même pas les cas où les développeurs décident de créer eux-mêmes leurs propres algorithmes de chiffrement.
« Le choix du langage pour le développement logiciel peut avoir un grand impact sur les applications. Bien que certains langages et modèles de programmation éliminent complètement certains problèmes de sécurité (par exemple, les problèmes de gestion d’un tampon commun à C / C ++ sont complètement éliminés en Java ou en .NET), il arrive que le choix du langage de programmation soit influencé par d’autres facteurs que la sécurité. La disponibilité de développeurs qualifiés, les langages de programmation utilisés par les fournisseurs et d'autres points encore peuvent conduire à des différences significatives de l'industrie dans le choix du langage de programmation », avance le rapport.
Pourtant, Carsten Eiram, le chef de la recherche à Risk Based Security, estime que « de nombreuses personnes soutiennent que, puisque les langages de programmation modernes sont plus faciles à utiliser et réduisent encore plus les possibilités d’erreur des développeurs, plusieurs d'entre eux peuvent se bercer dans un faux sentiment de sécurité et ne pas être assez soignés dans leur développement, c’est-à-dire accroître le risque d'introduire d'autres types de problèmes comme les erreurs de conception et de logique. Ne pas mettre en œuvre correctement un chiffrement rentrerait dans cette catégorie ».
De nombreux développeurs pensent qu'ils peuvent juste mettre un lien vers une bibliothèque de chiffrement pour que le tour soit joué, mais un chiffrement solide peut s’avérer difficile à mettre en œuvre si vous n’en comprenez pas les aspects les plus subtils comme la vérification correcte des certificats, la protection des clés de chiffrement, l’utilisation de taille de clé appropriée ou l’utilisation de générateurs de nombres pseudo-aléatoires solides. « Tout cela revient finalement à une meilleure éducation des programmeurs afin qu’ils comprennent tous les pièges lors de la mise en œuvre d’un chiffrement fort », a estimé Eiram.
Mais la faute n’incombe pas uniquement aux développeurs. Matthew Green, un professeur d’ingénierie de chiffrement à l'Université Johns Hopkins à Baltimore, pense que de nombreuses bibliothèques de chiffrement sont « franchement mauvaises » d'un point de vue ergonomique parce qu'elles ont été conçues par et pour les cryptographes. « Obliger les développeurs à les utiliser c’est comme s’attendre à ce que quelqu’un pilote un avion alors qu’il a un permis de conduire », avance-t-il. Pour lui, faire des logiciels de chiffrement plus faciles à utiliser serait plus efficace que former des développeurs à devenir cryptographes.
Il faut dire que certains auteurs de bibliothèques de chiffrement y travaillent. Par exemple, sur la feuille de route du projet OpenSSL publiée le 30 juin dernier, sur le paragraphe concernant la complexité de la liberté ils reconnaissent que « les bibliothèques et applications OpenSSL sont complexes, à la fois du point de vue de la personne effectuant la maintenance, mais également de celui qui les utilise ». Raison pour laquelle ils ont décidé de « revoir et modifier l’API avec pour objectif la réduction de la complexité » sur une période d’un an.
Pourtant, bien qu’il ne conteste pas le fait que certaines bibliothèques soient trop complexes, Eiram ne pense pas qu’il faille que les développeurs soient des cryptographes pour implémenter correctement des chiffrements. Pour lui, les API de chiffrement dans Java et .NET, les deux langages les plus utilisés dans les industries verticales d’après le rapport de Veracode, ont été conçus pour les développeurs et leur fournissent la plupart de ce dont ils ont besoin en termes de fonctionnalités de chiffrement lorsqu’ils développent leurs applications.
« Bien qu’il soit préférable que les bibliothèques incluant des bibliothèques de chiffrement soient conçues pour être utilisées le plus aisément possible, les développeurs qui choisissent de les utiliser doivent au moins comprendre à un haut niveau comment elles fonctionnent. Je vois ici une voie à double sens : faciliter l’utilisation des bibliothèques de chiffrement, mais également des développeurs qui doivent implémenter un chiffrement dans leurs applications qui se renseignent convenablement au lieu d’attendre que quelqu’un leur tienne la main », a-t-il avancé.
En plus d’une absence d’expertise parmi les développeurs sur un projet ou de la complexité de certaines bibliothèques de chiffrement, Green a avancé qu’oublier de réactiver les fonctionnalités de sécurité après avoir testé un produit est une autre erreur commune. Par exemple, des développeurs peuvent désactiver une validation de certificat TLS dans leur environnement test parce qu’ils ne disposent pas de certificat valide installé sur leur serveur test, mais après oublient de la réactiver une fois que l’application passe en production.
« Il y a deux ans, un article avait paru sur un grand pourcentage d’applications Android qui étaient victimes de telles erreurs », a rappelé Green. Wysopal a indiqué que l’incapacité à valider correctement des certificats TLS a souvent été observée par Veracode durant leurs tests de sécurité.
Source : Veracode, feuille de route OpenSSL
Et vous ?
Avez-vous déjà utilisé une bibliothèque de chiffrement ? Laquelle ?
Répondre avec citation
Envoyé par Fleur en plastique
Partager