Quel est le Top 10 de l'OWASP ?

L'Open Web Application Security Project (OWASP) est une communauté de sécurité des applications open source dont l'objectif est d'améliorer la sécurité des logiciels. Le Top 10 de l'OWASP est une norme sectorielle qui énumère les risques de sécurité des applications les plus critiques afin d'aider les développeurs à mieux sécuriser les applications qu'ils conçoivent et déploient.

Étant donné que les risques de sécurité évoluent constamment, la liste OWASP Top 10 est révisée périodiquement afin de refléter ces changements. Dans la dernière version du Top 10 de l'OWASP publiée en 2021, certains types de vulnérabilités qui ne représentent plus une menace sérieuse ont été remplacés par ceux qui sont les plus susceptibles de présenter un risque important.

Bien que le Top 10 de l'OWASP soit un excellent point de départ pour sécuriser les applications, il ne doit certainement pas être considéré comme un objectif final, car certaines des vulnérabilités les plus citées ne figurent pas dans le Top 10 de l'OWASP 2021. Pour se prémunir contre les failles logicielles, les responsables de la sécurité doivent adopter une vision plus globale de leur infrastructure informatique. Cela signifie que les professionnels de la sécurité informatique doivent se concentrer sur l'ensemble de l'écosystème logiciel et regarder au-delà des sources de vulnérabilités « traditionnelles ».

Quelles sont les 10 catégories principales de l'OWASP (2021) ?

A1 : Injection

Les failles d'injection peuvent être introduites chaque fois qu'une source de données non fiable est envoyée à un interpréteur. On trouve souvent des exemples dans les requêtes de bases de données dynamiques SQL, LDAP, XPath ou NoSQL avec des données fournies par l'utilisateur. Les attaquants injectent du code dans les données saisies par l'utilisateur, trompant ainsi l'interpréteur de requêtes et l'amenant à exécuter des commandes malveillantes.

Qu'est-ce qui rend une application vulnérable aux failles d'injection ?

• Les données fournies par l'utilisateur ne sont pas suffisamment validées.
• Les requêtes dynamiques s'exécutent sans une désinfection suffisante des données d'entrée.
• Données hostiles utilisées au sein des systèmes à des fins malveillantes.

Quel est l'impact des défauts d'injection ?

• Compromission de l'application ou du système hôte sous-jacent.
• Divulgation de données sensibles.
• Perte de productivité, de réputation ou de revenus.

Comment Fortify peut-il aider à corriger les défauts d'injection ?

• Si vous êtes développeur : Fortify détecte les failles d’injection et fournit des conseils de correction spécifiques au type de code.
• Si vous travaillez dans l'assurance qualité ou les opérations : Fortify valide le code à l'exécution pour les contrôles d'atténuation.
• Si vous travaillez dans le domaine des opérations : Fortify assure la journalisation en temps réel et la protection contre les tentatives d’injection Java et .NET.

A2 : Authentification défaillante

Des failles d'authentification peuvent survenir lors de la gestion des données d'identité ou de session dans les applications avec état. On trouve souvent des exemples de ce type de vulnérabilité lorsque l'enregistrement, la récupération des identifiants et les voies d'accès API sont exposés à des jetons de session non expirés, à des attaques par force brute ou à l'énumération des comptes. Les attaquants usurpent l'identité d'utilisateurs légitimes, prennent le contrôle des comptes et compromettent les données, les processus ou les systèmes.

Qu'est-ce qui rend une application vulnérable à une authentification défaillante ?

• Expose, n'invalide pas correctement ou ne parvient pas à faire tourner les identifiants de session.
• Ne conforme pas les politiques de mots de passe à des normes telles que NIST 800-63B.
• Absence d'authentification à deux facteurs (2FA) ou possibilité d'attaques automatisées.

Quel est l'impact d'une authentification défectueuse ?

• Vol d'identité de l'utilisateur.
• Perte de confiance des utilisateurs.
• Compromission de données sensibles.

Comment Fortify peut-il vous aider ?

• Si vous êtes développeur : Fortify détecte les problèmes d’authentification et recommande des solutions.
• Si vous travaillez dans l'assurance qualité ou les opérations : Fortify valide dynamiquement la sécurité de l'authentification et de la gestion des sessions.
• Si vous travaillez dans les opérations : Fortify utilise des instruments de surveillance d'exécution pour les événements des applications Java et .NET.

A3 : Exposition de données sensibles

Des problèmes d'exposition de données sensibles peuvent survenir lorsque des applications accèdent à des données non chiffrées, notamment aux renseignements personnels identifiables (IPI) et à d'autres types de données réglementées. On rencontre souvent des exemples de ce type lorsque des algorithmes de chiffrement cryptographiques faibles sont utilisés dans des applications existantes, lorsque des protocoles de transport sécurisés sont mal implémentés ou lorsque la sécurité axée sur les données n'est pas utilisée. Les attaquants obtiennent l'accès à des données sensibles des utilisateurs, ce qui leur donne un contrôle réel.

Qu'est-ce qui rend une application vulnérable à l'exposition à des données sensibles ?

• Transmission de données en clair via des protocoles tels que HTTP, SMTP et FTP.
• Des données sensibles sont stockées, transmises ou utilisées inutilement en clair.
• Utilisation d'algorithmes cryptographiques anciens, faibles ou non conformes aux normes.

Quel est l'impact de la divulgation de données sensibles ?

• Compromission de données réglementées (par exemple HIPAA ou RGPD) entraînant des amendes.
• Le détournement d'identité entraîne des coûts de nettoyage ou de surveillance des données.
• Statut de non-conformité aux lois et réglementations relatives à la protection de la vie privée.

Comment Fortify peut-il aider à gérer l'exposition des données sensibles ?

• Si vous êtes développeur : Fortify identifie les expositions de données sensibles et automatise l’audit des problèmes.
• Si vous travaillez dans l'assurance qualité ou les opérations : Fortify élimine les anomalies résolues en dehors du contexte de l'application grâce à la création de modèles.
• Si vous travaillez dans les opérations : Fortify renforce la journalisation et la protection des applications Java et .NET.

A4 : Entités externes XML

Des problèmes liés aux entités externes XML peuvent survenir lorsqu'une entrée XML contenant une référence à une entité externe est traitée par un analyseur syntaxique faiblement configuré. On trouve souvent des exemples dans les applications qui analysent des entrées XML provenant de sources non fiables, lorsque les définitions de type de document (DTD) sont activées, ou qui utilisent des cadres non corrigés comme SOAP 1.0. Le XML est omniprésent, des fichiers SVG et images aux protocoles réseau et aux formats de documents tels que le PDF et le RSS. Les attaquants font référence à des entités externes dans les entrées XML, ce qui permet aux processeurs d'être exploités pour extraire des données, exécuter du code à distance ou impacter les services réseau.

Qu'est-ce qui rend une application vulnérable aux entités externes XML ?

• L'application analyse les documents XML et les processeurs ont les DTD activées.
• Utilisation de SAML pour l'authentification unique (SSO), de SOAP avant la version 1.2 ou de .NET Framework avant la version 2.0.
• L'analyseur syntaxique accepte des sources non fiables ou insère des données XML non fiables.

Quel est l'impact des entités XML externes ?

• Vol de données sensibles.
• Chargement de l'URL contrôlée par l'attaquant.
• Attaques par déni de service (DoS).

Comment Fortify peut-il aider avec les entités externes XML ?

• Si vous êtes développeur : Fortify détecte les analyseurs XML vulnérables et recommande des mesures d’atténuation.
• Si vous travaillez dans l'assurance qualité ou les opérations : Fortify analyse automatiquement les analyseurs XML vulnérables et valide les charges utiles d'exploitation.
• Si vous travaillez dans le domaine des opérations : Fortify assure la journalisation en temps réel et la protection contre les problèmes dans les applications Java et .NET.

A5 : Contrôle d'accès défectueux

Des problèmes de contrôle d'accès peuvent survenir lorsque les restrictions liées au code et à l'environnement se chevauchent incomplètement ou sont définies à plusieurs endroits pour des fonctionnalités similaires. On trouve souvent des exemples de ce phénomène lorsque la sécurité par l'obscurité est contournée par une navigation forcée vers des pages restreintes, ou lorsque l'application définit des méthodes complexes de contrôle d'accès à plusieurs niveaux et à différents endroits. Les attaquants peuvent compromettre les limites d'accès pour voler des données sensibles ou perturber les opérations.

Qu'est-ce qui rend une application vulnérable à un contrôle d'accès défectueux ?

• Possibilité d'agir en tant qu'utilisateur sans se connecter, ou en tant qu'administrateur lorsqu'on est connecté en tant qu'utilisateur.
• Manipulation de métadonnées ou de jetons pour obtenir des privilèges non autorisés ou élevés.
• Logique de contrôle d'accès byzantine, non appliquée ou dispersée.

Quel est l'impact d'un contrôle d'accès défectueux ?

• Divulgation non autorisée de renseignements ou compromission de données sensibles.
• Modification ou destruction des données.
• Prise de contrôle de l'administration du site ou des utilisateurs.

Comment Fortify peut-il aider à résoudre les problèmes de contrôle d'accès ?

• Si vous êtes développeur : Fortify automatise l’audit et permet l’utilisation de modèles pour résoudre les problèmes traités ailleurs.
• Si vous travaillez dans l'assurance qualité et les opérations : les agents Fortify détectent les surfaces d'attaque cachées et les systèmes de contrôle d'accès défaillants.
• Si vous travaillez dans les opérations : Fortify utilise la journalisation du contrôle d’accès à l’exécution pour les applications Java et .NET.

A6 : Mauvaise configuration de sécurité

Des failles de sécurité liées à une mauvaise configuration peuvent être introduites lors de la configuration de l'application ou de son environnement sous-jacent. Une mauvaise configuration peut survenir à n'importe quel niveau de la pile d'applications, des services réseau et serveurs d'applications aux conteneurs et au stockage. On en trouve souvent des exemples dans les comptes et configurations par défaut, les messages d'erreur « faussés » ou les cadres et services non corrigés. Les attaquants peuvent obtenir des renseignements sur le déploiement et accéder à des données confidentielles afin de perturber les opérations.

Qu'est-ce qui rend une application vulnérable à une mauvaise configuration de sécurité ?

• Ports et comptes par défaut activés inutilement ou mots de passe inchangés.
• Afficher la trace de la pile ou d'autres messages en cas d'erreurs et d'exceptions.
• Renforcement insuffisant de la sécurité face aux risques posés par chaque composant de la pile.

Quel est l'impact d'une mauvaise configuration de sécurité ?

L'impact peut aller de la simple divulgation d'informations à la compromission complète du système.

Comment Fortify peut-il aider en cas de mauvaise configuration de sécurité ?

• Si vous êtes développeur : Fortify identifie les dépendances des applications et les fichiers de configuration lors des analyses.
• Si vous travaillez dans l'assurance qualité et les opérations : Fortify évalue dynamiquement les configurations des applications et des serveurs pour détecter les problèmes.
• Si vous travaillez dans le domaine des opérations : Fortify propose des analyses à code source ouvert pour la production de rapports sur les risques environnementaux.

A7 : Script intersite

Les failles de type Cross-Site Scripting (XSS) peuvent être introduites lorsque des entrées utilisateur non fiables et non nettoyées sont exécutées dans le cadre du code HTML, ou lorsque les utilisateurs peuvent être influencés pour interagir avec des liens malveillants. On trouve souvent des exemples de ce type lorsque des éléments de code familiers provenant de langages tels que JavaScript ou Flash sont acceptés de sources non fiables ou stockés pour être affichés ultérieurement par un autre agent utilisateur. Les attaquants peuvent exécuter du code à distance sur la machine de l'utilisateur, voler des identifiants ou diffuser des logiciels malveillants à partir de sites de redirection.

Qu'est-ce qui rend une application vulnérable aux attaques de type cross-site scripting (XSS) ?

Il existe trois formes de XSS, ciblant généralement les agents utilisateurs tels que les navigateurs :

• XSS par réflexion : L'application ou l'API inclut des données d'entrée non fiables dans la sortie HTML.
• XSS stocké : du code non nettoyé enregistré sur le disque est déclenché ultérieurement par une action de l’utilisateur.
• XSS DOM : Applications, cadres et API qui consomment des entrées non fiables.

Quel est l'impact des attaques XSS (Cross-Site Scripting) ?

• Prise de contrôle du compte de la victime dans l'application.
• Récupération des données de l'application Web cible.
• Modification du contenu de la page.

Comment Fortify peut-il aider à combattre les attaques XSS (Cross-Site Scripting) ?

• Si vous êtes développeur : Fortify détecte les vulnérabilités XSS dans le code et prédit la probabilité d’exploitation.
• Si vous travaillez dans l'assurance qualité et les opérations : Fortify valide dynamiquement le code pour les entrées non nettoyées vulnérables aux attaques XSS.
• Si vous travaillez dans le domaine des opérations : Fortify assure la journalisation des événements Java et .NET, y compris les redirections non autorisées.

A8 : Désérialisation non sécurisée

Des failles de désérialisation non sécurisées peuvent être introduites lorsque les langages et les cadres permettent de transformer des données sérialisées non fiables en un objet, souvent lorsque des applications Web communiquent avec l'utilisateur ou enregistrent l'état de l'application. On trouve souvent des exemples de ce genre lorsque les développeurs n'imposent aucune restriction aux méthodes qui peuvent s'exécuter automatiquement pendant le processus de désérialisation. Les attaquants exploitent ces « chaînes de gadgets » appelées en dehors de la logique applicative pour exécuter du code à distance, interrompre le service ou obtenir un accès non autorisé.

Qu'est-ce qui rend une application vulnérable à une désérialisation non sécurisée ?

• L'application désérialise des données provenant de sources non fiables.
• L'application ne vérifie ni la source ni le contenu avant la désérialisation.
• Les classes autorisées ne sont pas listées comme telles afin d'éviter une exposition inutile des appareils.

Quel est l'impact d'une désérialisation non sécurisée ?

• Ces failles peuvent mener à des attaques d'exécution de code à distance, l'une des attaques les plus graves qui soient.

Comment Fortify peut-il aider en cas de désérialisation non sécurisée ?

• Si vous êtes développeur : Fortify détecte les vulnérabilités dans le code source et fournit une analyse des composants.
• Si vous travaillez dans l'assurance qualité et les opérations : Fortify utilise des instruments dynamiques pour exécuter des applications et valider les vecteurs d'attaque.
• Si vous travaillez dans les opérations : Fortify utilise la journalisation des instruments pour les événements Java et .NET, y compris la désérialisation.

A9 : Utilisation de composants présentant des vulnérabilités connues

Ces failles peuvent apparaître lorsque des cadres et des bibliothèques open source ou tiers sont intégrés à une application et exécutés avec les mêmes privilèges. On constate souvent des exemples où le développement par composants entraîne un manque de compréhension des risques liés aux dépendances et où les composants ou les systèmes sont difficiles, voire impossibles, à corriger. Les attaquants ont exploité des composants vulnérables pour certaines des plus grandes violations de l'histoire, même si les vulnérabilités peuvent aller de la compromission d'applications à l'exécution de code à distance.

Qu'est-ce qui rend une application vulnérable aux cadres et bibliothèques libres ou tiers ?

• Ces erreurs peuvent être accidentelles (par exemple, erreur de codage) ou intentionnelle (par exemple composant à porte dérobée).
• L'application ou l'environnement utilise des composants non corrigés ou désuets (une des raisons pour lesquelles la modernisation des applications est essentielle).
• Absence d'analyse des vulnérabilités dans le code tiers ou les dépendances imbriquées.
• Inventaires de composants indisponibles ou bulletins de sécurité ignorés.

Quel est l'impact de l'utilisation de composants présentant des vulnérabilités connues ?

Alors que certaines vulnérabilités connues n'entraînent que des conséquences mineures, certaines des plus importantes violations de données connues, telles que Heartbleed et Shellshock, ont exploité des vulnérabilités connues dans des composants partagés. L'utilisation de composants présentant des vulnérabilités de code connues peut entraîner l'exécution de code à distance sur le serveur affecté, donnant ainsi à l'attaquant le contrôle total de la machine.

Comment Fortify peut-il contribuer à la sécurité des logiciels libres ?

• Si vous êtes développeur : Fortify offre une analyse des composants logiciels par le biais des intégrations Sonatype.
• Si vous travaillez dans l'assurance qualité et les opérations : Fortify automatise la validation dynamique des vulnérabilités connues lors de l'exécution.
• Si vous travaillez dans les opérations : Fortify fournit des outils de journalisation et de protection pour les composants d'application Java et .NET.

A10 : Journalisation et surveillance insuffisantes

Des failles dans la journalisation et la surveillance peuvent survenir lorsque les vecteurs d'attaque ou les dysfonctionnements des applications sont mal compris, ou lorsque les bonnes pratiques de surveillance des indicateurs de compromission ne sont pas respectées. On trouve souvent des exemples de ce type dans les systèmes anciens dépourvus de capacités de journalisation, lorsque les journaux des tests d'intrusion d'applications ne sont pas examinés, ou lorsque les journaux ne fournissent pas suffisamment de détails pour comprendre ce que les attaquants ont fait. Les attaquants comptent en moyenne sur environ 200 jours pour être détectés, généralement de l'extérieur, afin d'établir leur présence et de se tourner vers d'autres systèmes vulnérables.

Qu'est-ce qui rend une application vulnérable à une journalisation et une surveillance insuffisantes ?

• Les avertissements et les erreurs ne génèrent aucun message de journalisation, ou des messages insuffisants ou peu clairs.
• Les journaux sont stockés localement sans contrôle d'intégrité et/ou ne sont pas surveillés.
• Les seuils d'alerte et les processus de réponse sont insuffisants ou ne donnent aucune action.

Quel est l'impact d'une journalisation et d'une surveillance insuffisantes ?

La plupart des attaques réussies commencent par une analyse des vulnérabilités. Autoriser la poursuite de telles investigations peut augmenter la probabilité de réussite des exploits. Les attaquants peuvent s'implanter durablement, en créant des portes dérobées dans les applications et les systèmes d'exploitation, en volant des données ou en obtenant d'une autre manière un contrôle non autorisé et inaperçu des systèmes. Si les renseignements critiques en matière de sécurité ne sont pas consignés ou stockés correctement, il n'y aura aucune trace permettant une analyse médico-légale pour découvrir la source de l'attaque. Comprendre qu'il y a un problème peut devenir plus difficile, voire impossible, si l'attaquant conserve le contrôle des capacités de journalisation.

Comment Fortify peut-il aider en cas d'insuffisance de journalisation et de surveillance ?

• Si vous êtes développeur : Fortify analyse les fonctionnalités de journalisation des applications et des API afin d’y déceler les vulnérabilités.
• Si vous travaillez dans l'assurance qualité et les opérations : les analyses dynamiques de Fortify génèrent des journaux d'application pour un examen de suffisance, comme les tests d'intrusion.
• Si vous travaillez dans les opérations : Fortify renforce la journalisation et la protection des applications Java et .NET.

Quelles sont les nouveautés pour OWASP (2021) ?

Bien que seulement quatre ans se soient écoulés depuis la publication du dernier top 10 en 2017, de nombreux changements sont survenus dans le secteur de la cybersécurité, ce qui nous a amenés à reconsidérer les préoccupations prioritaires et à ne pas en ajouter de nouvelles.

Trois nouvelles catégories ont été introduites :

A04:2021

Conception non sécurisée : cette catégorie se concentre sur les défauts de conception. Cela est nécessaire car le mouvement en faveur d'une approche plus prospective du développement exige également une approche plus prospective de la modélisation des menaces.

A08:2021

Défaillances d'intégrité des logiciels et des données : se concentre sur les hypothèses concernant les mises à jour logicielles, les données critiques et le pipeline CI/CD sans vérifier l'intégrité qu'elles peuvent impacter. Cela intègre également la norme A08:2017 – Désérialisation non sécurisée.

10:2021

Falsification de requête côté serveur (SSRF) : cette catégorie figure généralement dans le top 10 du sondage auprès de la communauté. Ils ont vraiment insisté sur cette vulnérabilité en raison de son exploitabilité et de son impact au-dessus de la moyenne.

Autres modifications

Les autres catégories ont soit changé de nom, soit changé de rang, soit été regroupées dans d'autres catégories :

• A01:2017 – Injection déplacée vers A:03.
• A02:2017 – Authentification défaillante a été renommée Échecs d'identification et d'authentification et déplacée vers A07.
• A03:2017 – L'exposition de données sensibles a été déplacée vers A02 renommé Défaillances cryptographiques afin de traiter plus pleinement la cause profonde, et non seulement les symptômes.
• A05:2017 – Le contrôle d'accès défaillant a été déplacé vers A01 car 94 % des applications testées présentaient une exposition à une forme ou une autre de contrôle d'accès défaillant.
• A06:2017 – Erreur de configuration de sécurité a été déplacée d'un rang vers A05.
• A07:2017 – Cross-Site Scripting (XSS) a été intégré à A03 Injection.
• A09:2017 – Utilisation de composants présentant des vulnérabilités connues a été déplacé vers A06 et renommé Composants vulnérables et obsolètes. Ce changement est dû en grande partie au fait que la communauté l'a classé numéro 2 sur sa liste.
• A10:2017 – La journalisation et la surveillance insuffisantes ont été déplacées vers A09 et sont désormais appelées Défaillances de la journalisation et de la surveillance de la sécurité.

Vous voulez savoir comment Fortify peut aider votre organisation ? Lancez votre essai gratuit de 15 jours de Fortify on Demand dès maintenant par OpenText ™