Aujourd'hui, nous vivons dans un monde d'insécurité et de manque d'intimité. Des systèmes d'exploitation eux-mêmes aux programmes que nous utilisons tous les jours, il est très courant de trouver toutes sortes de vulnérabilités qui peuvent compromettre notre sécurité. Cependant, à qui la faute est-elle due à des failles de sécurité? Des développeurs? Des langages de programmation? Existe-t-il des langages de programmation sûrs et non sécurisés? Ou les deux parties sont-elles vraiment à blâmer?
Les systèmes d'exploitation et programmes sont des projets vraiment complexes. La moindre erreur ou erreur dans l'une des centaines de bibliothèques peut mettre notre programme en danger. Tous les langages de programmation sont, par défaut, sûrs. Si nous les utilisons bien, ils n'ont pas à mettre les utilisateurs en danger. Bien qu'il existe maintenant langues beaucoup plus sujettes aux échecs (en raison d'incidents, de la complexité ou de l'absence de mesures de sécurité) pouvant entraîner des vulnérabilités de toutes sortes.
Langages de programmation plus sûrs
De tous les langages de programmation les plus utilisés, celui qui présente le moins de vulnérabilités est Rubis. Ce langage de programmation n'a été affecté que par 5% des vulnérabilités. De plus, de manière générale, c'est l'un des langages les plus sûrs et les plus robustes, car bien que plusieurs vulnérabilités y aient été signalées, la seule qui soit vraiment inquiétante est la possibilité de lancer des attaques XSS. Si la langage de programmation le plus sûr étaient à recommander, ce serait l'idéal pour le titre.
C ++ est un autre des langages de programmation avec le moins de vulnérabilités que nous pouvons trouver, avec seulement 6% de code vulnérable. Cependant, il n'est pas exactement l'un des plus débogués, car il présente un grand nombre de problèmes de corruption de mémoire et d'erreurs de mémoire tampon qui peuvent conduire à des attaques informatiques plus complexes.
Poursuivre la liste des langages de programmation sûrs avec moins de vulnérabilités python. Dans le passé, cette langue était l'une des pires en termes de sécurité. Cependant, ces dernières années, il s'est beaucoup amélioré et a résolu la plupart des problèmes qui l'ont touché par le passé. Bien sûr, il présente toujours les vulnérabilités les plus critiques que nous pouvons trouver aujourd'hui, telles que le manque de validation d'entrée, l'escalade de privilèges, la fuite d'informations et XSS. Si nous savons comment programmer en Python, nous pouvons avoir un programme robuste. Mais si nous programmons mal, nous aurons littéralement une passoire.
Et il a aussi des JavaScript mentionner . Ceci est également largement utilisé dans le développement Web et ne cache que 11% des vulnérabilités. Parmi ses principales faiblesses figurent les problèmes de cryptographie, qui nous obligeront à utiliser des API tierces pour les résoudre.
Langues avec plus de vulnérabilités
D'autre part, parmi les langages de programmation les plus vulnérables, le premier que nous allons trouver est C. Et cela est évident, car c'est l'un des langages de programmation dans lesquels il y a plus de code écrit (en particulier l'ancien code), donc la probabilité de découverte de vulnérabilités dans ce code est très élevée. Parmi les vulnérabilités totales trouvées, 47% sont dans du code écrit dans ce langage de programmation. Cependant, des bogues en tant que tels spécifiques à la langue n'ont été trouvés que deux, une erreur de tampon et différents problèmes de validation.
PHP est l'un des langages les plus utilisés dans la programmation web (backend) et, par conséquent, l'un des plus frappants pour les pirates. C'est le deuxième langage de programmation avec le plus de vulnérabilités (17% du total), et ce qui est le plus frappant, c'est que ce langage est le seul qui a des vulnérabilités critiques telles que SQL Injection, et qui peut également être exploité via XSS. Deux vulnérabilités hautement exploitées sur le réseau et difficiles à éliminer.
Et bien sûr, nous ne pouvions pas finir sans parler de Java. Le langage de programmation multiplateforme si utilisé il y a quelques années est également l'une des vulnérabilités les plus cachées à l'intérieur, en raison de sa complexité. 12% des vulnérabilités se trouvent dans ce langage de programmation qui, bien qu'il ait perdu beaucoup de popularité ces derniers temps, reste l'un des piliers fondamentaux de Android.
Réutiliser le code: avantage ou risque?
Actuellement, il est possible de trouver une grande quantité d'open source sur des plateformes telles que GitHub. Ce code, en fonction de la licence dont vous disposez, peut être librement réutilisé dans d'autres types de projets, ce qui peut nous faire gagner beaucoup de temps lors de l'élaboration de nos programmes. Cependant, la réutilisation du code cache l'un des OpenSource les plus gros problèmes : vulnérabilités.
Il est très courant pour tous les types de développeurs, y compris les grandes entreprises comme Microsoft ou Google, pour profiter des bibliothèques ouvertes pour apporter certaines fonctions et fonctionnalités aux utilisateurs. Jusqu'ici tout va bien, car, en plus, cela donne un peu de transparence aux projets opaques que ces entreprises créent habituellement. Cependant, il faut garder à l'esprit un handicap très important: une vulnérabilité dans une bibliothèque open source mettra automatiquement en péril tous les projets qui l'utilisent.
Nous avons déjà vu vulnérabilités majeures (comme OpenSSL) qui ont mis en échec la sécurité de milliers de programmes et de plateformes à travers le monde. De plus, lorsqu'une vulnérabilité de ce type est découverte, il est nécessaire, d'une part, pour le développeur du projet d'origine de mettre à jour sa bibliothèque, et d'autre part, pour les développeurs des programmes vulnérables d'inclure la nouvelle version dans leur programme grâce à une mise à jour.
Réutilisation du code est l'une des caractéristiques des programmes et systèmes modernes. Mais nous ne devons jamais nous faire confiance, car la probabilité qu'une vulnérabilité apparaisse dans le code que nous avons utilisé est beaucoup plus élevée que si nous avions créé le code nous-mêmes.
