IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langages de programmation Discussion :

Le Pouvoir des Dix - Règles pour développer du code critique sécurisé [Tutoriel]


Sujet :

Langages de programmation

  1. #1
    Community Manager

    Avatar de Malick
    Homme Profil pro
    Community Manager
    Inscrit en
    Juillet 2012
    Messages
    9 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Community Manager
    Secteur : Conseil

    Informations forums :
    Inscription : Juillet 2012
    Messages : 9 121
    Points : 83 910
    Points
    83 910
    Billets dans le blog
    15
    Par défaut Le Pouvoir des Dix - Règles pour développer du code critique sécurisé
    Chers membres du club,

    J'ai le plaisir de vous présenter cet article de Gerard J. Holzmann traduit en français par watchinofoye :


    Les règles suivantes peuvent présenter des avantages, surtout si leur faible nombre signifie que les développeurs les respecteront effectivement. Chaque règle est suivie d’une brève justification de son utilisation.
    Bonne lecture

    Retrouvez Les meilleurs cours et tutoriels pour apprendre la programmation.
    Vous avez envie de contribuer au sein du Club Developpez.com ? Contactez-nous maintenant !
    Vous êtes passionné, vous souhaitez partager vos connaissances en informatique, vous souhaitez faire partie de la rédaction.
    Il suffit de vous porter volontaire et de nous faire part de vos envies de contributions :
    Rédaction d'articles/cours/tutoriels, Traduction, Contribution dans la FAQ, Rédaction de news, interviews et témoignages, Organisation de défis, de débats et de sondages, Relecture technique, Modération, Correction orthographique, etc.
    Vous avez d'autres propositions de contributions à nous faire ? Vous souhaitez en savoir davantage ? N'hésitez pas à nous approcher.

  2. #2
    Membre actif

    Homme Profil pro
    Lycéen
    Inscrit en
    Décembre 2003
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Lycéen
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 44
    Points : 297
    Points
    297
    Par défaut Les 10 commandements
    Tous ces conseils sont intéressants, sauf peut-être, à un degré moindre, le dernier : les messages d'avertissement sont parfois éloignés des considérations de sécurité et chercher à les faire "disparaître" tous peut s'avérer difficile dans certains environnements (et constitue donc une perte de temps inutile).

    L'auteur passe néanmoins sous silence d'autres problématiques :
    - l'utilisation de la récursivité, qui est à manier avec précaution (ou avec une allocation de pile adaptée) sous peine de plantage intempestif
    - le traitement systématique des erreurs
    - la protection des éléments secrets dans le code (mots de passe, clés, paramètres d'initialisation divers, etc.) et le nettoyage des conteneurs de ces éléments dans les environnements partagés ou réutilisables
    - le choix des algorithmes cryptographiques (quand il y en a)
    - le choix des composants tiers (bibliothèques)
    - et sans doute d'autres, au cas par cas

  3. #3
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Bonjour,

    Tout est discutable, et les règles citées ici le sont autant que le reste. Ce ne sont pas forcément les premières à mettre en avant.

    1. Récursivité
    À condition de ne pas considérer la programmation fonctionnelle, c'est vrai. Mais il ne faut pas oublier que la programmation fonctionnelle est vérifiable, avec récursivité.

    2. Boucles avec une limite supérieure fixe
    Soit je suis bête (ce qui n'est pas exclu), soit je ne comprends pas comment faire avec une liste chaînée (ce n'est qu'un exemple). Si j'ai une liste chaînée, c'est justement que je ne connais pas le nombre d'éléments, donc à quoi est-ce que ça sert d'ajouter un compteur arbitraire au nombre d'éléments de ma liste ?
    Si je connais le nombre d'éléments max, je peux utiliser d'autres structures que la liste chaînée.
    Si je ne connais pas le nombre d'éléments max, la valeur arbitraire sera probablement débile, et donc absolument inutile. Et elle va à l'encontre de la règle 1 qui est, en gros, de faire du code simple et lisible.

    3. pas d'allocation dynamique de mémoire après initialisation
    Ben si, mais il faut savoir ce que l'on fait.
    Si je ne peux pas utiliser l'allocation dynamique après l'init, à quoi ça sert d'utiliser une allocation dynamique ???
    Le principe de l'allocation dynamique, c'est que je ne connais pas à l'avance la taille dont j'ai besoin. Donc je l'alloue au moment où j'en ai besoin, et je la réalloue lorsque nécessaire (si si, c'est l'intérêt principal). Si je connais la taille à la compilation, ou à l'initialisation, j'utilise une allocation statique.
    Ah, et bien sûr j'utilise des outils de profiling pour m'assurer que je n'ai pas de fuites ni d'écrasements ni autres bugs.
    Et enfin, utiliser un tableau n'empêche aucunement d'accéder à une case non allouée (qui n'a jamais déclaré un tableau de N éléments (accessibles de tab[0] à tab[N-1]) puis a accédé à tab[N] ?)

    4. Fonctions trop longues
    Non. Du moins pas dans un gros programme. Ceux sur lesquels je travaille ont environ 1 million de lignes de code (c'est peut-être trop, mais c'est un autre débat). Si je respecte les 60 lignes par fonctions, ça me fait un peu plus de 16 600 fonctions, ce qui est beaucoup trop.
    Je veux bien limiter la taille des fonctions, mais aussi leur nombre, ça ne sert à rien de couper une fonction juste pour qu'elle "ne soit pas trop longue" (déjà vu).
    Ce qui est vrai, c'est qu'une fonction devrait être minimale, et ne concerner que ce qu'elle doit faire, et ne pas chercher à faire le travail de la fonction d'en face.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  4. #4
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    C'est marrant, les règles 1, 2, et 3 reviennent à écrire en COBOL. Qui interdit ce que l'article proscrit. La règle 9 presque, les pointeurs en cobol, c'est une horreur que personne n'utilise (ou presque).
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  5. #5
    Membre actif

    Homme Profil pro
    Lycéen
    Inscrit en
    Décembre 2003
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Lycéen
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 44
    Points : 297
    Points
    297
    Par défaut En complément
    Un article sur la gestion de projet de développement : https://medium.com/better-programmin...t-1b1657b4d04d

    En résumé :
    1. Estimates Are Always Wrong
    2. The Bigger the Project, the Less Accurate Your Estimate Will Be
    3. Focus and Concentration Are Our Most Valuable — and Scarcest — Commodities
    4. Hofstadter’s Law Is the Truth (“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”)
    5. You Can’t Speed Up Software Development, You Can Only Limit How Much You Slow It Down
    6. You Can Only Run in the Red for Very, Very Brief Periods
    7. Brain Time Is More Important Than Butt Time
    8. Hardware Is Cheaper Than Developer Time — Way Cheaper
    9. You Can’t Measure Software Developer Productivity
    10. If You Haven’t Read “PeopleWare”, Then You Aren’t Really a Software Development Manager
    11. Quality Is a Perception — Not a Bug Count

  6. #6
    Membre actif

    Homme Profil pro
    Lycéen
    Inscrit en
    Décembre 2003
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Lycéen
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 44
    Points : 297
    Points
    297
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    ...
    Bonjour,

    3. pas d'allocation dynamique de mémoire après initialisation


    L'auteur doit venir de la sûreté de fonctionnement (aéronautique, transports au similaire) et dans de type de logiciel "critique", l'allocation dynamique n'est pas la bienvenue. On alloue les variables statiquement (on fait du C à la sauce ADA). Ça explique aussi les boucles finies (pas de while(true) ou d'autres astuces de ce genre).

    c.

  7. #7
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 653
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 653
    Points : 3 773
    Points
    3 773
    Par défaut
    En quoi les Xxx::with_capacity() de Rust sont-ils compatibles ou incompatibles avec ces règles, notamment les règles n°3 et n°2 (plus pour les boucles que pour les malloc, certes) ? Ces méthodes là ont pour but d'éviter autant que faire se peut les réallocations au delà d'une limite fixe passée à la méthode. Du coup j'ai toujours trouvé sécurisé et optimisé dans mes codes Rust d'initialiser des collections avec des trucs du genre Xxx::with_capacity(limite_superieure_prevue). Est-ce une bonne pratique, surtout à la vue de ces règles ?
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

Discussions similaires

  1. Liste des EDI existants pour développer en DELPHI
    Par LeonCosnyd dans le forum EDI
    Réponses: 7
    Dernier message: 22/01/2016, 16h33
  2. Réponses: 5
    Dernier message: 08/03/2012, 14h40
  3. Réponses: 0
    Dernier message: 07/02/2010, 14h18

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo