Webinaire en vedette : MISRA C++ 2023 : tout ce que vous devez savoir | Voir le séminaire

Comment apprendre OWASP et démarrer la sécurité de vos applications

Portrait d'Arthur Hicken, évangéliste chez Parasoft
4 octobre 2023
11 min lire

La sécurisation des applications dans votre organisation ne peut pas être gagnée uniquement avec des outils de sécurité. Voici une couverture détaillée des raisons pour lesquelles la connaissance de l'Open Web Application Security Project (OWASP) peut vous aider à atténuer les vulnérabilités de votre application.

Nous continuons de voir d'importantes violations de données affectant des organisations de toutes tailles. Alors que les problèmes de cybersécurité se poursuivent et même augmentent en fréquence et en gravité, nous nous demandons : « Sommes-nous les prochains ? et "Que puis-je faire à ce sujet?" C'est là que OWASP entre en jeu.

Qu'est-ce que le Top 10 de l'OWASP et pourquoi devriez-vous l'apprendre ?

Le plus connu pour le OWASP Top 10, OWASP est l'Open Web Application Security Project, une communauté ouverte avec des informations gratuites et une formation sur la sécurité des applications. Le Top 10 de l'OWASP est une liste des risques de sécurité dangereux courants pour les applications Web, mise à jour périodiquement pour rester à jour. Si vous n'avez pas fait grand-chose en matière de sécurité des applications, ou si ce que vous avez fait est ad hoc, le Top 10 de l'OWASP est un excellent point de départ.

Comprendre le rôle de l'OWASP dans la sécurité des applications Web

OWASP, l'organisation, fournit des ressources, des directives et des outils pour aider les développeurs d'applications Web à identifier, atténuer et prévenir les vulnérabilités de sécurité. L'OWASP Top Ten est une ressource clé que l'organisation publie depuis 2003. L'intention est d'amener la communauté des développeurs à se concentrer sur les principaux problèmes de sécurité et à comprendre leur impact.

L’importance d’apprendre l’OWASP pour faire face aux risques de sécurité

La compréhension et la mise en œuvre du Top Ten de l'OWASP et d'autres recommandations de l'OWASP améliorent la sécurité des applications Web car elles aident à éliminer les risques de sécurité les plus courants et les plus critiques. Connaître les causes profondes de ces dix principales vulnérabilités aide les développeurs à prioriser leurs efforts et à se concentrer sur les risques les plus élevés. À mesure qu’une organisation mûrit et incarne ces pratiques, ses applications Web sont plus résilientes aux attaques, elles réduisent le risque de violations de données, de pertes financières et d’atteinte à la réputation.

Top 10 des vulnérabilités OWASP : ce que vous devez savoir

Le Top 10 OWASP comprend les vulnérabilités A1-A10 suivantes :

  1. A01: 2021-Contrôle d'accès cassé
  2. A02 : 2021 – Défaillances cryptographiques
  3. A03: 2021-Injection
  4. A04 : 2021 – Conception non sécurisée
  5. A05: Configuration incorrecte de la sécurité 2021
  6. A06 : 2021 – Composants vulnérables et obsolètes
  7. A07 : 2021-Échecs d’identification et d’authentification
  8. A08 : 2021-Intégrité des logiciels et des données
  9. A09 : 2021 -Journalisation et surveillance de la sécurité
  10. A10 : 2021-Demande côté serveur

OWASP fournit une documentation pour le Top 10 avec une page Web dédiée à chaque vulnérabilité. La page décrit chaque vulnérabilité et fournit un score de risque, qui est utilisé pour aider à prioriser et à trier les vulnérabilités possibles. Voici un exemple de la page Web A03:2021 Injection :

Capture d'écran montrant la page web OWASP Top 10:2021 dédiée à la description de la vulnérabilité A03:2021 - Injection.

La « Table des matières » en haut à droite fournit des conseils et vous aide à comprendre l'importance et le danger de chacune des vulnérabilités.

Vulnérabilités courantes dans les applications Web

Selon le Top Ten de l'OWASP, les vulnérabilités les plus courantes sont les contrôles d'accès brisés, les échecs cryptographiques et les failles d'injection.

Le contrôle d'accès maintient les utilisateurs dans les limites des autorisations prévues dans une application. Cependant, ces contrôles sont souvent mal mis en œuvre et facilement contournés. Avec des privilèges plus élevés que prévu, les attaquants peuvent accéder aux données privées ou perturber les opérations. Un contrôle d'accès approprié signifie implanter des contrôles efficaces avec une philosophie de refus par défaut. Les tests de sécurité doivent traiter de manière approfondie les problèmes possibles liés au contrôle d'accès.

Une autre vulnérabilité courante est le manque de cryptographie appropriée. Un manque faible ou total de sécurisation des données en mouvement ou au repos entraîne souvent une exposition des données. Lorsque la cryptographie est utilisée, elle utilise parfois un cryptage faible qui a déjà été « piraté » par des attaquants. La clé de la prévention consiste à assurer la sécurité des données lors de leur transmission grâce à des protocoles sécurisés et à un cryptage fort lors de leur stockage. Cela implique également une gestion appropriée des clés et la mise à jour des outils et méthodes de chiffrement si nécessaire.

Les attaques par injection manipulent les entrées pour exécuter des commandes non autorisées. Ces commandes peuvent être utilisées pour exposer des informations confidentielles. Par exemple, une attaque par injection SQL peut exposer les données des clients. Une mauvaise gestion des connexions et des sessions peut conduire à un accès non autorisé, conduisant souvent à une exposition des données, ce qui témoigne d'un problème général de mauvaise protection des informations confidentielles.

Comment l'OWASP aborde la conception non sécurisée

La lutte contre la conception non sécurisée est une nouvelle catégorie dans le Top Ten de l'OWASP pour 2021. Elle se distingue par le fait qu'elle se concentre sur les problèmes organisationnels liés à la sécurité des applications Web. Il est impossible de corriger une conception non sécurisée lors de la mise en œuvre. La meilleure approche consiste donc à introduire la sécurité dès le début du processus de développement et tout au long du cycle de vie.

La conception sécurisée est une approche qui comprend l'analyse des menaces, la gestion des risques, des pratiques de conception et de codage sécurisées, ainsi qu'une validation et une vérification continues de la sécurité. L'OWASP publie le Modèle de maturité de la Software Assurance (SAMM) pour aider les organisations à aligner et à faire évoluer leur cycle de vie de développement de logiciels sécurisés.

L'OWASP comprend de nombreuses recommandations pour passer à un processus de développement plus sécurisé. Les aspects clés incluent la modélisation des menaces, l'intégration des contrôles de sécurité et du langage dans les user stories et, bien sûr, l'établissement d'un cycle de vie de développement sécurisé avec des professionnels AppSec externes si nécessaire.

Détails du Top XNUMX de l'OWASP

Pour chacun des Top Ten, il existe une page dédiée à chaque catégorie de problèmes de sécurité des applications Web.

Facteurs

La section Facteurs affiche les données associées à la catégorie, telles que le nombre de CWE cartographiés, les taux d'incidence, le pourcentage de couverture, le nombre d'incidents.

Aperçu et description

Comme prévu, la présentation et la description fournissent des détails sur la catégorie de vulnérabilité. Ceci est étendu par rapport aux versions précédentes de la liste.

Comment empêcher

La section Comment prévenir est la plus intéressante à mon humble avis. Les tests de sécurité sont importants, mais la création d'un code sécurisé est la seule base solide pour une sécurité renforcée des applications. Cette section décrit diverses stratégies qui vous aideront à abandonner votre sécurité non seulement en testant plus tôt, mais en créant un meilleur code qui est fondamentalement moins vulnérable aux attaques. C’est la base d’une approche de sécurité dès la conception, requise par RGPD, Par exemple.

Exemples de scénarios d'attaque

La section Exemples de scénarios d'attaque montre comment un attaquant pourrait tirer parti de chaque vulnérabilité. Ces informations peuvent être utilisées pour aider à créer des tests ainsi qu'à informer l'équipe sur la façon dont les vulnérabilités logicielles affectent la sécurité des applications.

Bibliographie

Enfin, chaque élément du Top 10 comporte une section contenant plus d'informations sur chaque problème, les approches pour l'éviter et les approches pour le tester. Il contient également des liens qui vous mèneront à des problèmes connexes. Cela vous sera très utile lorsque vous travaillerez à améliorer continuellement la sécurité de vos logiciels.

Liste des CWE mappés

La dernière section répertorie tous les CWE mappé à la catégorie actuelle avec des liens vers les descriptions CWE de MITRE.

En lisant la documentation OWASP Top 10, vous constaterez peut-être que certains éléments sont évidents à partir de leur seul nom, tandis que d'autres nécessitent de creuser plus profondément pour être compris. Par exemple, A01 Broken Access Control est en fait un ensemble plus large de choses comme l'application de contrôles d'accès, les tests d'autorisation, la révocation d'accès, etc. À la base de cette faiblesse de sécurité se trouve le fait que les échecs d'accès peuvent conduire à une divulgation non autorisée d'informations, à une modification ou à la destruction de toutes les données ou à l'exécution d'une fonction en dehors des limites de l'utilisateur.

Pourquoi utiliser le Top 10 OWASP pour la sécurité des applications Web ?

Il y a des informations, de la formation et des conseils dans le Top 10 de l'OWASP. Vous pouvez en apprendre davantage sur les problèmes de sécurité courants ainsi que sur les stratégies pour détecter et même éviter complètement certains problèmes. Toutes ces informations sont disponibles gratuitement et sont constamment mises à jour et améliorées.

La conformité signifie également que nous devons savoir exactement quel élément spécifique de notre boîte à outils prend en charge quelle partie spécifique de la norme. Dans le cas de l'analyse statique, cela signifie savoir quels vérificateurs prennent en charge quels éléments de la norme et s'il existe ou non des éléments de la norme qui nécessitent plus qu'une analyse statique, comme une révision du code par les pairs ou une analyse de la composition logicielle.

Les avantages de la sécurité dès la conception

L'adoption de la sécurité dès la conception devrait être une priorité absolue pour le développement d'applications Web. La prévention grâce à une conception et un codage sécurisés et la mise en œuvre d’une norme de codage sécurisé font partie de la solution. En fait, la dernière liste OWASP Top Ten a ajouté la catégorie de conception non sécurisée pour résoudre ces problèmes précis. La sécurité ne peut pas être renforcée. Il doit être présent dans l'application dès le début.

Les outils SAST jouent un rôle important dans le déplacement de la sécurité vers la gauche, ce qui signifie appliquer des contrôles de sécurité plus tôt dans le cycle de vie du développement. Les outils SAST aident à prévenir les vulnérabilités de sécurité lorsqu'ils sont utilisés pour appliquer des pratiques et des normes de codage sécurisées. De plus, ces outils peuvent détecter les vulnérabilités existantes, que ce soit dans le code nouvellement développé ou existant.

Les avantages d’une conception sécurisée sont considérables, car les incidents de sécurité, notamment les violations de données, sont très coûteux. Les problèmes de sécurité rencontrés en production ou dans les produits déployés coûtent plusieurs fois plus cher à résoudre que ceux rencontrés lors du développement. Les violations de données publiques qui font l’actualité peuvent coûter des millions de dollars aux entreprises.
La conception sécurisée offre également des retours en termes de réputation et d’expérience client. Construire la sécurité dès le début est une bonne pratique.

Comment l'OWASP aide à identifier les risques de sécurité

Le Top Ten de l'OWASP, avant tout, fournit une sensibilisation et un langage commun aux vulnérabilités des applications Web les plus courantes et les plus risquées. Sous forme de liste, il fournit également une priorisation et une évaluation des risques que les développeurs doivent prendre en compte. Par exemple, les failles d’injection restent une vulnérabilité critique et devraient constituer une priorité lors de la conception de la sécurité, du codage et lors de l’utilisation d’outils d’analyse et de test d’intrusion.

Le Top Ten constitue également une bonne ressource pour former et aider les organisations à améliorer leur posture de sécurité. Secure by Design et DevSecOps s'appuient tous sur les informations et les conseils fournis par l'OWASP et des ressources telles que le Top Ten.

Commencer par la fin

Il est facile – et dangereusement courant – pour les organisations de développement de logiciels de commencer la sécurité en commençant par la fin, en utilisant des tests externes de fin de cycle sur l'ensemble du système, tels que les tests d'intrusion. Je pourrais appeler cela quelque chose comme DevTestOpsSec.

Ces tests sont parfaits pour démontrer que l'application/le système ne contient aucune des vulnérabilités énumérées dans OWASP, bien sûr. Mais ces tests en boîte noire ne constituent pas le moyen le plus efficace de produire du code plus sécurisé. Nous ne voulons pas nous fier aux tests de boîte noire pour sécuriser notre logiciel ou détecter des bogues, mais nous souhaitons plutôt l'utiliser pour prouver que le logiciel est sécurisé.

Ainsi, si les tests d’intrusion révèlent une vulnérabilité, nous devons nous demander pourquoi ? Et essayez de vous attaquer à la cause profonde du problème. C’est à ce moment-là que nous passons d’une mentalité de « test de sécurité » à une mentalité de « sécurité dès la conception ». Pour cela, vous trouverez des outils de tests de sécurité des applications statiques (SAST), tels que l'analyse de code statique, avec prise en charge d'OWASP.

Outils et stratégies pour satisfaire l’OWASP

Une petite chose à noter est que l'élément A06 du Top 10 OWASP est complètement différent des autres et ne se prête pas à SAST ou DAST car il s'agit de rechercher des vulnérabilités connues en open source, pas de trouver de nouvelles vulnérabilités.

Heureusement, OWASP a un outil gratuit pour cela appelé Vérification de la dépendance OWASP. Cet outil identifie les dépendances du projet et vérifie s'il existe des vulnérabilités connues et divulguées publiquement, et peut être utilisé pour analyser les applications et leurs bibliothèques dépendantes afin d'identifier les composants vulnérables connus.

Si vous utilisez Parasoft, nous avons en fait intégré OWASP Dependency Check dans notre système de reporting et l'avons intégré au tableau de bord OWASP Top 10. Cela facilite la gestion des problèmes liés à vos composants open source en analysant régulièrement votre CI, avec SAST, et en plaçant les résultats dans un tableau de bord unifié avec le reste de vos informations OWASP. Avec cette approche, au lieu d’être un processus orthogonal distinct, A9 est intégré au Top 10 comme il se doit.

DAST et SAST : outils pour satisfaire l'OWASP

Les outils de test de sécurité des applications prennent en charge les activités nécessaires pour prévenir les vulnérabilités répertoriées dans le Top Ten de l'OWASP. En tant que tel, l’utilisation d’une combinaison de ces outils constitue une bonne pratique pour les développeurs de logiciels.

Les outils SAST analysent le code « au repos » et peuvent être appliqués très tôt dans le cycle de vie du développement logiciel. Leur force réside dans la détection des faiblesses logicielles et des programmations non sécurisées au fur et à mesure de l’écriture du code. Ils sont également excellents pour appliquer des normes de codage sécurisées telles que SEI CERT. Les fournisseurs d'outils SAST proposent souvent des configurations pour le Top Ten de l'OWASP et documentent comment leur outil peut être utilisé pour traiter ces principales vulnérabilités.
Les outils DAST, quant à eux, sont utilisés lorsqu'une application est en cours d'exécution. Ils détectent les vulnérabilités au fur et à mesure qu’elles surviennent et avec une très grande précision. Les outils DAST sont utilisés pendant les tests pour détecter les bugs et les vulnérabilités qui pourraient passer inaperçus à partir des seuls résultats des tests.

Comment utiliser les directives de l'OWASP pour l'analyse de code sécurisé

Le Top Ten de l'OWASP aide à guider les tests de sécurité des applications et l'analyse du code en fournissant une liste hiérarchisée des risques de sécurité des applications Web les plus critiques. Les développeurs et les équipes de sécurité peuvent examiner leur code en gardant ces risques à l'esprit, en s'assurant qu'ils traitent et atténuent les vulnérabilités liées à ces dix principaux problèmes.

Outils et astuces d’analyse de code statique

La beauté de l’analyse statique est qu’il n’est pas nécessaire que l’ensemble de l’application ou du système soit terminé. Vous pouvez commencer à rechercher les problèmes de sécurité bien plus tôt dans le cycle pour décalage vers la gauche tests de sécurité. Si vous effectuez la sécurité tard ou vers la fin de votre développement (DevOpsSec), vous pouvez utiliser l'analyse statique pour pousser la sécurité plus tôt, avant même le début des tests, pendant que le code est en cours d'écriture (DevSecOps).

Le mauvais côté de l'analyse statique est qu'elle a la réputation d'être très bruyante, produisant par exemple des centaines, voire des milliers de violations juste au moment où vous pensiez être prêt à publier. Heureusement, il existe de bonnes stratégies pour y faire face. Voici quelques éléments à garder à l’esprit :

  • N'enregistrez pas les tests de sécurité jusqu'à la fin. Commencez à exécuter l'analyse statique dès que vous commencez à coder. Si vous attendez et ne l'exécutez que dans le cadre de votre pipeline CI / CD, les résultats vont s'accumuler et submerger votre équipe de développement. Exécutez-le sur le bureau pour trouver des problèmes, et exécutez-le dans CI / CD pour simplement vérifier que le code a été construit correctement
  • Affinez votre configuration. Certains vérificateurs d'analyse statique peuvent ne pas être nécessaires dans le contexte de votre code. Vérifiez votre application et déterminez les risques de sécurité qui comptent pour vous et ne travaillez que sur ceux-ci. Ne cherchez jamais les problèmes que vous ne prévoyez pas de résoudre.
  • L'âge du code compte. « Si ce n'est pas cassé, ne le réparez pas » devrait s'appliquer au code existant. Exécutez uniquement les scanners de sécurité les plus critiques sur du code plus ancien. Des problèmes mineurs vous feront perdre du temps et ces changements entraînent de nouveaux risques. Ne vérifiez jamais le code que vous ne prévoyez pas de corriger.
  • Tout est question de risque. Les outils SAST détectent à la fois les vulnérabilités réelles et potentielles. Toutes les découvertes ne comportent pas le même risque potentiel. OWASP Top Ten aide les développeurs à se concentrer en premier sur les problèmes les plus prioritaires. À l'aide des mappages de l'outil SAST avec les dix principales vulnérabilités OWASP, il est préférable de hiérarchiser et de trier vos résultats SAST.

Le pouvoir de la prévention dans l’apprentissage de l’OWASP

Je voudrais souligner quelque chose qui est important si vous souhaitez vraiment renforcer votre candidature. Il est facile de tester la sécurité, mais plus difficile de la construire. Heureusement, les vérificateurs d’analyse statique sont disponibles en différentes versions. Certains vérificateurs recherchent des problèmes typiques tels que des données corrompues et tentent de déterminer s'il existe un flux dans l'application où cela pourrait se produire. Ce sont les vérificateurs les plus courants dans de nombreux outils SAST.

Mais la plus grande valeur de l'analyse de code statique réside dans les vérificateurs qui appliquent deux choses spéciales:

  1. Un schéma fréquemment associé à des problèmes du passé. Bien que cela ne soit pas aussi intéressant qu'une trace de pile spécifique à un exploit, il peut être beaucoup plus approfondi de simplement réparer tout ce qui est plus faible qu'il ne devrait l'être plutôt que de résoudre uniquement les problèmes qui ont un vecteur d'attaque éprouvé.
  2. Exigences de types spécifiques de codage pour assurer un bon fonctionnement. Les normes automobiles et aéronautiques comme MISRA et JSF s'appuient sur cette technique pour assurer la sécurité fonctionnelle. La même technique consistant à exiger un bon code en plus de signaler le mauvais code vous aidera à créer des applications plus sécurisées.

Ironiquement, c'est l'approche que les industries critiques pour la sécurité utilisent depuis des décennies avec du matériel et des logiciels, mais d'une manière ou d'une autre, en cybersécurité, nous pensons que nous pouvons tester la sécurité dans une application et n'avons pas besoin de nous concentrer sur la création de code sécurisé. Tirez parti de toutes les capacités de l'analyse statique proactive, en plus des vérificateurs de détection précoce, pour obtenir le maximum de valeur.

Création de code sécurisé : meilleures pratiques de l'OWASP

Les meilleures pratiques que nous pouvons tirer du Top Ten de l’OWASP sont inscrites dans la liste elle-même. Par exemple, la clé pour éviter les défauts d’injection est de valider correctement toutes les entrées dans l’application. De plus, les bonnes pratiques suivantes sont nécessaires.

  • Gardez les données séparées des commandes et des requêtes.
  • Utilisez des API sécurisées.
  • Utilisez une validation d’entrée positive côté serveur.
  • Utilisez LIMIT et d'autres contrôles SQL dans les requêtes.
  • Assurer un contrôle d’accès approprié.
  • Sécurisez les données en transit et au repos.
  • Adoptez la sécurité dès la conception.
  • Garantissez des configurations sécurisées.
  • Assurer la sécurité de la chaîne d’approvisionnement logicielle.
  • Garantir l’intégrité du logiciel.
  • Assurer la journalisation et la surveillance de la sécurité.

Comment l'apprentissage de l'OWASP peut aider à l'évaluation des risques

Le OWASP Top Ten fournit une liste ordonnée des vulnérabilités de sécurité des applications Web les plus risquées. Ainsi, les développeurs d’applications Web disposent des informations dont ils ont besoin pour évaluer les risques de sécurité à mesure qu’ils surviennent. La priorité des incidents de sécurité ou de la détection des vulnérabilités lors du développement peut être priorisée en fonction de leur place dans la liste. Tous les Top Ten sont critiques, mais les développeurs doivent d'abord se concentrer sur les plus courants et les plus risqués.

Résumé : Vos prochaines étapes pour apprendre l'OWASP

Démarrer avec OWASP Top 10 ne sera pas facile si vous ne vous êtes jamais concentré sur la sécurité, mais cela est réalisable. DAST est un moyen simple de démarrer avec le Top 10, puis utiliser SAST vous aidera déplacez vos tests de sécurité vers la gauche. Mis en œuvre correctement, SAST peut même prévenir les problèmes, pas seulement les détecter. Recherchez donc des outils qui couvrent chaque élément de la liste, avec à la fois des vérificateurs de détection et de prévention.

Intégrer la sécurité à votre application dès le départ

Les développeurs d'applications Web peuvent intégrer la sécurité dans leurs applications dès le départ dans le contexte du Top Ten de l'OWASP en :

  • Comprendre le risque. Soyez conscient des vulnérabilités courantes.
  • Suivre des pratiques de codage sécurisées. Un codage sécurisé qui atténue les dix principaux risques.
  • Entraînement régulier. Les équipes de développement doivent apprendre le codage sécurisé et les meilleures pratiques OWASP.
  • Tester la sécurité. Effectuez des tests de sécurité continus, y compris des analyses statiques et dynamiques.
  • Effectuer des revues de code. Révisions régulières du code avec un accent sur la sécurité.
  • Adopter la sécurité dès la conception. La sécurité ne peut pas être renforcée plus tard.
  • Utiliser la modélisation des menaces. Identifiez les faiblesses de sécurité potentielles et corrigez-les dans l’architecture.

Le thème clé est d'intégrer dès le départ des mesures de sécurité dans le processus de développement, d'être proactif et de donner la priorité à l'atténuation grâce à l'évaluation des risques décrite dans le Top Ten de l'OWASP.

Avec ces conseils, vous devriez être prêt à commencer à éliminer les risques de sécurité des applications Web les plus courants et les plus dangereux aujourd'hui.

Intégrez la sécurité à votre application dès le départ.

« MISRA », « MISRA C » et le logo triangulaire sont des marques déposées de The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Tous droits réservés.

Article connexe + ressources