Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>

Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>
Aller à la section
Les normes de codage sécurisé sont des règles et des directives qui aident à maintenir des normes de codage efficaces pour éviter les vulnérabilités de sécurité. Ici, nous expliquons comment la mise en œuvre de SAST peut vous aider à appliquer et à maintenir des normes de codage sécurisées.
Aller à la section
Aller à la section
Lorsque les équipes de développement utilisent des normes de codage sécurisées pour développer des logiciels, il en résulte moins de bogues de sécurité et, au final, une meilleure qualité, ce qui conduit à une expérience plus robuste pour les développeurs et les utilisateurs. Dans ce blog, nous passons en revue les bases des normes de codage sécurisé, les meilleures pratiques, ainsi que comment et quand les utiliser.
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 constitue la première ligne de défense qui protège contre les acteurs malveillants exploitant les logiciels et é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 consacrer plus de temps à innover, au lieu de consacrer du temps à la correction de bogues.
Les pratiques de codage sécurisées garantissent que des contrôles de sécurité sont mis en œuvre dans le code afin de réduire les problèmes de sécurité pouvant résulter d'un code mal développé. Il est impératif que les organisations formalisent des pratiques de codage sécurisées afin d'établir un ensemble minimum de normes de sécurité logicielle sur la manière dont les développeurs doivent écrire le code, que l'organisation peut appliquer et valider avec une analyse statique automatisée ou 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. |
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é.
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.
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.
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.
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.
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é.
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.
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.
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.
NIST 800-63b définit trois niveaux de garantie d'authentification, alias, AAL ou niveaux d'assurance d'authentification.
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 :
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 :
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é.
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.
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 :
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 :
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.
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.
Procédez comme suit pour éviter les données non protégées :
Les développeurs peuvent envisager les mesures de contrôle d'accès suivantes pendant la phase de conception :
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.
Software les développeurs utilisent SAST (tests de sécurité des applications statiques) pour exécuter des tests automatisés pour 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 en « 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 est implémenté.
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 exploitent l'IA/ML pour une analyse incrémentielle, qui analyse uniquement le code modifié 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 créer un code de qualité, fiable et sécurisé pendant l'intégration et avant la livraison finale. Il répond au concept d'assurance logicielle continue, dans lequel les pratiques d'assurance logicielle sont automatisées dans les activités de développement pour garantir un déploiement et une livraison rapides des logiciels.
Des tests Java plus intelligents grâce à l'IA pour plus de rapidité, de couverture et de conformité