Premiers pas avec AppSec en utilisant OWASP

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 OWASP?

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.

Quelles sont les 10 principales vulnérabilités de l'OWASP aujourd'hui ?

Le Top 10 OWASP a été mis à jour pour la dernière fois en 2017 et comprend les vulnérabilités A1-A10 suivantes:

1. Injection
2. Authentification brisée
3. Exposition de données sensibles
4. Entités externes XML (XXE)
5. Contrôle d'accès cassé
6. Mauvaise configuration de la sécurité
7. XSS (Cross-Site Scripting)
8. Désérialisation non sécurisée
9. Utilisation de composants avec des vulnérabilités connues
10. Journalisation et surveillance insuffisantes

OWASP fournit une documentation pour le Top 10, avec une page Web dédiée à chaque vulnérabilité. La page décrit ce qu'est chaque vulnérabilité et fournit un score de risque, qui est utilisé pour aider à hiérarchiser et trier les vulnérabilités possibles. Voir un exemple de la page ci-dessous:

Les différentes sections de la page vous aident à comprendre l'importance et le danger de chacune des vulnérabilités.

L'application est-elle vulnérable?

La section appelée L'application est-elle vulnérable explique ce que cela signifie pour une application d'avoir la vulnérabilité et quels types d'outils (DAST, SAST, etc.) sont utiles pour trouver cette vulnérabilité particulière.

Exemples de scénarios d'attaque

Les Exemples de scénarios d'attaque La section montre comment un attaquant peut tirer parti de chaque vulnérabilité. Ces informations peuvent être utilisées pour créer des tests et informer l'équipe sur la manière dont les vulnérabilités logicielles affectent la sécurité des applications.

Comment empêcher

Les Comment empêcher section 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é d'application renforcée. Cette section décrit diverses stratégies qui vous aideront à déplacer votre sécurité vers la gauche 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 Security-by-Design (requise par le RGPD, par exemple).

Références

Enfin, chaque élément du Top 10 a une section avec plus d'informations sur chaque problème, des approches pour l'éviter et des 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 votre logiciel.

Lors de la lecture de la documentation OWASP Top 10, vous constaterez peut-être que certains éléments sont évidents à partir de leur seul nom, tandis que d'autres doivent être approfondis pour être compris. Par example, A1 - «Injection» - est en fait un large éventail de choses comme l'injection SQL, l'injection de commandes, l'injection LDAP, etc. À la base de cette faiblesse de sécurité, il y a le fait que les entrées de l'utilisateur ne sont pas suffisamment vérifiées et nettoyées avant qu'une application l'utilise.

Pourquoi utiliser OWASP Top 10?

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 quel (s) vérificateur (s) prennent en charge quels éléments de la norme, et s'il y a ou non des éléments de la norme qui nécessitent plus qu'une analyse statique (c'est-à-dire une revue de code par les pairs ou une analyse de la composition logicielle).

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 et de système complet tels que les tests de pénétration (je pourrais appeler cela quelque chose comme DevTestOpsSec). Ce test est idéal 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 ce test de la boîte noire n'est pas le moyen le plus efficace de produire un code plus sécurisé. Nous ne voulons pas nous fier aux tests en boîte noire pour sécuriser notre logiciel ou trouver des bogues, autant que nous voulons l'utiliser pour prouver que le logiciel is garantir.

Donc, si le test de pénétration trouve une vulnérabilité, nous devons nous demander pourquoi et essayez de résoudre la cause profonde sous-jacente au problème. C'est à ce moment-là que nous passons d'une mentalité de « test de sécurité dans » à une mentalité de « sécurité dès la conception ». Pour cela, vous trouverez des outils de test de sécurité des applications statiques (SAST) tels que l'analyse de code statique, avec prise en charge de l'OWASP.

Plus que DAST et SAST

Une petite chose à noter est que l'élément A9 dans le Top 10 OWASP est complètement différent du reste et ne se prête pas à SAST or 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 dans vos composants open source en analysant comme une partie régulière de 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.)

Outils et astuces d'analyse de code statique

La beauté de l'analyse statique est que vous n'avez pas besoin d'avoir l'ensemble de l'application ou du système terminé, vous pouvez donc commencer à vérifier les problèmes de sécurité beaucoup plus tôt dans le cycle (pour shift-gauche tests de sécurité). Si vous effectuez la sécurité tardivement 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 que le test ne commence, pendant que le code est en fait en cours d'écriture (DevSecOps).

Le côté laid de l'analyse statique est qu'elle a la réputation d'être très bruyante, par exemple en produisant des centaines, voire des milliers de violations juste au moment où vous pensiez être prêt à sortir. Heureusement, il existe de très bonnes stratégies pour y faire face. Voici quelques points à 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 hérité. N'exécutez les scanners de sécurité les plus critiques que sur un code plus ancien. Des problèmes mineurs vous feront perdre du temps, et ces changements comportent leur propre risque. Ne vérifiez jamais le code que vous ne prévoyez pas de corriger.
• Tout est question de risque. Les outils SAST trouvent à la fois des vulnérabilités réelles et potentielles. Tous les résultats ne présentent pas le même risque potentiel. OWASP a aidé en définissant le risque pour chaque élément du Top 10 en fonction de la facilité avec laquelle il est d'exploiter une faiblesse, de la facilité avec laquelle quelqu'un trouve la faiblesse et de l'impact réel de l'exploit. Utilisez ces informations utiles pour hiérarchiser et trier vos résultats SAST:

Le pouvoir de la prévention

Je voudrais souligner quelque chose qui est important si vous voulez vraiment durcir votre application. Il est très facile de tester la sécurité, mais plus difficile à construire pour cela. Heureusement, les contrôleurs d'analyse statique sont disponibles dans différentes saveurs. Certains vérificateurs recherchent des problèmes typiques tels que des données corrompues et essaient 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 modèle fréquemment associé à des problèmes du passé. Bien que cela puisse ne pas être aussi intéressant qu'une trace de pile spécifique à un exploit, il peut être beaucoup plus complet de simplement corriger tout ce qui est plus faible qu'il ne devrait l'être que de ne résoudre que 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 garantir la sécurité fonctionnelle. La même technique d'exiger un bon code en plus de signaler un 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.

Résumé

Obtenir le Top 10 OWASP ne sera pas facile si vous ne vous êtes jamais concentré sur la sécurité, mais c'est réalisable et c'est un excellent point de départ. DAST est un moyen simple de commencer 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 éviter les problèmes, pas seulement les détecter, alors recherchez des outils qui couvrent entièrement la norme, avec des contrôleurs de détection et de prévention.

Apprenez à utiliser la notation des risques OWASP pour aider à hiérarchiser les résultats et vous assurer que vos outils fournissent ces informations sur les risques avec leurs résultats. Cela vous aidera à vous concentrer sur ce qui est le plus important et qui est la clé d'une mise en œuvre réussie 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.

« 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.