Si vous utilisez Java comme la plupart des autres langages de programmation, par exemple pour écrire des applications autonomes, il n'est pas moins sécurisé que d'autres langages et plus sécurisé que C ou C ++ en raison de l'absence de débordement de tampon etc.

Mais Java est régulièrement utilisé comme plugin dans le navigateur Web, par exemple similaire à Flash. Parce que dans ce cas, l'utilisateur exécute du code non approuvé sans l'avoir explicitement installé, l'idée est de faire exécuter le code dans un bac à sable limité, où il ne devrait pas être en mesure d'agir d'une manière ou d'une autre contre le système ou l'utilisateur (par exemple, lire les fichiers locaux et envoyer sur le site Web, scannez le réseau local, etc.). Et c'est là que Java a échoué ces dernières années, par exemple de nouveaux bogues surgissaient parfois quotidiennement, ce qui permettait de s'échapper du bac à sable.

De plus, des bogues dans l'interpréteur de code d'octet ou dans les bibliothèques natives entraînaient des débordements de tampon et pouvaient compromettre le système, mais à cet égard Flash est généralement considérée comme pire.

Et comme pour les autres langages étant meilleurs: ceux-ci ne peuvent généralement même pas fonctionner en tant que code non approuvé dans un bac à sable (l'exception est JavaScript et peut-être Flash), ils seraient donc encore pires car il n'y a pas de moyen inhérent pour limiter leur interaction avec le système.

Les vulnérabilités de sécurité signalées ne concernent pas Java (le langage de programmation), qui, en vertu de la sécurité de la mémoire de la JVM, est en fait plus robuste que les langages tels que C ou C ++, où la mémoire tampon déborde et les surcharges de mémoire tampon restent une menace, et peuvent entraîner des dégâts comme Heartbleed.

Au lieu de cela, les vulnérabilités signalées se trouvent dans le Java Sandbox, qui tente d'appliquer un modèle de privilèges qui permet une exécution sûre du code non approuvé, et est surtout utilisé pour permettre l'exécution automatique des applets Java dans un navigateur. Ce bac à sable est criblé de trous. De plus, Oracle ne publie des correctifs (les «mises à jour critiques de correctifs») que 4 fois par an. Inutile de dire que les fournisseurs de navigateurs ne sont pas satisfaits de cela. Firefox, par exemple, requiert l'autorisation de l'utilisateur pour lancer une applet Java depuis Firefox 26.

La raison pour laquelle les rapports de presse ne font pas cette distinction est qu'Oracle utilise le "Java" marque déposée à la fois pour le langage de programmation et le plugin de navigateur qui exécute les applets. En fait, si un utilisateur ordinaire rencontre la marque Java, il fait probablement référence à cette dernière.

Il est quelque peu spéculatif pourquoi exactement le Sandbox reste vulnérable. Si vous me demandez, une des raisons est que la même API est utilisée avec et sans Sandbox, et la plupart du code Java s'exécute sans Sandbox (car le code est approuvé). En conséquence, il est tout à fait possible pour un développeur d'oublier cette fonctionnalité obscure lors de la modification de l'API Java ou de son implémentation, en exposant accidentellement des éléments qui devraient être protégés (pour illustrer à quel point cela est facile, voyez les longues Consignes de codage sécurisé pour Java SE). Une autre raison, mais liée, est la taille de l'API Java ( 5800 classes, et près de 50 000 méthodes, pour Java SE 6).

Il y a des tonnes d'autres langages de programmation qui n'ont pas ce problème, il doit donc y avoir une meilleure façon de faire tout ce que Java fait mal.

C'est un joli haute revendication, où avez-vous eu cette impression? Il y a "des tonnes d'autres langages de programmation" qui n'ont pas été soumis au même rythme que Java, ou qui sont utilisés de manière omniprésente.

En principe, la raison pour laquelle il y a tant de correctifs de sécurité est conçu pour être sécurisé, avec un certain nombre de fonctionnalités axées sur la sécurité que d'autres langages n'ont pas.

L'environnement du langage Java

1.2.2 Robuste et sécurisé

La technologie Java est conçue pour fonctionner dans des environnements distribués, ce qui signifie que la sécurité est d'une importance primordiale. Avec des fonctionnalités de sécurité intégrées au langage et au système d'exécution, la technologie Java vous permet de créer des applications qui ne peuvent pas être envahies de l'extérieur. Dans l'environnement réseau, les applications écrites dans le langage de programmation Java sont protégées contre les intrusions par du code non autorisé tentant de pénétrer dans les coulisses et de créer des virus ou d'envahir les systèmes de fichiers.

Si vous n'incluez pas «soyez en sécurité» dans les spécifications de votre langage de programmation, vous aurez rarement à publier des correctifs de sécurité. Si, au contraire, c'est l'un de vos objectifs déclarés, vous aurez du mal à ne pas le faire .

By itself, Java has great assets for security, namely its inherent resistance to buffer overflows and memory management errors:

• All array accesses are checked with regards to allocated array length. Buffer overflows are thus reliably trapped, and trigger an exception, which is better (this turns remote code execution vulnerabilities into mere denial-of-service).

• Memory allocation is managed through a garbage collector, which prevents use-after-free and double-free errors. Also, the GC allows for an easier handling of character strings (strings are immutable in Java), which removes most occasions for buffer overflow bugs.

• Strict typing is enforced; code cannot access data bytes for what they are not. This again prevents vulnerabilities (bugs where data types are transgressed will be reported at compilation or, at worst, as a runtime ClassCastException).

This makes Java much stronger than many programming languages (in particular the infernal couple C/C++) when it comes to security.

However, the Java designers tried to leverage this enhanced security to make something hard, i.e. applets. The problem is attack surface: since the applet is potentially hostile code, everything it does must be controlled. But the hostile code must be able to use the "standard Java classes" if it is to do anything, so "control points" must be enforced on every single standard Java class. The attack surface thus consists of hundreds of classes containing thousands of methods, and all of them must enforce adequate checks.

The Java designers sinned by ambition: the difficulty of implementing thousands of checks without botching any was much higher than what they imagined. All the "Java bugs" come from this fact.

We can compare Java with Javascript here; for instance, Java allows access to files on disks, but this right must not be granted to applets, except if the applet asked for it and the user agrees (which entails the whole applet signing business). Javascript, less ambitious, simply lacks any file access method: access controls on a function cannot be implemented improperly if the function does not actually exist !

To sum up: Java is fine and secure. Java applets imply a huge attack surface whose security is very hard to ensure. For stand-alone applications and servers, though, using Java is a good idea if you want security (this equally applies to C#).

De nos jours, trouver davantage de vulnérabilités n'implique peut-être pas le degré d'insécurité du logiciel. Le problème est de savoir comment l'équipe d'intervention en matière de sécurité de chaque éditeur de logiciels y réagit et à quelle vitesse les correctifs sont publiés.

Il suffit de vérifier à quelle vitesse Firefox et Chrome sont corrigés. De nombreuses vulnérabilités y sont également trouvées et résolues.

Si je me souviens bien, Oracle a un programme appelé Critical Patch Updates (CPU) qui donne de nombreux correctifs chaque trimestre. Ils publient également des correctifs sans CPU s'il existe une vulnérabilité zero-day. Mais le problème est le temps pris par Oracle pour publier un correctif.

Peur surestimée .. Java lui-même va bien; les problèmes se produisent avec les applets Java à l'ancienne fonctionnant dans les navigateurs Web, mais je doute que quiconque crée réellement des applets plus - la plupart des maisons de développement ont utilisé Flash ou HTML4 / 5 pour les interfaces Web frontales pendant au moins 10 ans. p>

De nos jours, Java est principalement utilisé pour le backend JEE, les clients d'interface graphique frontale (JFX / AWT / SWING), les applications de console et les applications mobiles - il n'y a donc aucun problème.

La réponse est assez évidente. Pouvez-vous supprimer vos fichiers informatiques en utilisant JavaScript, HTML ou Flash? Non, vous ne pouvez pas.

Et Java. Pouvez-vous supprimer tous vos fichiers, effacer complètement votre disque dur à l'aide d'une applet Java (hébergée sur un site Web)? La réponse est oui, si vous acceptez d'exécuter l'applet. Contrairement à toute autre langue de navigateur Web.

Java a la capacité de faire des choses comme exécuter des programmes sur votre ordinateur (exécutables) et a également la capacité d'écrire, de mettre à jour ou de supprimer des fichiers sur votre disque dur.

De plus, Java les applets ne sont pas détectables par les antivirus: dans la plupart des cas, vous ne saurez même pas que cela a gâché votre ordinateur. Certains scanners peuvent détecter que quelque chose tente de supprimer des fichiers dans un répertoire restreint: l'un que je connais est Kaspersky, mais la plupart des gens ont cette fonctionnalité désactivée par défaut.

Les applets Java peuvent faire des choses telles que mettre à jour les fichiers Windows, comme HAL.dll , ce qui empêchera votre ordinateur de démarrer. Il peut tout faire sur votre ordinateur lorsque vous acceptez d'exécuter l'applet.

Dans certains cas, peu importe si une applet Java est signée ou non signée - elle téléchargera toujours des fichiers sur votre ordinateur.

Sans oublier que Java est très populaire.

Il y en a un autre qui gagne en popularité, appelé Unity Engine (similaire à Flash): il a le même problèmes de sécurité comme Java et pourrait faire n'importe quoi à votre ordinateur. La seule différence entre Unity Engine et Java est qu'Unity s'exécute sans vous demander si vous souhaitez l'exécuter ou non. Donc, si quelqu'un a installé Unity Player et exécute un jeu contenant un virus, cela endommagera votre ordinateur.

Moins populaire, mais potentiellement extrêmement dangereux, est VBScript. Je crois que Microsoft Internet Explorer est le seul qui prend en charge cela actuellement, mais je peux me tromper. Il a les mêmes capacités que Java.