IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quel langage de programmation comporte le plus de vulnérabilités en matière de sécurité ?
Une étude de WhiteSource

Le , par Bill Fassinou

1.1KPARTAGES

13  4 
On peut affirmer sans aucun doute qu’aucun des langages de programmation qui existe n’est sans vulnérabilité qu’il s’agisse du C/C++, du Java, du Ruby, du PHP ou encore le JavaScript. Et bien, WhiteSource s’est penché sur le sujet et a publié récemment un rapport présentant quelques-uns des langages qu’il juge les plus vulnérables selon des informations recueillies au sein de la communauté open source.

L’un des débats les plus récurrents entre les développeurs et les ingénieurs porte sur le langage de programmation le plus rapide parmi tous, mais la question de savoir lequel d’entre eux offre le plus de sécurité ne se pose pas souvent. Cependant, à la limite de la rapidité, les entreprises recherchent aujourd’hui également plus de sécurité qu’autrefois. Les menaces sur les systèmes informatiques et les applications métiers des entreprises sont grandissantes et même si, les langages de programmation ne cessent d’être régulièrement mise à jour, les pirates et les experts en sécurité parviennent toujours à trouver des failles de sécurité dans leur conception.

Vous avez sûrement votre idée du langage le plus sécuritaire, mais qu’en est-il du moins sécurisé d’entre eux ? Pour cela, WhiteSource, une plateforme de gestion de la sécurité et de la conformité des licences open source fondée en 2011 par Ron Rymon, Azi Cohen et Rami Sass, a mené récemment une étude visant à collecter pour les 7 langages de programmation les plus utilisés, le nombre de vulnérabilités signalées par la communauté open source pour chacun d’entre eux et ainsi, présenter un index de ceux ayant un nombre de vulnérabilités plus élevé.

L'étude s’est appuyée sur une base de données regroupant des informations provenant de sources diverses telles que la base de données nationale sur les vulnérabilités des USA (NVD), les avis de sécurité, GitHub et d’autres projets populaires liés au suivi des problèmes. WhiteSource a souligné le fait que le rapport tient en compte seulement les sept langages les plus populaires utilisés ces dix dernières années dans la communauté open source notamment le C, le Java, le JavaScript, le Python, le Ruby, le PHP et le C++.

Ensuite, WhiteSource a précisé que l’étude a vérifié pour chaque langage de programmation quelles étaient ses CWE les plus courantes. Cela a révélé que les vulnérabilités les plus courantes dans la plupart de ces langages sont le Cross-Site Scripting (XSS), la validation des entrées, les autorisations, les privilèges, les contrôles d'accès, etc. Il faut noter cependant que CWE fait référence à une liste mise au point par la communauté qui recense les faiblesses courantes en matière de sécurité des logiciels. Il sert de langage commun ou de jauge pour les outils de sécurité logicielle et de base pour les efforts d'identification, de réduction et de prévention des failles.


Pourcentage des vulnérabilités reportées par la communauté open source

C’est donc sur la base de tout ceci que la plateforme a présenté son index. WhiteSource indique qu’en dix ans, C a montré un nombre de vulnérabilités très important. Il arrive donc en tête de liste des langages les plus vulnérables avec une faiblesse reconnue à 47 % de toutes les vulnérabilités signalées. Pour former le trio des langages présentant le nombre de vulnérabilités le plus élevé, le PHP et le Java suivent respectivement 17 % et 12 %. Le JavaScript vient en quatrième place avec 11 %, le Python et le C++ restent en cinquième place avec 6 % chacun et le Ruby ferme le podium avec un nombre de vulnérabilités open source connu de 5 %. Il est donc le moins vulnérable parmi ces sept langages de l’étude.

Cela dit, un nombre de vulnérabilités élevé pour un langage signifie-t-il que le langage est moins sécurisé que les autres ? WhiteSource semble avoir répondu non. Il explique que plus le volume de code écrit dans un langage est élevé et plus le nombre de vulnérabilités est susceptible d’être élevé pour ce dernier ou cela peut également dépendre d’autres facteurs. « Le nombre élevé de vulnérabilités dans C peut s’expliquer par plusieurs facteurs. Pour commencer, l’utilisation de C remonte à plus longtemps que n’importe lequel des autres langages que nous avons recherchés. Il possède le volume de code écrit le plus élevé et c'est l'un des langages derrière des infrastructures majeures telles que OpenSSL et le noyau Linux. Cette combinaison gagnante de volume et de centralité explique le nombre élevé de vulnérabilités Open Source connues en C », précise WhiteSource à propos du langage C.


vulnérabilités par langage au fil des années

Selon l’analyse de WhiteSource, le nombre de vulnérabilités reconnu pour chaque langage de programmation a augmenté très rapidement au cours des dix dernières années avec une augmentation particulière en 2017. Cet état de choses résulterait de la popularité croissante de l’open source qui a permis de découvrir plus de problèmes au sein des logiciels. De plus, énonce le rapport, les outils de sécurité automatisés et les investissements croissants dans les programmes de bug bounty ont largement contribué à faire grandir les bases de données des vulnérabilités des langages.

Source : WhiteSource

Et vous ?

Que pensez-vous des résultats de cette analyse ?
Selon vous, quel est le langage de programmation le moins sécurisé ? Pourquoi ?

Voir aussi

Quel langage de programmation pour le Web est-il plus sécurisé ? Selon une étude, les langages populaires ont presque le même degré de sécurité

Internet aurait de sérieux problèmes à cause de langages comme C et C++ favorisant la survenue de failles mais peu de développeurs s'en soucieraient

Rust 1.21 est disponible en téléchargement le langage de programmation centré sur la sécurité et la vélocité

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 26/03/2019 à 7:59
Encore une statistique idiote, genre TIOBE, réalisée par des gens qui veulent à partir d'un travail simpliste présenter des jolis chiffres faciles à faire ingurgiter aux décideurs, sans se soucier de leur pertinence réelle. Ces chiffres se retrouvent ensuite relayés par des distributeurs de news, soit incompétents sur le sujet, ou pire qui veulent juste faire du clic quitte à diffuser n'importe quoi.

C'est sur que c'est plus sexy de présenter un concours de celui qui à la plus grosse, mais ces chiffres sont sans le moindre intérêt vu qu'il tombent dans touts les biais possibles et imaginables. Que se soit la représentativité de l'échantillon, la quantité de code disponible pour chacun des langages, les cas d'utilisations ...
18  0 
Avatar de emixam16
Membre chevronné https://www.developpez.com
Le 26/03/2019 à 10:32
Wow, moi aussi j'ai toujours rêvé de publier une étude faisant dire n'importe quoi à des données sous-représentatives voire absurdes et de présenter les résultats comme une réponse générale à un problème complexe.

Allez, je me lance :

Toutes les lettres de l'alphabet ne sont pas aussi jolies les unes que les autres. Selon une étude très éclairante menée par le site https://www.alphabet.exionnaire.com/...ree-f3794.html , la lettre A arriverait largement en tête suivie des lettres M et S. En revanche la lettre U parait particulièrement impopulaire auprès du panel avec seulement 5 suffrages contre 250 pour la lettre A.

Dans cette étude, on trouve des témoignages édifiants comme celui de gelamboo qui préfère la lettre H car parce que « c'est le premier barreau de la courte-échelle de l'hinspiration » ou de bonetout qui préfère la lettre Y parce que "YOUPI".

Il parait donc clair qu'un langage de programmation de qualité est donc forcément un langage qui utilise majoritairement les lettres préférées des Français.

Dans cette étude, nous évaluons donc le meilleur langage de programmation*
C 76,98%
Java 63 ,75%
Python 49,05%
BrainFuck NaN

On remarque de manière claire que le langage C est objectivement largement meilleur que les autres et que toute entreprise voulant accélérer sa transformation digitale devrait l’utiliser sans délai dans tous ses projets, y compris Web.
On remarque toutefois que BrainFuck contourne ce problème de manière astucieuse en n’utilisant aucune lettre, évitant ainsi les débats clivants. Se pourrait-il que ce soit une stratégie gagnante ?

Et vous ?

Le BrainFuck est-il l’avenir de l’informatique ?

Aimez-vous la lettre A ? La lettre U ?

Allez-vous continuer à utiliser des langages dépassés comme le Java ou le Python ou tout miser sur le C ?

* Méthodologie: Nombre de lettres A sur nombre de lettre U. Testé sur un fichier arbitraire sur mon ordinateur **
** C'est mon étude bidon, je fais ce que je veux.
15  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 26/03/2019 à 6:36
J'ai un peu de mal à cerner l'étude.
Parle-t-on des vulnérabilités de codage des applications ou bien du langage en lui même ?
J'ai l'impression que c'est plutôt le premier aspect.
On pense tout de suite que c'est un problème de connaissance du dit langage par les développeur qui entraîne la création de vulnérabilités dans leurs applications.
Pour moi même avec un langage qui fait la café pour nous on peut insérer des vulnérabilités si on l'utilise n'importe comment.

Pour utiliser une image :
Si on dit que le langage C est une voiture lambda, que la vulnérabilité c'est qu'avec l'utilisateur peut sortir de la route s'il ne fait pas attention...
Beh même une voiture avec un système de contrôle des lignes blanche (qui serait donc un langage plus "sécurisé" ne va pas solutionner entièrement le problème, on peut toujours sortir de la route et avoir un accident.

De fait pointer le langage comme étant la source est caduc.
C'est plutôt la communauté utilisant le langage qui devrait être ciblé.
D'ailleurs la conclusion vient contredire le titre du coup...
12  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 26/03/2019 à 8:23
Citation Envoyé par transgohan Voir le message
J'ai un peu de mal à cerner l'étude.
Parle-t-on des vulnérabilités de codage des applications ou bien du langage en lui même ?
J'ai l'impression que c'est plutôt le premier aspect.
En effet on parle bien de faille dans les applications.

Le site s'est contenté, à peu de choses près, de compter le nombre failles publiées dans les registres de sécurité style CVE, par langage de l'application. Un parfait exemple de mauvaise utilisation de données pourtant très utiles. C'est complètement idiot de procéder ainsi, notamment parce que les langages les plus utilisés vont évidement se retrouver surreprésentés. De plus les domaines d'utilisation des langages étant différents, les vulnérabilités ne sont pas directement comparables.

Citation Envoyé par transgohan Voir le message
On pense tout de suite que c'est un problème de connaissance du dit langage par les développeur qui entraîne la création de vulnérabilités dans leurs applications.
Pour moi même avec un langage qui fait la café pour nous on peut insérer des vulnérabilités si on l'utilise n'importe comment.
Disons que si aucun langage n'est protégé d'une mauvaise utilisation, il est cependant indéniable que tous les langages ne sont pas égaux face aux risques. Chaque langage fournit plus ou moins de garde fous qui évitent certaines mauvaises utilisations et donc certaines failles. Malheureusement, cette l'étude n'est pas du tout capable de démontrer ça, vu que c'est un simple décompte des vulnérabilités sans prise en compte du contexte.

Par exemple Le C et le C++ auront beaucoup de failles de mémoire qui sont quasi-impossibles avec des langage mangés comme Java, Python,... Mais il n'auront quasiment pas de faille d'injection pourtant il ne fournissent absolument pas de protection contre ça. C'est juste qu'ils ne sont quasiment pas utilisés dans les domaines ou ce genre de faille est prédominante(principalement le Web)

Citation Envoyé par transgohan Voir le message
De fait pointer le langage comme étant la source est caduc.
C'est plutôt la communauté utilisant le langage qui devrait être ciblé.
D'ailleurs la conclusion vient contredire le titre du coup...
La communauté du langage peut jouer, les spécificités du langage aussi, mais il ne faut pas oublier de les rapporter au domaine : on a des problème différents quand on fait du web, un OS, ou un jeu vidéo.
11  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 26/03/2019 à 18:29
Citation Envoyé par Manu940 Voir le message
pffff, cet article n'a pas grand intérêt, et il est vrai qu'il est ambigu. C'est plus un problème développeurs que de langage.
Les problèmes de sécurité applicative c'est bien sur toujours à la base un problème de développeur. Et bien sur qu'une bonne formation des développeurs est toujours le premier élément à considérer pour la sécurité, et je n'ai jamais voulu dire qu'il en était autrement.

Mais il faut aussi savoir que dans la pratique, on fait avec les développeurs que l'on a, et même les meilleurs font des erreurs, par fatigue, manque d'attention, manque de connaissances des subtilités du code existant, ... D'ailleurs rien ne m'inquiète plus que le développeur qui dit fièrement, "Je sais ce que je fais, mon code n'aura pas de problème de sécurité". Le développeur parfait, ça n'existe pas. Donc avoir des langages qui réduisent voire empêchent certains risques, ça reste bon a prendre quand c'est possible.

Citation Envoyé par Manu940 Voir le message
Les langages ne sont pas seulement différents, ça n'est pas des instructions ou une organisation du code différentes, se sont aussi des visions différentes.
On parle de niveau de langage. Les langages bas niveau ou le développeur fait ce qu'il veut et surtout pas mal de conneries et le compilateur s'en fiche, ou l’interpréteur, et les langages haut niveau où le compilateur va gérer lui même pas mal de choses.

Les langages plus bas niveau sont donc plus sensibles, et le développeur doit avoir les connaissances et le temps de gérer tous les aspects. Et en général il a ni l'un ni l'autre.
La encore, j'ai l'impression que vous me faites dire l'inverse de ce que je voulais dire. Bien sur que en dehors des seules préoccupations de sécurité, il y a des contextes plus propices a certain langages que d'autres.

Mais force est de constater que quand on considère l'aspect sécurité, les langages comme le C sont plus risqués sur pas mal de points et c'est clairement un point a prendre en compte. Si on peut se permettre de lâcher du contrôle alors Java, Python, ou d'autres langages managés peuvent être intéressant. Si on peut se permettre des contraintes de vérification du code plus fortes, alors Ada ou Rust peuvent être intéressant.

Ne voyez pas ça comme de l’opposition frontale au C, il y a bien sur il y a bien sur d'autre argument qui peuvent jouer en sa faveur, comme la portabilité, les compétences disponibles, ... Je dis juste qu'on ne peut nier que tous les langages ne sont pas égaux en terme de risques de sécurité.

Citation Envoyé par Manu940 Voir le message

Le Java est un langage plus haut niveau, il va par exemple gérer tout ce qui est mémoire. Si il y a un souci avec la mémoire, ça sera plus au niveau de l'interpréteur ou du langage qu'au niveau du code.
Comme tu prend l'exemple de la mémoire. Et encore.... Aujourd'hui les OS mettent en place pas mal de protections contre buffer overflow. Les tutos sur le sujet datent de pas mal de temps sont dépassés. Aujourd'hui c'est devenu très compliqué avec la mise en oeuvre des explois avec les canaris, ASLD, DEP, ....
Dans la pratique, on a toujours des problèmes qui font que des failles passent à travers. Donc tous les outils qui permettent de réduire les risques (langages stricts, outils de gestion mémoire, analyseurs statiques, ASLR, DEP, ...) sont bon à prendre. Le langage n'est pas l'alpha et l'oméga de la sécurité, mais c'est clairement un maillon de la chaine.

Citation Envoyé par Manu940 Voir le message
Ca m'est arrivé de trouver des injection SQL dans des programmes Java tout simplement car le développeur ne connait pas assez son langage et qu'il l'utilise mal.
En effet, c'est un exemple de quelquechose qui aurait pu être amélioré par le langage en promouvant une API mieux conçue (les Statement classiques auraient par exemple pu être dépréciés). C# a plutôt bien fait les choses en promouvant activement LINQ.
Là encore, les particularités du langage peuvent offir des moyen de réduire les mauvaises utilisation.

Citation Envoyé par Manu940 Voir le message
Donc si les C/C++ ne fournissent pas de protection contre les SQLI c'est plus un problème lié au niveau du langage que d'utilité du langage. Tu peux parfaitement utiliser du C++ pour requêter une base de données.
Le choix du langage se fait rarement sur les composants que tu vas utiliser mais sur d'autres critères. Si tu veut faire du web tu peux utiliser des framework Java ou PHP. Le choix se fera sur des critères d'universalité, de facilité de trouver des compétences, de briques déjà implémentées, de recherche de performance, ...
La encore tu me fait tenir des propos que je n'ai pas eu. Je dis clairement que le C et C++ ne sont généralement pas utilisés dans les mêmes domaines que les langages managés et que c'est justement un des points qui rend cette étude sans intérêt.

Citation Envoyé par Manu940 Voir le message
Désolé, je ne souhaite pas paraître prétentieux, mais ce qui est dit est tout simplement faux...
C'est sur qu'après avoir complètement détourné tout mes propos c'est facile de dire qu'il sont faux, c'est une superbe application de l'argumentation de l'homme de paille. Mais je suis très flatté que tu ais pris la peine de créer un compte et te soit donné tant de mal pour me dire que j'avais tort.
4  0 
Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 27/03/2019 à 16:26
Citation Envoyé par PirBip Voir le message
Je sens bien que je vais enfoncer une porte ouverte maiiiiiiiiiis... à quelqu'un qui connaît suffisamment l'assembleur, surtout qui a le temps de le lire et de le comprendre, et qui le connaît pour une plateforme donnée, aucun langage de programmation n'est invulnérable. Genre, zéro. Peau d'zob.
  • Qu'est ce que l'assembleur vient faire là dedans ?
  • On va supposer que "langage de programmation invulnérable" est un abus de langage pour "langage de programmation qui permet d'écrire des programmes invulnérables"


Donc déjà à la base, on a la question "invulnérable à quoi ?". Alors soyons large et prenons "tout comportement que le développeur n'aurait pas voulu avoir dans son programme". Première constatation : il faut savoir ce que le développeur veut de son programme, sa spécification formelle. Et tous les langages ne fournissent pas de moyens d'exprimer ça, mais ça existe. Ensuite, il faut se prémunir des erreurs de programmation une fois que l'on sait ça, et puis ben ça, on sait faire. Il y a des langages qui permettent d'arriver à ce niveau de garantie. Mais ça demande beaucoup de boulot. il faut :

  • une formalisation du langage,
  • une preuve mathématique que cette formalisation garantit qu'un programme écrit dans ce langage n'a que les bons comportements spécifiés,
  • un compilateur qui garantit que le code machine généré a la même sémantique que le programme d'entrée.


Et si vraiment on n'a pas confiance, on peut aussi demander la génération d'un certificat au fur et à mesure pour pouvoir contrôler que la preuve obtenue est bien une preuve. On atteint pas du 100%, mais on en est tellement proche que dans la pratique la différence on s'en cogne. Et donc pour ça, on peut s'intéresser à toute la famille des langages à types dépendants, qui bien que reposant sur un coeur qui n'est pas nécessairement prouvé, permettent de construire d'autres langages et leur processus de compilation, notamment des DSL, qui aboutissent à ce type de garanties. Et c'est clairement pas aberrant d'imaginer qu'à terme on soit capable de produire de gros langages avec ce type de garanties.

Citation Envoyé par PirBip Voir le message
il est assez rare d'entendre dire, même chez les devs, que "MonAppli a été développée en C++ pour un système embarqué", généralement quand on entend ça on reste dubitatif.ve , pardon je m'égare.
Il y a pas mal de monde autour de l'embarqué en C++. Et je dirais que celui qui l'évangélise le plus est probablement Dan Saks.

Citation Envoyé par PirBip Voir le message
Ces études de vulnérabilité qui tendent à prouver que tel ou tel langage serait plus vulnérable sont à mon humble avis d'énormes crottes de taureaux.
Et pourtant si l'étude avait été conduite correctement, notamment avec une méthodo cohérente et pas ... ça, on aurait pu avoir des informations intéressantes. Un langage peut factuellement être au final plus vulnérable. Sauf que ça dépend de beaucoup de choses, notamment le domaine où il est utilisé, l'expertise des développeurs et surtout les contraintes de temps et d'argent pour le développement. Avec deux développeurs ayant un niveau d'expertise semblable, disons l'un en C et l'autre en Haskell. Si on demande au dév Haskell de produire une brique logicielle qui ne soit pas un élément au raz du matériel, il le fera en un certain temps. Donnons le même temps au développeur C pour produire son soft, il est peu probable qu'à la fin du développement, le soft C soit aussi secure que le soft Haskell. Simplement parce qu'en C il est très facile d'aboutir à un UB difficile à détecter, alors qu'en Haskell c'est impossible ce qui empêche purement et simplement toute une classe d'erreur (qui sont souvent celles exploitables en C).
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 27/03/2019 à 18:29
Citation Envoyé par Manu940 Voir le message
La portabilité du C ça fait longtemps que c'est de la théorie, d'où l'intérêt du java à sa sortie.
En effet le C à théoriquement pas mal de problèmes de portabilité par rapport à certains langages comme Java.

Mais dans la pratique il garde un énorme avantage : il existe un compilateur C disponible pour quasiment toutes les architectures existantes, ce qui est loin d'être le cas des VM Java ou des langage compilés modernes. Il y aura certes probablement un effort d'adaptation du code, mais on peut porter un code C sur quasiment n'importe quel OS, microprocesseur ou microcontrôleur, même les plus folkloriques.
3  0 
Avatar de Mandraxx
Membre averti https://www.developpez.com
Le 29/03/2019 à 21:46
Perso, j'ai l'impression que çà ressemble à une étude purement statistique avec peu d'analyse.

47% de vulnérabilités sur le C alors que c'est un langage qui est à la base (directement ou indirectement) de quasiment tous les systèmes en production, ce n'est pas étonnant. Ca ne veut pas forcément dire que le langage est vulnérable mais qu'il y a statistiquement plus de chances de trouver une vulnérabilité au niveau des couches C tout simplement parce qu'il y en a beaucoup.

Par exemple, je ne vois pas COBOL : peut-être parce que c'est un langage back-office donc pas au feu et peu attaqué. Pourtant, je suis presque certain qu'on peut identifier des vulnérabilités sur des programmes COBOL (bug de l'an 2000, qui s'en rappelle ?).

Bref, il faudrait un peu laisser les analyses systématiques de côté et remettre un peu de cerveau humain dans l'analyse des chiffres ^^
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 26/03/2019 à 11:44
Citation Envoyé par neuneutrinos
Il y a quand même un disclaimer qui ne s'applique pas qu'au C
Sauf qu'un disclaimer c'est tolérable pour des écarts à la marge. Là, vu que la quantité de code n'est prise en compte pour aucun des langages, on a de base un énorme biais (et ce n'est malheureusement pas le seul) qui fausse complètement tous les résultats.

Publier un rapport en grand sur son site en annonçant que tous les chiffres sont substantiellement faux et qu'on essaie même pas de les corriger, c'est clairement dire qu'on en a rien a foutre : on veut juste donner des chiffres a manger aux gens.

Citation Envoyé par neuneutrinos
et en lisant un peu on peut comprendre leur procédé...
Et constater qu'il ne sert à rien pour tirer la moindre conclusion sur la sécurité des langages.
2  0 
Avatar de jeanluc75
Nouveau membre du Club https://www.developpez.com
Le 26/03/2019 à 23:39
ce ne serais pas plutôt les compilateurs ou les runtimes qui ont des failles,
parce que un langage après tout c'est juste une norme ?.
2  0