Qu'est-ce que le Top 10 de l'OWASP ?

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

Les risques de sécurité étant en constante évolution, la liste Top 10 de l'OWASP est révisée périodiquement pour 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 des vulnérabilités plus susceptibles de poser un risque important.

Si le Top 10 de l'OWASP est 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 n'ont pas été retenues dans le Top 10 2021 de l'OWASP. Pour se prémunir contre les faiblesses des logiciels, les défenseurs doivent envisager plus largement l'ensemble de leurs technologies de l'information. Cela signifie que les professionnels de la sécurité informatique doivent se concentrer sur l'ensemble de l'écosystème logiciel et aller au-delà des sources "traditionnelles" de vulnérabilité.

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

A1 : Injection

Des failles d'injection peuvent être introduites chaque fois qu'une source de données non fiable est envoyée à un interpréteur. On en 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 l'entrée de l'utilisateur, trompant l'interpréteur de requêtes pour qu'il exécute des commandes malveillantes.

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

• Les données fournies par les utilisateurs ne sont pas suffisamment validées.
• Les requêtes dynamiques sont exécutées sans une vérification suffisante des données d'entrée.
• Données hostiles utilisées dans les systèmes pour des comportements malveillants.

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

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

Comment Fortify peut-il aider à résoudre les problèmes d'injection ?

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

A2 : Authentification rompue

L'authentification interrompue peut être introduite lors de la gestion des données d'identité ou de session dans les applications avec état. Des exemples sont souvent trouvés lorsque l'enregistrement, la récupération des informations d'identification et les voies d'accès à l'API sont vulnérables aux jetons de session non expirés, au forçage brutal ou à l'énumération des comptes. Les attaquants prennent 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 erronée ?

• Expose, n'invalide pas correctement ou n'effectue pas la rotation des identifiants de session.
• N'aligne pas les politiques de mots de passe sur 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éfaillante ?

• L'usurpation d'identité des utilisateurs.
• Perte de confiance des utilisateurs.
• Compromission de données sensibles.

Comment Fortify peut-elle vous aider ?

• Si vous êtes développeur : Fortify détecte et recommande des mesures correctives pour les problèmes d'authentification interrompue.
• Si vous travaillez dans le domaine de l'assurance qualité ou des opérations : Fortify valide la sécurité de l'authentification et de la gestion des sessions de manière dynamique.
• Si vous êtes dans les opérations : Fortify permet de surveiller les événements liés aux applications Java et .NET pendant l'exécution.

A3 : Exposition de données sensibles

Des problèmes d'exposition aux données sensibles peuvent survenir lorsque des applications accèdent à des données non cryptées, en particulier à des informations personnelles identifiables (PII) et à d'autres types de données réglementées. Des exemples sont souvent trouvés lorsque des cyphers cryptographiques faibles sont utilisés dans des applications anciennes, que des protocoles de transport sécurisés sont mis en œuvre de manière incorrecte ou que la sécurité centrée sur les données n'est pas utilisée. Les attaquants accèdent aux données sensibles des utilisateurs qui leur permettent de contrôler la vie réelle.

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

• Transmission de données en texte clair via des protocoles tels que HTTP, SMTP et FTP.
• Données sensibles stockées, transmises ou utilisées inutilement en texte clair.
• Utilisation d'algorithmes cryptographiques anciens, faibles ou non fondés sur des normes.

Quel est l'impact de l'exposition des données sensibles ?

• Compromission de données réglementées (par ex. HIPAA ou GDPR) entraînant des amendes.
• Détournement d'identité entraînant des coûts de nettoyage ou de contrôle des données.
• Statut de non-conformité aux lois et règlements relatifs à la protection de la vie privée.

Comment Fortify peut-il contribuer à l'exposition des données sensibles ?

• Si vous êtes un développeur : Fortify identifie l'exposition aux données sensibles et automatise l'audit des problèmes.
• Si vous travaillez dans le domaine de l'assurance qualité ou des opérations : Fortify supprime les résultats atténués en dehors du contexte de l'application grâce au templating.
• Si vous êtes dans le domaine des opérations : Fortify instrumente la journalisation et la protection des applications en Java et .NET.

A4 : Entités externes XML

Des problèmes liés aux entités externes XML peuvent être introduits lorsqu'une entrée XML contenant une référence à une entité externe est traitée par un analyseur syntaxique faiblement configuré. On en trouve souvent des exemples dans les applications qui analysent des donné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 tels que SOAP 1.0. Le langage XML est omniprésent, qu'il s'agisse de SVG, de fichiers images, de protocoles de mise en réseau ou de formats de documents tels que PDF et RSS. Les attaquants référencent des entités externes dans l'entrée XML, ce qui entraîne l'exploitation des processeurs pour extraire des données, exécuter du code à distance ou avoir un impact sur les services du 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 activé les DTD.
• Utilisation de SAML pour le SSO, SOAP antérieur à v1.2, ou .NET Framework antérieur à v2.0.
• L'analyseur accepte des sources non fiables ou insère des données XML non fiables.

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

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

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

• Si vous êtes un développeur : Fortify détecte les analyseurs XML vulnérables et recommande des facteurs d'atténuation.
• Si vous êtes dans l'assurance qualité ou les opérations : Fortify recherche automatiquement les analyseurs XML vulnérables et valide les charges utiles des exploits.
• Si vous travaillez dans le domaine des opérations : Fortify assure la journalisation et la protection au moment de l'exécution pour les problèmes dans les applications Java et .NET.

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

Des problèmes de contrôle d'accès peuvent survenir lorsque le code et les restrictions environnementales se chevauchent de manière incomplète ou sont définis à plusieurs endroits pour une fonctionnalité similaire. Des exemples sont souvent trouvés lorsque la sécurité par l'obscurité est violé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 de plusieurs manières et à plusieurs 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éfaillant ?

• Possibilité d'agir en tant qu'utilisateur sans connexion, ou en tant qu'administrateur lorsque l'on est connecté en tant qu'utilisateur.
• Manipulation des métadonnées ou des 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éfaillant ?

• Divulgation d'informations non autorisées 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 à rompre le contrôle d'accès ?

• Si vous êtes développeur : Fortify automatise l'audit et permet de créer des modèles pour supprimer les problèmes atténués ailleurs.
• Si vous êtes 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 êtes dans le domaine des opérations : Fortify instrumente la journalisation du contrôle d'accès au moment de l'exécution pour les applications Java et .NET.

A6 : Mauvaise configuration de la sécurité

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

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

• Ports et comptes par défaut activés inutilement ou mots de passe inchangés.
• Révéler la trace de la pile ou d'autres messages en cas d'erreurs et d'exceptions.
• Le renforcement de la sécurité n'est pas adapté au risque posé par n'importe quelle partie de la pile.

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

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

Comment Fortify peut-il aider à résoudre les problèmes de mauvaise configuration de la sécurité ?

• Si vous êtes un développeur : Fortify identifie les dépendances des applications et les fichiers de configuration pendant les analyses.
• Si vous travaillez dans le domaine de l'assurance qualité et des opérations, Fortify évalue dynamiquement les configurations des applications et des serveurs afin de détecter les problèmes : Fortify évalue dynamiquement les configurations des applications et des serveurs pour détecter les problèmes.
• Si vous êtes dans le domaine des opérations : Fortify fournit une analyse open source pour la rédaction de rapports sur les risques environnementaux.

A7 : Scripts croisés (Cross-Site scripting)

Des failles de type Cross-Site Scripting (XSS) peuvent être introduites lorsque des données utilisateur non fiables et non assainies sont exécutées dans le cadre du code HTML, ou lorsque les utilisateurs peuvent être incités à interagir avec des liens malveillants. On en trouve souvent des exemples lorsque des constructions de code familières issues de langages tels que JavaScript ou Flash sont acceptées à partir de sources non fiables ou stockées en vue d'être affichées ultérieurement par un autre agent utilisateur. Les attaquants peuvent exécuter un code à distance sur la machine de l'utilisateur, voler des informations d'identification ou diffuser des logiciels malveillants à partir de sites de redirection.

Qu'est-ce qui rend une application vulnérable au cross-site scripting (XSS) ?

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

• XSS réfléchi : l'application ou l'API inclut une entrée non fiable dans la sortie HTML.
• XSS stocké : un code non aseptisé enregistré sur le disque est déclenché ultérieurement par une action de l'utilisateur.
• DOM XSS : Applications, frameworks et API qui consomment des données d'entrée non fiables.

Quel est l'impact du cross-site scripting (XSS) ?

• 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 à lutter contre le cross-site scripting (XSS) ?

• Si vous êtes un développeur : Fortify détecte les vulnérabilités XSS dans le code et prédit la probabilité d'une exploitation.
• Si vous êtes dans l'assurance qualité et les opérations : Fortify valide le code dynamiquement pour les entrées non nettoyées vulnérables au XSS.
• Si vous travaillez dans le domaine des opérations : Fortify permet de consigner les é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ûres peuvent être introduites lorsque des langages et des cadres permettent à des données sérialisées non fiables d'être développées dans un objet, souvent lorsque les applications web communiquent avec l'utilisateur ou sauvegardent l'état de l'application. Des exemples sont souvent trouvés lorsque les développeurs n'imposent aucune restriction sur les méthodes qui peuvent s'exécuter d'elles-mêmes pendant le processus de désérialisation. Les attaquants exploitent ces chaînes de gadgets "" appelées en dehors de la logique de l'application pour exécuter du code à distance, refuser 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 pas la source ou le contenu avant la désérialisation.
• Les classes acceptables ne sont pas inscrites sur la liste blanche afin d'éviter toute exposition inutile à des gadgets.

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

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

Comment Fortify peut-il aider à la désérialisation non sécurisée ?

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

A9 : Utilisation de composants dont les vulnérabilités sont connues

Ces failles peuvent être introduites lorsque des cadres et des bibliothèques open source ou tiers sont introduits dans une application et exécutés avec les mêmes privilèges. On trouve souvent des exemples où le développement basé sur les composants entraîne un manque de compréhension des risques associés aux dépendances et où les composants ou les systèmes sont difficiles ou impossibles à corriger. Les attaquants ont utilisé des composants vulnérables pour certaines des plus grandes brèches de l'histoire, bien que les vulnérabilités puissent aller de la compromission d'une application à l'exécution d'un code à distance.

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

• Elles peuvent être accidentelles (par ex. erreur de codage) ou intentionnelle (ex. composant endossé).
• L'application ou l'environnement utilise des composants non corrigés ou obsolètes (l'une des raisons pour lesquelles la modernisation des applications est essentielle).
• Absence d'analyse des vulnérabilités dans les codes 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 dont les vulnérabilités sont connues ?

Si certaines vulnérabilités connues n'ont que des conséquences mineures, certaines des plus grandes brèches connues, telles que Heartbleed et Shellshock, reposent sur l'exploitation de 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 concerné, ce qui permet à l'attaquant de prendre le contrôle total de la machine.

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

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

A10 : Insuffisance de la journalisation et de la surveillance

Des failles insuffisantes dans la journalisation et la surveillance peuvent être introduites lorsque les vecteurs d'attaque ou les comportements erronés des applications ne sont pas bien compris ou que les meilleures pratiques de surveillance des indicateurs de compromission ne sont pas suivies. On en trouve souvent des exemples dans les systèmes existants dépourvus de capacités de journalisation, lorsque les journaux des tests de pénétration des 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 sur une moyenne d'environ 200 jours pour la détection qui est généralement découverte à l'extérieur pour établir la persistance et pivoter vers d'autres systèmes vulnérables.

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

• Les avertissements et les erreurs ne génèrent aucun message, ou des messages inadéquats 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 n'entraînent aucune action.

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

La plupart des attaques réussies commencent par l'exploration des vulnérabilités. Permettre à ces sondes de se poursuivre peut augmenter la probabilité d'une exploitation réussie. Les attaquants peuvent établir une persistance, rétroagir avec les applications et les systèmes d'exploitation, voler des données ou prendre le contrôle inaperçu et non autorisé des systèmes. Si les informations critiques pour la sécurité ne sont pas enregistrées ou stockées de manière appropriée, il n'y aura pas de trace pour une analyse médico-légale permettant de découvrir la source de l'attaque. Comprendre qu'il y a un problème peut devenir plus difficile, voire impossible, si l'attaquant garde le contrôle des capacités de journalisation.

Comment Fortify peut-il contribuer à une journalisation et à une surveillance insuffisantes ?

• Si vous êtes développeur : Fortify recherche les vulnérabilités dans les capacités de journalisation des applications et des API.
• Si vous travaillez dans le domaine de l'assurance qualité et des opérations : Les analyses dynamiques de Fortify produisent des journaux d'application pour l'examen de la suffisance, comme les tests d'intrusion.
• Si vous êtes dans le domaine des opérations : Fortify instrumente la journalisation et la protection des applications Java et .NET.

Quoi de neuf pour l'OWASP (2021) ?

Bien que le dernier top 10 ait été publié en 2017 il y a seulement quatre ans, le secteur de la cybersécurité a connu de nombreux changements qui nous ont amenés à réfléchir à deux fois sur les préoccupations prioritaires ou sur les nouvelles préoccupations à ajouter.

Trois nouvelles catégories ont été introduites :

A04:2021

Conception incertaine : Cette catégorie se concentre sur les défauts de conception. Cela est nécessaire parce que le mouvement de déplacement vers la gauche en matière de développement nécessite également un déplacement vers la gauche en matière de modélisation des menaces.

A08:2021

Défauts d'intégrité des logiciels et des données : Se concentre sur les hypothèses concernant les mises à jour de logiciels, les données critiques et le pipeline CI/CD sans vérifier l'intégrité qu'elles peuvent avoir. Il intègre également la norme A08:2017 - Insecure Deserialization.

A10:2021

Falsification des requêtes côté serveur (SSRF) : Cette catégorie figure principalement dans le top 10 de l'enquête communautaire. Ils ont vraiment insisté sur cette vulnérabilité en raison de son exploitabilité et de son impact supérieurs à la moyenne.

Autres changements

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 - Broken Authentication a été renommé Identification and Authentication Failures et déplacé en A07.
• A03:2017 - Sensitive Data Exposure a été déplacée vers A02, renommée Cryptographic Failures (défaillances cryptographiques), afin de s'attaquer plus complètement à la cause première, et pas seulement aux symptômes.
• A05:2017 - Broken Access Control a été déplacé à A01 parce que 94% des applications testées ont montré une exposition à une forme quelconque de contrôle d'accès brisé.
• A06:2017 - Security Misconfiguration a été déplacée d'une place à A05.
• A07:2017 - Cross-Site Scripting (XSS) a été consolidée dans A03 Injection.
• A09:2017 - Using Components with Known Vulnerabilities a été déplacée vers A06 et renommée Vulnerable and Outdated Components (Composants vulnérables et obsolètes). Ce changement est dû en grande partie au fait que la communauté l'a placé en deuxième position sur sa liste.
• A10:2017 - Insuffisance de la journalisation & La surveillance a été déplacée vers la norme A09 et s'intitule désormais Défaillances de la journalisation et de la surveillance de la sécurité.

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