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

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

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.

Pièce jointe 461100
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.

Pièce jointe 461105
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 ?

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

Voir aussi

:fleche: 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é

:fleche: 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

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

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...

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 ...

Citation:

---

Envoyé par transgohan

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

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

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.

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 ?

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

:fleche: Aimez-vous la lettre A ? La lettre U ?

:fleche: 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.

Ce genre d'étude pourrait avoir un sens.
Mais sauf erreur de ma part, la source de cette article ne cite aucune source.
Donc pas moyen de vérifier la méthodologie de l'étude en question...

Il y a quand même un disclaimer qui ne s'applique pas qu'au C

Citation:

---

For starters, more code has been written than any other language, providing more opportunities for vulnerabilities to be discovered.
The fact is that C has been in use for much longer than most other languages, and is behind the core of most of the products and platforms we use.
As such, it is bound to have more known vulnerabilities than the rest.

---

et en lisant un peu on peut comprenre leur procédé... mais pas de lien vers l'étude en question

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.

Citation:

---

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)

---

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.

Le souci c'est que ça attire des commentateur fort éclairés, mais comme on dit au royaume des aveugles les borgnes sont rois.

Alors Uther, on loue peut-être tes compétences, mais en terme de sécurité, tu n'es peut-être pas aveugle, mais pas borgne non plus.

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.

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, ....


Comme le Java et le Python sont des langages de haut niveau, c'est pour ça qu'ils introduisent moins de vulnérabilités. Java pour sa part intègre les Prepared Statement depuis très très longtemps pour justement gérer les requêtes SQL. Le développeur n'a plus a filtrer son entrée, c'est la classe qui le fait pour lui justement. Alors après libre au développeur de l'utiliser ou pas. Si il en est encore à utiliser '+' pour concaténer sa requête à son filtre qu'il a récupérer depuis son application c'est son problème, mais c'est pas la façon de faire.

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.

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, ...

Par exemple, j'ai connu des clients qui ne voulaient pas utiliser de framework Java car ça évolue trop vite par rapport à leur capacité à s'adapter.

Désolé, je ne souhaite pas paraître prétentieux, mais ce qui est dis est tout simplement faux...

Citation:

---

Envoyé par Manu940

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

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

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

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

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

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.

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 ?.

Super étude sur rien du tout d'exploitable. Il n'y a rien sur la qualité des langages de programmation parce que l'étude porte sur les défauts des logiciels créés avec les langages et pas les langages eux-même. Qui imagine que le C, périmètre Kernighan & Ritchie, ait la moindre faiblesse ?
Et pourtant c'est là qu'est le langage C et pas dans les librairies et les programmes réalisés avec. Donc ce n'est pas le langage qui est en faiblesse et le titre est menteur.

Ensuite, comment est comparé un langage comme le C, tout "nu", face à un langage compilé avec des extensions nombreuses par défaut comme le PHP ? Ah, oui, il s'agit d'une étude sur le code fait avec ces langages, rien à voir.

Bon, reste à imaginer ce que les chiffres valent dans l'absolu. Peut-être est-ce que certains langages, par les développeurs qui s'en servent, est plus susceptible de provoquer des erreurs ? Facile, comparons le nombre de problèmes signalés avec le nombre de ligne codées / le nombre de codeurs en activité / n'importe quoi lié à l'activité autour du langage. Et bien non, il y a des pourcentages (c'est joli, hein ?) mais rien lié à l'activité autour du langage, juste un ratio entre bugs d'applications développée entre les langages sans aucune considération pour leur popularité. Bref, si Ruby a deux fois plus de bugs que PHP mais qu'il est utilisé vingt fois moins, il apparaîtra plus sûr dans ces stats.

Ok, mes raisonnements ont une faiblesse majeure: l'étude initiale est peut-être bien plus soutenue que l'article qui la résume. Alors allons directement voir à la source ... mais il n'y a pas de liens.

Bref, c'est pas la joie parce que la base de cet article n'est vraiment pas au top.

Citation:

---

Envoyé par jeanluc75

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 ?.

---

En effet les failles technique d'un langages résident généralement dans leur implémentation, mais cette pseudo-étude ne porte pas du tout là dessus.
Elle fait juste un compte du nombre de failles dans les logiciel recensés sur les registres de vulnérabilité, en fonction du langage dans lequel elles ont été écrites.

Citation:

---

Envoyé par bmayesky

Ok, mes raisonnements ont une faiblesse majeure: l'étude initiale est peut-être bien plus soutenue que l'article qui la résume. Alors allons directement voir à la source ... mais il n'y a pas de liens.

---

Alors si il y a un lien vers la source

Citation:

---

Source : WhiteSource

---

Après le classement du nombre de vulnérabilité par langage, il fait aussi un classement des différents types de vulnérabilités par langage. C'est déjà plus intéressant, mais ça a déjà été fait depuis longtemps et n'apprend rien de surprenant : erreur mémoires majoritaires en C/C++, injection et XSS dans les langages managés, problèmes de non validation des entrées partout.

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.

Ensuite, d'expérience personnelle (donc réfutable, évidemment), les langages qui ont été montrés sont d'autant plus vulnérables qu'ils sont à la fois populaires, et modulables. Ça ne me surprend guère que le C et le Java arrivent dans le haut du panier, car ce sont des langages qui s'exportent facilement pour les systèmes embarqués qui sont de plus en plus nombreux dans nos poches. Ce n'est pas le cas du C++ -- 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.

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.

Citation:

---

Envoyé par PirBip

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

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

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).

Désolé Uther, j'ai relu nos 2 messages et je n'ai pas l'impression d'avoir déformé vos propos.
De mon point de vue je trouve votre avis un peu naïf, et il y aurait d'autres choses à développer, mais bon ça n'est pas l'objet.

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 tout cas j'ai bien rigolé pour l'Ada, j'avais fait mon possible pour ne pas le citer :-)

Et je vous en prie pour le compte. J'en avait déjà un que j'avais fait supprimé, mais quand je vois les raccourcis pris par l'article et les personnes qui votent négativement sans ouvrir la bouche (ou utiliser leur clavier plutôt clicker de façon névrotique sur leur souris) je commence à me rappeler pourquoi j'avais supprimer le précédent...

bmayesky, le C n'est pas un langage tout nu, il repose sur des bibliothèque pour étendre ses possibilités, comme le PHP.....

Citation:

---

Envoyé par Manu940

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.

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 ^^

Si cette étude recense les personnes créant des vulnérabilités dans leurs développements, ça ne rend pas les langages vulnérables...
Voilà une étude qui ne sert à rien du tout, si ce n'est mettre l'accent sur l'inconscience de certains quand ils codent.
On le sait bien que de très nombreuses personnes apprennent les rudiments d'un langage en zappant totalement l'aspect sécurité, copiant/collant de ci de là sur le net des rustines de code peu ou pas comprises. Pas besoin d'étude pour ça.

J'aurais préféré une étude qui pointe du doigt les faiblesses et vulnérabilités des langages, pas celles de leurs utilisateurs. :calim2:

il est normale qu'un langage de bas niveau (pas nul, mais qui inclus peu de fonction) comme le C obtient une mauvaise note à ce type d'étude lorsque l'on regarde les produit finaux généré. (Moins de fonction = refaire le monde ; fonction résultante moins testé....)

A l'inverse, si on fessait une étude sur chaque commande de base d'un langage, le C serait grand gagnant ! (peux de fonction = moins de problème !)

Citation:

---

Envoyé par emixam16

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 :

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

---

Merci pour cette étude qui m a bien fait rire et vaut tout autant bien des études faites par des "cabinets spécialisées"! :)

et youpi pour le BrainFuck :)
https://en.wikipedia.org/wiki/Brainfuck

d ailleurs, choix très audacieux par rapport à l article: peux t on dire que la sécurité d un langage est aussi lié à sa complexité: un truc comme le BrainFuck est tellement illisible qu il y ait des fortes chances de faire des erreurs de programmation, et donc potentiellement de sécurité.
Mais cela n'a en fait rien à voir avec la sécurité: c est juste plus ou moins probable que l humain fasse des conneries!