Directives de codage sécurisé et meilleures pratiques pour les développeurs

secure coding guidelines

Ce didacticiel explique le codage sécurisé, comment éviter les vulnérabilités liées à la sécurité et fournit des directives de codage et une liste de contrôle pour les pratiques de codage sécurisé:

Pour que la sécurité soit intégrée au logiciel et pour mettre en œuvre les directives et les meilleures pratiques de codage sécurisé, toute l'organisation ainsi que l'équipe identifiée pour travailler sur le développement d'application prévu doivent prendre en compte certains aspects.

Ici, nous discuterons des aspects qui aident à développer un logiciel sécurisé.

C'est aussi simple que cela si un développeur ne sait pas ce que l'on entend par «Sécurité du logiciel» et comment un hacker peut pirater son logiciel, en prendre le contrôle et essayer de l'exploiter, alors il est tout simplement impossible de coder un logiciel sécurisé. Ainsi, le développeur doit d'abord comprendre la signification du codage sécurisé.

Ce que vous apprendrez:

• Qu'est-ce que le codage sécurisé?
  • Atténuation des risques
  • Raisons de la mise en œuvre inadéquate de la sécurité
• Directives de codage sécurisé
  • Sélection de la langue pour le codage sécurisé
  • Règles et recommandations de codage sécurisé
  • Erreurs de programmation courantes à éviter
• Liste de contrôle des pratiques de code sécurisé
  • Résumé tabulaire de la liste de contrôle du codage sécurisé
• Conclusion
  • lecture recommandée

Qu'est-ce que le codage sécurisé?

Le codage sécurisé consiste à concevoir et développer des logiciels en éviter les faiblesses qui conduisent à des vulnérabilités liées à la sécurité en adhérant aux normes de sécurité spécifiées et aux meilleures pratiques du secteur.

La toute première question qui se pose dans l’esprit de chacun est «Quel est le niveau de sécurité requis pour notre logiciel» ou Quand pouvons-nous dire que notre logiciel est sécurisé? et Quelles sont ces normes de sécurité ?

Les fraudes et les menaces de sécurité augmentent de jour en jour et nous voyons de nouvelles variétés et méthodes de piratage, même dans les logiciels dits les plus sécurisés.

Récemment, nous avons entendu le programme Aaadhar de UIDAI se faire trafiquer pour des données personnelles. Par conséquent, il est vraiment difficile de savoir quel niveau de sécurité est requis pour le logiciel et quelles sont les normes de sécurité à moins de comprendre les menaces impliquées dans le logiciel et de les hiérarchiser en fonction des risques pour l'entreprise.

Il peut être difficile de fournir une protection de sécurité à 100% au logiciel, mais si l’équipe du programme analyse le Risques et valeurs qui sont impliqués dans leur logiciel, c'est-à-dire des menaces potentielles et si l'équipe peut prendre soin d'atténuer ces risques, alors ce serait bien du point de sécurité de l'application.

Ainsi, la toute première tâche de l'équipe est d'identifier et d'analyser les risques et les titres impliqués dans leur application, de comprendre les options d'atténuation possibles et d'adopter la meilleure option en conséquence.

Ainsi, une fois identifiées, les dix principales vulnérabilités classifient presque toutes les attaques auxquelles un programme est susceptible de faire face. Cela aidera à donner un sens aux menaces et à donner la priorité aux efforts de sécurité et de développement davantage vers la prévention que vers l'atténuation.

Par exemple. Alors que nous prévoyons de développer une application liée à la santé, qui gère et stocke les données de santé de l'individu et ses informations personnelles, le principal risque de sécurité pour l'application est de voler les données de santé personnelles.

Atténuation des risques

Pour atténuer le risque,

• La mise en œuvre de la sécurité pour l'accès aux données par un utilisateur non autorisé doit être gérée avec une authentification et une autorisation appropriées (implémentations de politique de mot de passe fort, authentification à 2 facteurs).
• Il faut veiller à ce qu'il n'y ait pas de fuite de données lors de la transmission de données d'une source à une autre source en mettant en œuvre des canaux sécurisés (HTTPS) de transmission de données et en mettant en œuvre le cryptage des données pendant le transit.
• La falsification ou le vol de données au repos est également une autre possibilité. Par conséquent, le stockage des données de santé personnelles (à l'aide du cryptage) est très essentiel.

Avant de passer à la «norme de codage sécurisé», il est toujours préférable que l’ensemble de l’équipe du programme dispose d’un «Session de sensibilisation à la sécurité» et discuter et réfléchir à,

• L'exigence de sécurité pour leur produit spécifique.
• Avantages possibles qu'un pirate informatique aurait en piratant son système.
• Moyens possibles de compromettre la sécurité de leur application.
• Des pratiques de sécurité communes suivies dans un secteur et un domaine similaires.
• Compréhension des problèmes de sécurité typiques de leurs programmes respectifs.

Cela aide également l'équipe à mieux gérer, si elle peut comprendre Sources des vulnérabilités auxquels leur logiciel peut faire face et les raisons pour lesquelles le logiciel est construit avec Faible / inadéquat Sécurité .

Raisons de la mise en œuvre inadéquate de la sécurité

En général, voici quelques raisons de l'implémentation de la sécurité inadéquate dans l'application.

• La priorité est donnée pour la version fonctionnelle aux aspects de sécurité.
• Ignorance ou absence de conscience de la sécurité des logiciels et des pirates informatiques.
• Pas assez de clarté sur le programme ou sur la conception du logiciel lui-même.
• La complexité du programme.
• Pas assez de données, d'informations sur le système en direct sur lequel il sera déployé.
• Aucune considération de la sécurité dans les phases SDLC.
• Connaissance et compréhension insuffisantes des spécificités de la langue utilisée dans le logiciel.
• Pas assez de connaissances pour l'équipe et les développeurs sur les directives de codage de sécurité.

Nous savons que tous les développeurs et testeurs ne sont pas conscients de la sécurité d'une application et peuvent ne pas avoir une compréhension approfondie des vulnérabilités et des exploits de sécurité, en particulier de l'application sur laquelle ils travailleraient. En général, ils connaissent, «Comment coder fonctionnellement» mais tous ne savent pas «coder en toute sécurité».

Par conséquent, l'aspect très important pour l'organisation d'adopter des pratiques de codage sécurisé dans son logiciel est d'abord «Former les gens» . Il est donc très important de former leur équipe sur les aspects de codage sécurisé, les meilleures pratiques de codage de sécurité et l'utilisation correcte des outils.

Le principe de conception le plus important de la sécurité logicielle est de «Mettre en œuvre la sécurité par conception et par défaut» .

Directives de codage sécurisé

Pour assurer la sécurité, il est très essentiel d'avoir un «Norme de codage sécurisé» identifié pour un programme au tout début du développement de l'application, ce qui aide l'équipe à prendre en charge les valeurs par défaut sécurisées du logiciel et à le protéger des attaques.

Il est essentiel de s'assurer que toute l'équipe est Adhérer à cette norme , quel que soit le langage de codage et les outils qu'ils utilisent dans le programme.

Vous trouverez ci-dessous quelques exemples qui doivent être implémentés par défaut dans la conception de code sécurisé:

• L'accès doit être limité aux utilisateurs authentifiés uniquement et l'authentification doit être mise en œuvre à chaque couche.
• Les canaux de communication doivent être chiffrés pour protéger les jetons d'authentification.
• Toutes les clés, mots de passe et certificats doivent être correctement stockés et protégés.
• Le cryptage des fichiers, le cryptage de la base de données et le cryptage des éléments de données doivent être mis en œuvre.

Sélection de la langue pour le codage sécurisé

Le choix de la langue pour le codage peut ne pas dépendre d'un codage sécurisé. Il n'y a rien de spécifique en tant que langage sécurisé ou non pour le codage pour créer un logiciel sécurisé.

quel est le meilleur Linux ou Windows

Il s'agit simplement de la façon dont nous utilisons un langage de programmation pour créer le logiciel et de la connaissance approfondie que possède le développeur du langage de codage dans la mise en œuvre des aspects de sécurité.

Cependant, il est précisé que, bien que Les normes de codage sécurisé sont indépendantes de la sélection de la langue, les meilleures pratiques de code sécurisé dépendent de la langue, de la plate-forme et de l'implémentation .

Ainsi, pour avoir un code sécurisé, il est essentiel que le développeur ait une connaissance approfondie du langage utilisé dans le programme, afin que les meilleures pratiques de sécurité puissent être mises en œuvre facilement.

Exemple:

• La probabilité de vulnérabilité de dépassement de mémoire tampon diffère d'un langage à l'autre, mais C, C ++ et Assembly sont considérés comme les plus vulnérables en raison de leurs capacités de gestion de mémoire obsolètes. Plusieurs fonctions standard de la bibliothèque C, telles que strcpy () et memcpy (), sont vulnérables aux attaques par débordement de tampon. Une utilisation incorrecte de ces fonctions, en copiant un tampon source trop volumineux pour tenir dans le tampon de destination, entraîne un débordement de tampon.
• Le problème courant dans les applications Web Java est les éventuelles fuites de ressources qui peuvent se produire en raison de ressources système ouvertes, telles qu'un fichier, un socket et des connexions à la base de données.

Le prochain aspect de la sécurité concerne le outils à utiliser dans le programme d'application pour optimiser la sécurité, en utilisant des outils tels que Environnements de développement intégrés seront plus bénéfiques car ils fournissent beaucoup de Alertes aux utilisateurs et attirer l'attention sur ces alertes pour essayer d'améliorer la qualité du logiciel.

• L'intégration de bibliothèques / plugins commerciaux ou Open-source tels que Eclipse, Spring Tool Suite, RAD avec IDE aide les développeurs à écrire du code sécurisé en détectant et identifiant le code potentiellement vulnérable et fournit des alertes sur les résultats liés à l'exécution de fichiers malveillants, aux fuites d'informations et mauvaise gestion des erreurs.

Il est également essentiel d'utiliser le Analyseurs statiques et dynamiques pour améliorer les aspects de sécurité du logiciel. En règle générale, les analyseurs statiques sont optimisés pour des types d'erreurs spécifiques, ils finissent donc par trouver un grand nombre de faux positifs tout en identifiant des erreurs spécifiques. Parfois, il est possible qu'ils passent à côté des erreurs réelles.

Par conséquent, il est recommandé d'utiliser plusieurs analyseurs statiques pour obtenir une meilleure couverture des différents types d'erreurs et éviter un grand nombre de faux positifs. Parfois, il est également recommandé d'effectuer test manuel à éliminer les faux positifs .

Règles et recommandations de codage sécurisé

Il sera bon que le programme définisse un ensemble de «Règles et recommandations de codage sécurisé» auquel le code source peut être évalué pour la conformité afin que les testeurs puissent effectuer «Test de conformité de conformité» pour chacune de ces normes de codage sécurisé.

Par conséquent, le code de sécurité peut être certifié conforme ou non conforme en utilisant ces règles par rapport au référentiel défini.

Peu de règles mentionnées ci-dessous peuvent être utilisées pour vérifier les violations de sécurité:

• Les fichiers doivent être fermés lorsqu'ils ne sont plus nécessaires.
• Chaque fois qu'une structure franchit une frontière, les fuites d'informations doivent être évitées.
• Les objets doivent être déclarés avec des durées de stockage appropriées.

Ainsi, des cas de test pour vérifier ces règles doivent être conçus et exécutés pour vérifier la conformité de conformité. Il est également identifié que la plupart des vulnérabilités sont causées par des erreurs de programmation courantes typiques.

Par conséquent, le développeur doit comprendre «Méthode de codage non sécurisée» , tout en apprenant les meilleures pratiques du codage sécurisé. Il est idéal de rassembler les erreurs de programmation les plus courantes qui contribuent aux vulnérabilités de sécurité de leur application afin qu'elles puissent être prises en charge lors du codage.

Ces erreurs de programmation typiques sont principalement dues aux dépassements de tampon, aux scripts intersites et aux défauts d'injection.

Certaines des vulnérabilités de programmation typiques incluent:

• Injection SQL (Neutralisation incorrecte des éléments spéciaux utilisés dans une commande SQL).
• Débordement d'entier.
• Buffer overflow (Buffer Copy sans vérification de la taille de l'entrée).
• Chaîne de format non contrôlée.
• Authentification et autorisation manquantes (autorisation incorrecte).
• Exposition de données sensibles.
• Traitement incorrect des erreurs.

Certaines de ces erreurs peuvent entraîner une panne du système, un accès imprévu au système et la perte de contrôle du logiciel par les pirates.

Erreurs de programmation courantes à éviter

Quelques erreurs de programmation courantes à éviter sont répertoriées ci-dessous:

• Neutralisation incorrecte d’éléments spéciaux utilisés dans une commande SQL («injection SQL»).
• Copie de la mémoire tampon sans vérification de la taille de l’entrée («débordement de la mémoire tampon classique»).
• Authentification manquante pour la fonction critique.
• Autorisation manquante ou incorrecte.
• Utilisation d'informations d'identification codées en dur.
• Chiffrement manquant des données sensibles.
• Téléchargement illimité de fichiers de type dangereux.
• Dépendance à des entrées non approuvées dans une décision de sécurité.
• Exécution avec des privilèges inutiles.
• Falsification de demandes intersites (CSRF).
• Téléchargement de code sans contrôle d'intégrité.
• Calcul incorrect de la taille du tampon.
• Restriction incorrecte des tentatives d'authentification excessives.
• Redirection d'URL vers un site non approuvé («Redirection ouverte»).
• Chaîne de format non contrôlée.
• Utilisation d'un hachage à sens unique sans sel.

Liste de contrôle des pratiques de code sécurisé

Dernier point, mais non le moindre, après avoir examiné tous les points ci-dessus des aspects du développement de logiciel sécurisé, les développeurs doivent suivre les Liste de contrôle établie pour les pratiques de code sécurisé pour s'assurer que les choses ne sont pas manquées. Vous en trouverez ci-dessous quelques-uns, mais non une liste exhaustive.

Validation d'entrée:

• Ne faites pas confiance à l'entrée, envisagez une validation d'entrée centralisée.
• Ne vous fiez pas à la validation côté client.
• Soyez prudent avec les problèmes de canonisation.
• Contraignez, rejetez et nettoyez les entrées. Validez pour le type, la longueur, le format et la plage.

Authentification:

• Partitionner le site par zone anonyme, identifiée et authentifiée.
• Utilisez des mots de passe forts.
• Prise en charge des périodes d'expiration des mots de passe et de la désactivation des comptes.
• Ne stockez pas les informations d'identification (utilisez des hachages unidirectionnels avec du sel).
• Cryptez les canaux de communication pour protéger les jetons d'authentification.
• Transmettez les cookies d'authentification par formulaire uniquement sur les connexions HTTPS.

Autorisation:

• Utilisez les comptes les moins privilégiés.
• Tenez compte de la granularité des autorisations.
• Appliquer la séparation des privilèges.
• Restreignez l'accès des utilisateurs aux ressources au niveau du système.
• Utilisez le protocole OAuth 2.0 pour l'authentification et l'autorisation.
• Effectuez la validation de l'API.
• Liste blanche des méthodes autorisées.
• Protégez les actions privilégiées et les collections de ressources sensibles.
• Protégez-vous contre la falsification de ressources intersites (CSRF).

Gestion de session:

• Créez un identifiant de session sur le serveur.
• Terminez la session avec la déconnexion.
• Générez une nouvelle session lors de la ré-authentification.
• Définissez l'attribut «sécurisé» pour les cookies transmis via TLS.

Cryptographie:

• Utilisez la cryptographie lors de «données en transit, données en stockage, données en mouvement, intégrité des messages».
• Ne développez pas le vôtre. Utilisez les fonctionnalités éprouvées de la plate-forme.
• Gardez les données non chiffrées à proximité de l'algorithme.
• Utilisez le bon algorithme et la bonne taille de clé.
• Évitez la gestion des clés (utilisez DPAPI).
• Cycle vos clés périodiquement.
• Stockez les clés dans un endroit restreint.

Journalisation et audit:

logiciel de gestion informatique et outils de surveillance

• Identifiez les comportements malveillants.
• Sachez à quoi ressemble un bon trafic.
• Audit et journalisation de l'activité à travers tous les niveaux d'application.
• Accès sécurisé aux fichiers journaux.
• Sauvegardez et analysez régulièrement les fichiers journaux.

Encodage de sortie:

• Effectuez la validation des entrées (XML, JSON….).
• Utilisez une requête paramétrée.
• Effectuez la «validation du schéma».
• Effectuer l'encodage (XML, JSON ..).
• Envoyer des en-têtes de sécurité.

Référence: ' Liste de contrôle des pratiques de codage sécurisé OWASP (En bref, la liste de contrôle SCP) '

Résumé tabulaire de la liste de contrôle du codage sécurisé

Le tableau ci-dessous résume les «Choses à retenir pour Secure Code» d'une application.

Conclusion

Nous espérons que ce didacticiel sera votre meilleur guide pour garantir la sécurité des logiciels.

Les directives de codage pour le développement de logiciels sécurisés ont été répertoriées ici en termes simples avec des exemples pour faciliter votre compréhension du concept.

Bonne lecture!!

lecture recommandée

• Test de sécurité (un guide complet)
• Top 30 des MEILLEURES entreprises de cybersécurité en 2021 (petites et petites entreprises)
• Bases de la programmation informatique pour les débutants »wiki utile Tutoriel de codage
• Top 15 des meilleurs éditeurs de code gratuits pour une expérience de codage parfaite
• Didacticiel de test d'injection SQL (exemple et prévention des attaques par injection SQL)
• Les développeurs ne sont pas de bons testeurs. Ce que tu dis?
• Format de l'examen de la Fondation ISTQB et directives pour résoudre des articles
• Directives de test de sécurité des applications mobiles