Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

java est il plus secure

10 réponses
Avatar
sylv
Bonjour

une petite réflexion sur les applications Java ou J2EE. Imaginons par
exemple un serveur tcp (ex serveur de chat) j'aurais tendance à dire
qu'il est plus sécure (d'un point de vue buffer/heap overflow) qu'un
serveur tcp écrit en C et ceci pour 2 raisons :
- Il n'y a pas de notion de bufferoverflow dans java lui même, la JVM
géré la mémoire à sa sauce et évite cela
- Il est toujours possible d'avoir un buffer overflow dans le JVM mais
concrêtement le pb sont plutôt sur le classloader à qui l'on fait
charger un .class tordu. Au niveau buffer overflow à distance, la couche
IP est gérée par l'OS, il me semble quasi impossible de faire un buffer
overflow à distance.

Donc au final,de mon point de vue : à compétence de développeur égale il
est moins risqué d'un point de vue sécurité d'écrire un service réseau
en java qu'en C.

Ceci n'est que mon avis, n'hésitez pas à apporter vos arguments ...

10 réponses

Avatar
Fabien LE LEZ
On 07 Sep 2006 14:42:35 GMT, sylv :

Donc au final,de mon point de vue : à compétence de développeur égale il
est moins risqué d'un point de vue sécurité d'écrire un service réseau
en java qu'en C.


Oui. Mais comparer Java et C n'a pas vraiment de sens.
Il faudrait comparer les deux groupes de langages :

- les langages où le programmeur doit gérer lui-même la mémoire (C,
assembleur -- y'en a d'autres) ?
- les langages où le programmeur peut, ou doit, laisser le langage
gérer la mémoire (C++, Java, PHP, etc.)

Mais note que ce "détail" ne suffit pas. Il rend juste les choses plus
faciles pour le programmeur.

Le manque de vérification des données fournies en entrée est la source
d'autres failles de sécurité. La plus classique en PHP est une faille
de la fonction mail() qui, couplée à l'absence d'une vérification
stricte des données, permet à un spammeur d'envoyer des emails avec le
contenu et les destinataires qu'il veut.

Avatar
Thomas Samson
sylv writes:

Bonjour

une petite réflexion sur les applications Java ou J2EE. Imaginons par
exemple un serveur tcp (ex serveur de chat) j'aurais tendance à dire
qu'il est plus sécure (d'un point de vue buffer/heap overflow) qu'un
serveur tcp écrit en C et ceci pour 2 raisons :
- Il n'y a pas de notion de bufferoverflow dans java lui même, la JVM
géré la mémoire à sa sauce et évite cela
- Il est toujours possible d'avoir un buffer overflow dans le JVM mais
concrêtement le pb sont plutôt sur le classloader à qui l'on fait
charger un .class tordu. Au niveau buffer overflow à distance, la
couche IP est gérée par l'OS, il me semble quasi impossible de faire
un buffer overflow à distance.

Donc au final,de mon point de vue : à compétence de développeur égale
il est moins risqué d'un point de vue sécurité d'écrire un service
réseau en java qu'en C.

Ceci n'est que mon avis, n'hésitez pas à apporter vos arguments ...


Je suis globalement d'accord. Java permet d'utiliser la memoire de facon
bien plus 'sure' qu'avec du C.

Et meme a competences inegales ... il est toujours possible de faire une
faute de manipulation de buffer en C (meme le meilleur programmeur
risque de laisser passer une faute), en java, c'est pratiquement
impossible (je suppose que c'est faisable par des moyens complexes,
notamment si le code utilise une lib externe...)

Apres, j'ai tendance a ne pas apprecier particulierement java, mais sur
ce point, java est 'mieux' que le C ou certains autres langages laissant
le controle de l'allocation/utilisation memoire au programmeur.

(je prefere python, et les memes arguments peuvent s'y appliquer)

--
Thomas Samson
A programming language is low level when its programs require attention
to the irrelevant.

Avatar
Nicob
On Fri, 08 Sep 2006 10:54:38 +0000, Fabien LE LEZ wrote:

Le manque de vérification des données fournies en entrée est la source
d'autres failles de sécurité. La plus classique en PHP est une faille
de la fonction mail() qui, couplée à l'absence d'une vérification
stricte des données, permet à un spammeur d'envoyer des emails avec le
contenu et les destinataires qu'il veut.


Mode capillo-traction activé : à mon avis, l'erreur de validation la
plus classique en PHP est liée à include() et ses dérivés. Mais là, je
conçois que je chipote. En tout cas, l'impact de ce type de failles est
souvent supérieur à la simple utilisation d'une machine comme relais de
spam (ie. compromisison locale).


Nicob

Avatar
Fabien LE LEZ
On 09 Sep 2006 08:51:41 GMT, Nicob :

à mon avis, l'erreur de validation la
plus classique en PHP est liée à include() et ses dérivés


Faire un "include" brutal d'un fichier passé en paramètre (dans
l'URL), tu veux dire ?
Wow... on en est encore là ? :-/

Avatar
Nicob
On Mon, 11 Sep 2006 14:15:29 +0000, Fabien LE LEZ wrote:

Faire un "include" brutal d'un fichier passé en paramètre (dans
l'URL), tu veux dire ? Wow... on en est encore là ? :-/


Des fois, c'est plus fin qu'un bon vieux include() dont on contrôle la
partie gauche, mais c'est vulnérable quand même. Extrait d'un code
audité récemment, où $this->file est contrôlé par l'attaquant et où on
a un accès local au serveur :

if( !isset($this->file)
|| !strpos( $this->file, 'foobar.php')
|| strpos( $this->file, '..') )
{
$this->file = 'default.php';
}
require FULL_PATH . "/" . $this->file;


Nicob

Avatar
FAb
Fabien LE LEZ writes:

On 07 Sep 2006 14:42:35 GMT, sylv :

Donc au final,de mon point de vue : à compétence de développeur égale il
est moins risqué d'un point de vue sécurité d'écrire un service réseau
en java qu'en C.


Oui. Mais comparer Java et C n'a pas vraiment de sens.
Il faudrait comparer les deux groupes de langages :

- les langages où le programmeur doit gérer lui-même la mémoire (C,
assembleur -- y'en a d'autres) ?
- les langages où le programmeur peut, ou doit, laisser le langage
gérer la mémoire (C++, Java, PHP, etc.)


Gnii ? y a un garbage collector en C++ maintenant ?
Y a plus les new et delete à la malloc et free ??

FAb


Avatar
Fabien LE LEZ
On 12 Sep 2006 13:25:18 GMT, FAb :

Gnii ? y a un garbage collector en C++ maintenant ?


Tu peux en mettre un, si tu en as l'utilité.
Un GC n'est pas forcément utile en C++, car beaucoup d'objets ont une
sémantique de valeur (contrairement à ce qui se passe en Java).

Y a plus les new et delete à la malloc et free ??


Ça existe, mais c'est peu utilisé directement.

Et surtout, pour les chaînes de caractères, on utilise std::string, et
pas les char* comme en C. Du coup, un "buffer overflow" est
impossible.


Si tu écris

void f()
{
std::string ligne;
std::getline (cin, ligne);
ligne= "La ligne lue est '" + ligne + "'.";
//...
}

l'objet "ligne" est détruit automatiquement à la sortie de la fonction
(i.e. pas besoin de GC), et tu es sûr que la cuisine interne de
std::string allouera un espace mémoire suffisant pour éviter le buffer
overflow.


En résumé, un programmeur qui utilise ses mains et pas ses pieds peut
laisser passer un buffer overflow en assembleur ou en C, mais pas en
C++, PHP, bash, etc.

Avatar
Brice Arnould
sylv wrote:
- Il n'y a pas de notion de bufferoverflow dans java lui même, la JVM
géré la mémoire à sa sauce et évite cela
[...]
Donc au final,de mon point de vue : à compétence de développeur égale il
est moins risqué d'un point de vue sécurité d'écrire un service réseau
en java qu'en C.


Les compilateurs et systèmes d'exploitations modernes incluent des
protections contre les débordements de tampon, même en C .
http://en.wikipedia.org/wiki/Stack-smashing_protection
Ainsi que des techniques très efficaces contre l'injection de code :
http://en.wikipedia.org/wiki/PaX
et pour compliquer l'écriture des shellcodes :
http://en.wikipedia.org/wiki/Address_space_layout_randomization

Je n'ai pas vraiment compté, parmis les failles découvertes ces dernières
années, quelle part ces techniques permettent de masquer. Mais elles ont
l'air convaincantes.

Restent les dénis de services. Et là le C a l'avantage de ses
performances...

Ceci n'est que mon avis, n'hésitez pas à apporter vos arguments ...
Voilà qui est fait ! ^_^


Bonne continuation,

Brice

Avatar
lap
On 12 Sep 2006 13:25:18 GMT, FAb :


Gnii ? y a un garbage collector en C++ maintenant ?



Tu peux en mettre un, si tu en as l'utilité.
Un GC n'est pas forcément utile en C++, car beaucoup d'objets ont une
sémantique de valeur (contrairement à ce qui se passe en Java).



Dans ce cas on passe son temps à recopier des objets (sauf quand on les
passe en "const CLASS &"), et ça rame, mais c'est une autre histoire. :)

LaP


Avatar
Fabien LE LEZ
On 16 Sep 2006 03:41:42 GMT, lap :

et ça rame


En pratique, on s'en sort plutôt pas mal. Et si ça rame, on lance le
profiler pour pouvoir optimiser les quelques lignes de code qui posent
effectivement problème.

En pratique, le C++ apporte la rapidité de C et la fiabilité des
autres langages, mais il a un inconvénient de taille : pour
l'apprendre, il faut vraiment passer beaucoup de temps.