Discussion :

[fugi]

Et j'aurais presque envie de rajouter, "et quel est le pire ?"

Voila je m'intéroge à ce sujet et je voulais sondez un peu vos avis. J'aimerais savoir quelle est la meilleure solution (et pourquoi ?) pour produire du code sécurisé, et notament régler les problèmes de buffer overflow, saisie de données, fichiers temporaire, race course, ...

Merci de votre collaboration

Edit : si vous avez des sources d'information, je prend volontier

[Luc Hermitte]

C++ (à condition de l'utiliser comme du C++ et pas comme du C)
Ada peut-etre aussi. Eiffel. Peut-être D aussi.

Ils permettent d'ignorer les problèmes de buffer overflow (cf ma parenthèse précédente) vu qu'ils disposent de types chaines et vecteurs qui sont autres choses que des buffers à taille limité lors de l'exécution ; ils permettent de programmer par contrat là où c'est nécessaire et que cela a un sens, sans passer par des outils externes comme en Java.

J'ai l'impression que tout le problème (dans les cas de buffer overflow) est surtout de connaitre le sous-ensemble de ces langages qui permet d'éviter ces problèmes. Malheureusement, ce sous-ensemble n'est pas toujours enseigné/connu (juste pour garder un code simple (C), ou par méconnaissance (C++)).

[GnuVince]

Pour éviter les buffer overflows, à peu près n'importe quel langage avec un bon garbage collector fait l'affaire. Comme la plupart des languages en ont un (Python, Ruby, C#, Java, Perl, Lisp, Scheme, ML, Haskell, etc.), le choix du langage est large.

Pour la saisie de données, un langage avec des exceptions rend la tâches très facile:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
try:
    n = int(raw_input('Entrez un entier: '))
except ValueError:   # Si la fonction int() échoue, elle renvoie une exception
    print "Vous n'avez pas entrez un entier"

Pour les fichiers temporaires et les race conditions, je ne suis pas sûr s'il y a des features dans un langage qui permettent de les éviter

[Luc Hermitte]

Pas besoin de ramasse miettes pour éviter simplement les buffer overflow. J'ai même envie dedire qu'il n'y a pas trop de rapport. C'est plus une question de savoir si le langage dispose d'abstractions qui sont sûres à ce regard et que les programmeurs ajoutent des données dans ces abstractions de buffers (ou autres -> chaines) en utilisant les méthodes dédiées à cela au lieu de faire des accès directs non contrôlés.

[MarcG]

Plus que le langage la programmation "securisé" est surtout un problème d'ecriture de code correcte et contrôlé. c'est beaucoup plus long, donc plus couteux, c'est plus astraignant, nécéssite une meilleur connaissance du langage utilisé, mais aussi de l'OS et du contexte, bref beaucoup de "bonne" raison à un manque certain de "securité" dans les programmes quelqu'ils soient.
Mettre un porte blindé (même exellente) sur un mur en torchie n'as qu'une utilité toute relative