Normes de codage sécurisé : appliquer des pratiques de codage sécurisé avec SAST

Lorsque les équipes de développement utilisent normes de codage sécurisé pour développer des logiciels, le résultat est moins de bogues de sécurité et finalement une meilleure qualité qui conduit à une expérience plus robuste pour les développeurs et les utilisateurs. Dans ce blog, nous examinons les bases des normes de codage sécurisé, les meilleures pratiques et comment et quand les utiliser.

Comment fonctionne le codage sécurisé

Le codage sécurisé signifie que les développeurs appliquent un ensemble de normes de codage ou de directives de codage sécurisé qu'ils implémentent dans le code source pour prévenir et atténuer les vulnérabilités courantes qui conduisent souvent à des cyberattaques. La mise en œuvre de pratiques de codage sécurisées dans le code est la première ligne de défense qui protège contre les mauvais acteurs exploitant les logiciels et qui élimine les surfaces d'attaque que les adversaires ciblent souvent avec des logiciels malveillants. Lorsque les organisations adhèrent religieusement aux meilleures pratiques de codage sécurisé, elles peuvent réduire le coût de maintenance des logiciels et les développeurs peuvent passer plus de temps à innover, au lieu de consacrer du temps à des corrections de bogues.

Les pratiques de codage sécurisé garantissent que des contrôles de sécurité sont mis en œuvre dans le code pour réduire les problèmes de sécurité qui peuvent se manifester à la suite d'un code mal développé. Il est impératif que les organisations formalisent des pratiques de codage sécurisées pour établir un ensemble minimum de normes de sécurité logicielle sur la façon dont les développeurs doivent écrire du code, que l'organisation peut appliquer et valider avec des outils automatisés. analyse statique or test de sécurité des applications statiques (SAST) outils. Ces outils utilisent des règles et des vérificateurs qui analysent le code source pour les violations de syntaxe, les variables non définies, la qualité du code, les violations de codage et de sécurité et les erreurs de programmation (pour n'en nommer que quelques-unes).

Les outils d'analyse statique de Parasoft utilisent des normes de codage sécurisées telles que CERT normes de codage, OWASP Top 10 (partie des directives de codage sécurisé OWASP), Énumération des faiblesses communes MITRE (CWE), Et DISA Sécurité et développement des applications STIGS dans les règles et les dames comme indiqué dans le tableau 1.

Nom de la norme de codage	Entretenu par	Résumé de l'objectif
CERT (Équipe d'intervention d'urgence informatique)	Centre de coordination CERT	Lignes directrices pour aider les développeurs à éviter les erreurs lors du codage et de la mise en œuvre, et également à détecter les erreurs de faible niveau dans la conception.
Top dix OWASP	Fondation OWASP (Open Web Application Security Project)	Les développeurs d'applications Web et de logiciels utilisent ces normes pour identifier et remédier aux risques de haute sécurité dans les applications Web.
CWE (Énumération des faiblesses communes)	Communauté développée et maintenue.	Il s'agit d'un système de catégories qui aide les développeurs à identifier les vulnérabilités et les faiblesses des logiciels, et les aide à comprendre les défauts des logiciels. Les développeurs utilisent également le système pour développer des outils permettant de corriger et de prévenir les défauts.
DISA Sécurité et développement des applications STIGS	Defense Information Systems Agency (DISA) et division du Département de la défense des États-Unis.	Aide les gestionnaires, les concepteurs, les développeurs et les administrateurs système à développer et à maintenir des contrôles de sécurité dans les applications et le développement d'applications.

De mauvaises pratiques de codage entraînent des problèmes de sécurité

Les développeurs doivent être conscients des conséquences de leurs activités de codage et de refactorisation dans la création et l'exposition de vulnérabilités dans les logiciels. Voici quelques problèmes courants qui peuvent mal se passer lorsque les développeurs ne suivent pas et n'utilisent pas des pratiques de codage sécurisées. Nous suivons les meilleures pratiques pour atténuer et résoudre ces problèmes de sécurité.

Problème : injection SQL

Cela se produit lorsqu'un attaquant injecte de manière non sécurisée une entrée dans une requête SQL, plusieurs fois via une chaîne de chaînes de base. L'injection SQL est un risque de sécurité très dangereux pour les applications car elle est relativement facile à utiliser à mauvais escient et peut conduire l'exploiteur à modifier, effacer ou voler toute la base de données. Les attaquants peuvent également utiliser l'application pour exécuter des commandes dangereuses sur le système d'exploitation qui héberge la base de données, ce qui lui donne accès à votre réseau.

Problème : Authentification et gestion de session interrompues

Les développeurs implémentent souvent de manière incorrecte les tâches d'application associées à la gestion et à l'authentification des sessions. Cela permet aux attaquants de compromettre les clés, les mots de passe et les jetons de session et de permettre aux acteurs malveillants d'utiliser les identités des utilisateurs à leur avantage.

Problème : Contrôle d'accès interrompu

Les systèmes n'appliquent souvent pas correctement ce que les utilisateurs authentifiés sont autorisés à faire. Les mauvais acteurs peuvent utiliser ces failles pour accéder aux fonctionnalités et aux données, par exemple, aux comptes d'utilisateurs et aux fichiers, pour modifier des données ou pour changer les autorisations d'accès.

Problème : Script intersites (XSS)

Cela se produit chaque fois que l'application autorise des données suspectes sur une nouvelle page Web sans authentification appropriée. XSS permet aux pirates d'implémenter des scripts dans le navigateur de la cible. Les scripts peuvent vandaliser des sites Web ou envoyer des utilisateurs vers des sites malveillants et réquisitionner des sessions utilisateur.

Meilleures pratiques de code de sécurité

L'augmentation des cyberattaques attribuée à des logiciels mal développés rend essentiel que les développeurs adhèrent à des pratiques de codage sécurisées. Lorsqu'ils le font, cela améliore la productivité et aide à accélérer la livraison des logiciels, car il y a moins de problèmes de sécurité à résoudre. Cela augmente la probabilité que le build soit réussi. Lorsqu'une version est réussie, cela signifie que toutes les gravités critiques et élevées ont été résolues et qu'il n'y a aucun risque significatif pour l'organisation. Par exemple, une organisation pourrait définir des seuils (en termes de gravité) et/ou identifier des problèmes spécifiques qui ne sont pas négociables, et s'ils sont identifiés, ils briseront le build jusqu'à ce que les problèmes soient résolus.

Une façon de s'assurer qu'une version sera réussie consiste à appliquer des pratiques de codage sécurisées et une validation de la conformité avec une analyse statique dans le cadre de tests automatisés. Voici les bonnes pratiques de sécurité que les développeurs peuvent suivre dans le cadre d'un codage sécurisé.

Pour atténuer l'injection SQL

Utiliser la configuration sécurisée

Souvent, les systèmes de gestion de bases de données n'incluent pas de composant sécurisé par défaut. Les développeurs doivent s'assurer que les contrôles de sécurité de la plate-forme d'hébergement et du système de gestion de base de données (SGBD) fonctionnent et sont correctement configurés. Des guides, des normes et des références existent pour les SGBD les plus populaires. L'aide-mémoire de base de données fournit des conseils rapides pour développer une configuration sécurisée.

Utiliser l'authentification sécurisée

Authentifiez correctement tous les accès à une base de données. Utilisez une méthode sécurisée pour authentifier le SGBD. Authentifiez-vous uniquement sur un canal sécurisé et sécurisez correctement les informations d'identification avant de les rendre disponibles. Reportez-vous à la feuille de triche de la base de données pour plus d'informations.

Utiliser la communication sécurisée

Presque tous les SGBD prennent en charge une gamme de méthodes de communication, telles que des API, des services, etc., à la fois non sécurisées (non cryptées ou non authentifiées) et sécurisées (cryptées ou authentifiées). Il est sage pour les développeurs d'utiliser uniquement les choix de communication sécurisée disponibles avec Protect Data Everywhere (voir ci-dessous). La feuille de triche de base de données fournit une assistance rapide pour fournir une communication sécurisée.

Pour atténuer l'authentification cassée et la gestion de session

NIST 800-63b définit trois niveaux de garantie d'authentification, alias, AAL ou niveaux d'assurance d'authentification.

Niveau 1 : Mots de passe

Le niveau 1 est destiné aux applications à faible risque qui ne contiennent aucune PII (informations personnelles identifiables). Il ne nécessite qu'un identifiant à un seul facteur, généralement un mot de passe.

Les meilleures pratiques incluent :

• Utiliser des mots de passe avec pas moins de 8 caractères, si nous utilisons MFA (authentification multi-facteurs) ; 10 caractères si nous n'utilisons pas MFA.
• Utilisation de tous les caractères ASCII imprimables, en plus du caractère espace.
• Promouvoir l'utilisation de phrases secrètes et de mots de passe longs.
• Suppression des exigences de complexité (les développeurs ont constaté qu'elles ne sont pas très efficaces).
• Éviter d'utiliser des mots de passe courants, en particulier ceux qui ont déjà été compromis.
• Récupération de mot de passe qui implémente les éléments MFA.
• Stockage sécurisé des mots de passe à l'aide de contrôles cryptographiques.

Niveau 2 : Authentification multifacteur

Ce niveau est destiné aux applications les plus à risque contenant des informations personnelles, que les utilisateurs ont fournies en ligne. AAL niveau 2 nécessite MFA, y compris la mise en œuvre QTP (quick test professionnel). Le MFA certifie qu'un utilisateur est bien celui qu'il prétend être et exige que la personne s'identifie avec au moins deux de ces combinaisons :

• Un code PIN ou un mot de passe
• Un téléphone ou un jeton
• Biométrie, comme une empreinte digitale ou une image faciale

Niveau 3 : Authentification basée sur la cryptographie

Lorsqu'un système intégré peut entraîner des pertes financières substantielles, un préjudice personnel, des violations pénales ou civiles, ou un préjudice considérable à l'intérêt public, une authentification de niveau 3 est nécessaire. Les développeurs utilisent généralement des modules cryptographiques pour atteindre ce niveau d'assurance élevé.

Gestion de session

Une application peut suivre l'authentification pendant une période de temps limitée. Cela permet à l'utilisateur de continuer à utiliser l'application sans avoir besoin de se ré-authentifier à chaque demande. Le suivi est connu sous le nom de gestion de session.

Génération et expiration de session

Le système suit l'état de l'utilisateur pendant une session. Le serveur stocke la session et attache un identifiant de session à l'utilisateur afin que les informations utilisateur puissent identifier la session qui contient les données correctes pour l'utilisateur. Le client conserve simplement l'identifiant, qui protège également les informations confidentielles de session côté serveur du client.

Les contrôles de sécurité à prendre en compte lors de la mise en œuvre ou de la création de systèmes de gestion de session incluent :

• Assurez-vous que l'ID de session est unique, long et aléatoire.
• S'assurer que l'application génère une nouvelle session, ou au moins fait pivoter l'ID de session lors de l'authentification et de la réauthentification.
• S'assurer que l'application implémente un délai d'inactivité après un temps d'inactivité, en plus de définir une durée de vie maximale pour chaque session. Après cela, l'utilisateur doit se ré-authentifier.

Cookies

Les applications utilisent couramment des cookies de navigateur pour stocker les identifiants de session d'application Web lorsque les systèmes implémentent des méthodes de gestion de session. Quelques défenses sont :

• Seul un petit nombre de domaines devrait pouvoir accéder aux cookies. L'application doit baliser leurs chemins afin que les balises expirent à la fin, ou peu de temps après, la session perde de sa vitalité.
• Définir les balises « sécurisées » pour s'assurer que le système ne transfère que sur un canal sécurisé.
• Définir l'indicateur HttpOnly pour empêcher JavaScript d'accéder au cookie.
• Ajout de caractéristiques « même site » aux cookies, ce qui empêche certains navigateurs actuels d'envoyer des cookies ayant des demandes intersites. Cela protège contre les attaques de type fuite d'informations et la contrefaçon à la demande entre sites.

Tokens

Pour certains types d'authentification, les sessions côté serveur peuvent être restrictives. Les « services sans état » permettent au système de gérer les données de session pour améliorer les performances. Le résultat est que la charge de vérifier et de stocker les sessions des utilisateurs sur le serveur est moindre. Une application « sans état » crée un jeton d'accès temporaire, que le système utilise pour authentifier la demande d'un client moins les informations d'identification de l'utilisateur après l'authentification initiale.

Jetons Web JSON (JWT)

Il s'agit d'un standard ouvert. Il s'agit d'une méthode autonome et compacte de transfert d'informations en toute sécurité entre les entités en tant qu'élément JSON (JavaScript Object Notation). Le système peut vérifier les informations car elles sont signées numériquement. Lors de l'authentification, le système crée un jeton JWT et le serveur le vérifie avant tout traitement.

Le serveur n'enregistre pas toujours le JWT. Le système maintient l'intégrité du token avec une signature numérique afin qu'un serveur ultérieur puisse confirmer que le JWT reste valide et que personne ne l'a corrompu depuis que le système a créé le token.

Cette méthode est portable et sans état, ce qui signifie que les technologies serveur et client peuvent être différentes mais néanmoins elles peuvent interagir.

Pour atténuer les données non protégées

Procédez comme suit pour éviter les données non protégées :

• Classez les informations dans l'application selon le niveau de sensibilité et mappez chaque catégorie de données à la règle de protection appropriée.
• Chiffrez les données en transit. Pour la protection des données d'applications Web sur un réseau, les développeurs utilisent généralement TLS (sécurité de la couche de transport) correctement configuré.
• Chiffrez les données au repos. Évitez de stocker des informations sensibles, si possible. Si vous devez le stocker, cependant, assurez-vous de le protéger cryptographiquement.
• Stockage local sécurisé dans les appareils mobiles. Les gens volent ou perdent souvent des appareils mobiles, ce qui rend les informations qu'ils contiennent vulnérables aux fuites. Les propriétaires doivent stocker un minimum de données sensibles sur leurs appareils et les stocker dans le répertoire de stockage de données spécifié.
• Gérer les cycles de vie des clés secrètes. Les développeurs utilisent des clés secrètes dans les applications pour des fonctions confidentielles ; par exemple, pour protéger les cartes de crédit et pour signer des JWT. Gérez correctement les clés en :
  • S'assurer que toutes les clés secrètes sont protégées contre une utilisation non autorisée.
  • Utilisation de clés indépendantes si plusieurs clés sont nécessaires.
  • Stocker correctement les clés dans les coffres secrets.
  • Construire des applications pour changer les clés et les algorithmes si nécessaire.
  • Construire des fonctionnalités pour s'adapter à la rotation des clés.
• Gérer les secrets d'application. Les applications possèdent de nombreux « secrets » dont elles ont besoin pour fonctionner en toute sécurité, tels que des mots de passe, des certificats et des clés de chiffrement. Si quelqu'un compromettait ces secrets, cela pourrait entraîner une panne complète du système. Pour gérer les secrets d'application :
  • Ne les transmettez pas à travers des variables d'environnement et ne les stockez pas dans des fichiers de configuration ou du code.
  • Conservez-les en toute sécurité dans des coffres secrets.

Pour atténuer le contrôle d'accès brisé

Les développeurs peuvent envisager les mesures de contrôle d'accès suivantes pendant la phase de conception :

• Incluez le contrôle d'accès dès le départ. Aussi, autorisez la personnalisation.
• Obliger toutes les demandes à passer les contrôles de contrôle d'accès.
• Refuser par défaut. Si le programme n'autorise pas spécifiquement la demande, refusez-la.
• Mettre en œuvre le «principe du moindre privilège». Assurez-vous que tous les programmes, processus et utilisateurs ont le moins d'accès possible.
• Ne codez pas les rôles en dur. Trop de programmes utilisent par défaut le contrôle d'accès basé sur les rôles, ce qui est fragile et n'autorise pas les règles de contrôle d'accès multi-locataires et horizontales et spécifiques aux données. Il est également difficile à auditer.
• Enregistrez chaque échec de contrôle d'accès. Ceux-ci peuvent indiquer que les exploiteurs recherchent des faiblesses dans l'application.

Atténuation des scripts intersites (XSS)

L'échappement et l'encodage sont des méthodes de défense qui aident à arrêter les piratages par injection. L'échappement signifie que le codeur ajoute un caractère spécifique avant la chaîne pour éviter qu'elle ne soit mal interprétée. Par exemple, vous pouvez ajouter une barre oblique inverse ( \ ) avant un guillemet double ( " ) afin que le système l'interprète comme du texte au lieu d'un signal pour fermer une chaîne. Le codage, également appelé codage de sortie, signifie que le développeur modifie les caractères spéciaux sous une forme différente mais égale, ce qui les rend non dangereux dans l'interpréteur. Par exemple, remplacer < par la chaîne < lorsque vous écrivez en HTML.

D'autres méthodes de protection par injection incluent le codage de sortie contextuel, que les développeurs de codage implémentent lorsqu'ils créent une interface utilisateur ; neutraliser des métacaractères spécifiques lorsque vous ajoutez une entrée à une commande d'un système d'exploitation ; Encodage Unicode, une méthode de stockage de caractères utilisant plusieurs octets ; et la canonisation, c'est-à-dire lorsque les systèmes transforment les données en une forme standard ou simple.

Comment les tests statiques de sécurité des applications (SAST) aident les développeurs à améliorer leurs pratiques de codage

Les développeurs de logiciels utilisent SAST (test de sécurité des applications statiques) pour exécuter des tests automatisés afin d'analyser le code source sans exécuter ni exécuter le code. L'objectif est d'identifier les violations de codage et les faiblesses qui pourraient exposer des vulnérabilités logicielles. SAST est considéré comme une approche de test « boîte blanche » car il a accès au code source qui documente la conception, le cadre et la manière dont le système et/ou l'application sont mis en œuvre.

SAST utilise les détails documentés dans le code source, ainsi que sa structure de code pour garantir le respect des normes et directives de codage sécurisé. SAST utilise des règles et des vérificateurs pour appliquer et valider la conformité, ainsi que pour identifier les violations de codage dans les pratiques de codage des développeurs. Les équipes de développement peuvent utiliser différentes normes et directives de codage sécurisé telles que les normes de codage sécurisé CERT et CWE au début du processus de développement pour garantir que le logiciel répond à certaines exigences de qualité et de sécurité.

Il convient de noter que les organisations de développement de logiciels performantes et matures utilisent ces normes et pratiques pour adapter les politiques de sécurité et la gouvernance aux équipes de développement. De nombreuses organisations ajoutent des conseils supplémentaires qu'elles peuvent utiliser pour la formation et la sensibilisation des développeurs. OWASP Top 10 et les sept pernicieux Royaumes jouer un rôle clé dans la sensibilisation aux choses qui pourraient mal tourner dans les pratiques de codage.

Étant donné que SAST ne nécessite pas l'exécution du logiciel pour effectuer une analyse, les développeurs peuvent l'implémenter de manière transparente dans leurs flux de travail de développement existants pour analyser le code en temps réel, signalant immédiatement toute violation de codage déclenchée par les règles de codage et les vérificateurs. Le résultat est de trouver des problèmes critiques de qualité et de sécurité dans le flux de travail du développeur où le coût de résolution et de résolution des problèmes de sécurité est le moins cher. Cela se traduit par des logiciels de meilleure qualité avec moins de problèmes de sécurité ou de vulnérabilités, permettant aux organisations de gagner en confiance pour accélérer le déploiement et la livraison des logiciels.

Bien que l'intégration de SAST dans les workflows des développeurs aide les développeurs à trier leurs violations de codage, SAST peut également s'intégrer de manière transparente dans un pipeline automatisé pour analyser les validations de code avant que le logiciel ne soit mis en production. Chaque commit peut déclencher automatiquement une analyse à partir d'un outil SAST.

Les outils Parasoft SAST tirent parti de l'IA/ML pour l'analyse incrémentielle, qui analyse uniquement le code qui a changé dans le cadre de cette validation. Cela permet une utilisation plus efficace de SAST et fournit aux organisations de développement une vue historique des analyses. L'intégration SAST dans le processus CI/CD est un élément essentiel de la création d'un code de qualité, fiable et sécurisé pendant l'intégration et avant la livraison finale. Il satisfait au concept d'assurance logicielle continue, où les pratiques d'assurance logicielle sont automatisées dans les activités de développement pour assurer le déploiement et la livraison des logiciels rapidement.