Conformité OWASP

Les échecs cryptographiques se classent désormais en position n ° 2 à partir du n ° 3 sur la précédente liste des 10 meilleurs OWASP. Cette vulnérabilité était connue sous le nom de "Sensitive Data Exposure". Le nouveau nom se concentre sur la cause profonde du problème au lieu d'un symptôme plus large comme l'ancien terme.

Que sont les échecs cryptographiques ?

Les défaillances cryptographiques entraînent souvent des violations de données. Des exemples de vecteurs de menace incluent des choses comme un manque d'en-têtes HTTP, des algorithmes cryptographiques faibles, la transmission de données en texte clair, etc. Les données violées peuvent inclure tout, des simples mots de passe aux dossiers de santé et aux numéros de carte de crédit.

Quel est l'impact des échecs cryptographiques ?

Les défaillances cryptographiques peuvent souvent entraîner des violations de données sensibles, ainsi que d'autres types de compromission du système. Les violations notables dans la mémoire récente incluent la violation de données de la Croix-Rouge de janvier 2022.

Le but est de les rendre extrêmement difficiles à produire en premier lieu. Cela nécessite une conception appropriée, un code sécurisé, des tests cohérents et une sécurité d'intégration dans votre flux de travail.

Désormais en troisième position, cette catégorie comprend les scripts intersites, qui étaient auparavant son propre élément classé n ° 7 dans le Top 10 de l'OWASP.

Que sont les problèmes d'injection ?

Une injection se produit lorsqu'un attaquant envoie des données spécialement conçues pour forcer l'application à exécuter des commandes qu'elle n'est pas censée exécuter. Par exemple, une injection SQL peut potentiellement extraire des données inattendues, voire une base de données entière, ou même modifier ou supprimer des données.

Quel est l'impact des problèmes d'injection ?

Pendant de nombreuses années, c'était le problème n°1 selon l'OWASP. Cela reste important et trop courant. En effet, parmi les applications testées, l'OWASP a relevé 274,000 XNUMX occurrences d'injection. Cependant, les problèmes d'injection sont également hautement évitables.

Éviter les attaques par injection signifie examiner de près ce que vous avez pu faire de mal. Cela va de la non-validation des données fournies par l'utilisateur aux données hostiles utilisées dans les paramètres de recherche de mappage objet-relationnel (ORM) qui permettent l'extraction d'enregistrements sensibles.

Les plus grands types d'attaques par injection à surveiller incluent :

1. CWE-79 : Script intersite
2. CWE-89 : Injection SQL
3. CWE-73 : contrôle externe du nom ou du chemin d'accès au fichier

Cette nouvelle catégorie s'articule autour des risques inhérents aux défauts de conception. L'OWASP a développé cette catégorie à la suite de la méthodologie de décalage vers la gauche qui nécessite l'intégration de tests de sécurité et de modélisation des menaces dans les flux de travail et l'architecture. En plus de commencer les tests de sécurité plus tôt, il est important d'examiner le code. Signalez tout ce qui ne peut pas être bien sécurisé en faveur d'une conception plus sécurisée.

Qu'est-ce que la conception non sécurisée ?

La conception non sécurisée implique que les équipes de développement et de test ne parviennent pas à anticiper les menaces lors du développement du code. L'évaluation des menaces et le respect des meilleures pratiques de sécurité affectent également la sécurité de la conception. Cette catégorie est différente de la mise en œuvre non sécurisée en ce sens qu'elle a davantage à voir avec les risques liés aux défauts de conception et d'architecture.

Une implémentation sécurisée peut avoir une conception non sécurisée qui rend toujours une application Web vulnérable aux attaques et aux exploits. La conception non sécurisée est une vaste catégorie représentant différentes faiblesses exprimées comme une conception de contrôle manquante ou inefficace.

Quel est l'impact de la conception non sécurisée ?

Dans le monde du développement d'aujourd'hui, la conception non sécurisée est plus courante que vous ne le pensez. C'est pourquoi DevSecOps, qui intègre la sécurité dans le cycle de vie du développement, est désormais crucial. En d'autres termes, vous ne pouvez pas simplement tester votre façon de sécuriser les logiciels. Vous devez commencer à créer des logiciels plus sécurisés.

Voici quelques exemples de scénarios d'attaque qui exploitent une conception non sécurisée.

• Messages d'erreur verbeux conduisant à un chemin transversal.
• Une implémentation sécurisée peut avoir une conception non sécurisée qui rend une application Web vulnérable aux attaques et aux exploits.
• Une conception non sécurisée a empêché les utilisateurs de PC et les joueurs d'acheter de nouveaux GPU Nvidia aux prix de détail recommandés lors d'un récent incident réel.

Maintenant en position #5 de #6 dans le Top 10 précédent, la mauvaise configuration de la sécurité inclut les entités externes XML (XEE). La nature de plus en plus configurable des logiciels a contribué à la place de cette catégorie sur cette liste. Un exemple notable de mauvaise configuration récente a été la panne NOTAM de la FAA en 2023 - preuve de la gravité du problème.

Qu'est-ce qu'une mauvaise configuration de sécurité ?

Cette catégorie comprend les implémentations non sécurisées dues à une certaine forme de mauvaise configuration. Considérez-le comme lorsqu'un paramètre de sécurité vital est configuré de manière incorrecte ou pas du tout. Un exemple simple de cela est de ne pas réinitialiser le mot de passe par défaut. Ces oublis et erreurs créent des failles de sécurité pour les attaquants potentiels, en particulier avec le déploiement piloté par conteneur qui présente de nombreuses possibilités de mauvaise configuration.

Quelle est la fréquence des erreurs de configuration de la sécurité ?

Des exemples de mauvaise configuration de la sécurité sont des éléments tels que des logiciels obsolètes, un renforcement de la sécurité manquant, des fonctionnalités inutiles et des comptes par défaut avec des mots de passe inchangés. Beaucoup de choses peuvent être facilement négligées, c'est pourquoi l'OWASP recommande un processus de configuration de sécurité reproductible pour atténuer les risques. A quoi cela ressemble-t-il? Dans la mesure du possible, les fichiers de configuration doivent faire partie du contrôle de version et être inclus dans les révisions par les pairs.

Cette catégorie s'appelait auparavant "Utilisation de composants avec des vulnérabilités connues" à la neuvième place du précédent Top 10 de l'OWASP. L'OWASP admet que cela est difficile à tester sans vulnérabilité et exposition communes (CVE), y compris les CWE. Cependant, il s'est classé deuxième dans l'enquête de la communauté OWASP grâce à de gros incidents fréquemment dans l'actualité tels que ceux impliquant Log4j et SolarWinds.

Que sont les composants vulnérables et obsolètes ?

L'utilisation de composants que vous ne connaissez pas ou de composants avec des dépendances imbriquées peut entraîner des risques. D'autres exemples incluent des logiciels non pris en charge, vulnérables ou obsolètes tels que des bibliothèques tierces, d'anciennes versions de sources ouvertes, etc.

L'analyse régulière des vulnérabilités, la suppression des fonctionnalités inutilisées ou inutiles et la mise à jour des logiciels peuvent aider à atténuer les risques associés aux composants vulnérables et obsolètes.

Quel est l'impact des composants vulnérables et obsolètes ?

De nombreux outils et attaques tirent parti de ces problèmes connus. S'assurer que vous êtes à jour avec les correctifs et les versions vous aide à protéger l'application contre ces attaques.

À titre d'exemple, Log4j a subi une vulnérabilité zero-day qui a affecté Cloudflare, Steam, iCloud, Twitter, Tencent QQ et l'édition Java de Minecraft en 2021.

Connue auparavant sous le nom d'"authentification brisée", cette catégorie tombe à la 7e place de la 2e position dans le Top 10 précédent. Elle comprend également les CWE plus étroitement liés aux échecs d'identification. Les risques de sécurité associés à cette catégorie sont atténués par l'adoption d'un cadre standardisé qui permet de mieux contrôler les problèmes d'identification/d'authentification.

Que sont les échecs d'identification et d'authentification ?

Les échecs d'identification et d'authentification de base se produisent lorsqu'une application n'identifie pas ou ne sécurise pas correctement les informations d'identification, l'identité ou les autorisations de connexion d'un utilisateur ou ne parvient pas à maintenir les contrôles d'identification tout au long de la session d'un utilisateur. Les vulnérabilités se produisent lorsqu'un système utilise du texte brut ou des informations d'identification faiblement hachées, a des méthodes de récupération d'informations d'identification faibles ou n'invalide pas les ID de session, par exemple.

Quel est l'impact des échecs d'identification et d'authentification ?

Étant donné que cette catégorie comprend les activités courantes des utilisateurs telles que la connexion aux applications et les sessions utilisateur sur les sites Web, ces risques sont souvent parmi les plus couramment rencontrés. Une tactique connue sous le nom de "credential stuffing" utilise ce type d'attaques pour exploiter tous les mots de passe obtenus lors de fuites.

Des fonctionnalités telles que l'authentification multifacteur et des vérifications de mot de passe plus robustes peuvent aider à atténuer les risques.

Cette nouvelle catégorie s'articule autour d'hypothèses sur le code et l'infrastructure faites en relation avec les données critiques, les mises à jour logicielles et les pipelines CI/CD qui ne vérifient pas l'intégrité. Il inclut le sujet de 2017 « Désérialisation non sécurisée ».

Que sont les échecs d'intégrité des logiciels et des données ?

Les défaillances d'intégrité des logiciels et des données incluent des problèmes tels que des parties non sécurisées d'un pipeline CI/CD ou même des réseaux de diffusion de contenu (CDN). Par exemple, une application peut inclure une fonction de mise à jour automatique qui modifie le code. Cela présente des opportunités pour les attaquants d'obtenir un accès non autorisé et d'utiliser leur propre code malveillant.

Quel est l'impact des défaillances des logiciels et de l'intégrité des données ?

Étant donné que ces problèmes impliquent une infrastructure et un code sans protection contre les violations d'intégrité, les experts en sécurité s'attendent à une augmentation de ces types de violations. Les éléments tels que les routeurs domestiques et le micrologiciel de l'appareil ne nécessitent pas de micrologiciel signé pour être mis à jour. Cette vulnérabilité nécessiterait des correctifs dans une future version.

La désérialisation non sécurisée est également une préoccupation importante. C'est une opportunité courante pour les attaques DoS. Cela se produit lorsque des données contrôlables par l'utilisateur sont désérialisées par un site Web. La désérialisation non sécurisée peut permettre à un attaquant de manipuler des objets sérialisés pour transmettre des données nuisibles dans le code de l'application.

Les échecs de journalisation et de surveillance de la sécurité étaient autrefois appelés «journalisation et surveillance insuffisantes» et apparaissaient également fréquemment dans l'enquête de la communauté OWASP. Bien que difficiles à tester, ces types de défaillances peuvent affecter considérablement divers aspects tels que la criminalistique, l'alerte d'incident et la visibilité.

La journalisation aide à déclencher la surveillance et la réponse ; s'il est incorrect, la posture de sécurité tombe en panne. La visibilité aide les équipes de développement à mieux résoudre les problèmes plus tôt.

Que sont les échecs de journalisation et de surveillance de la sécurité ?

Ce type d'échec implique de ne pas identifier et/ou de ne pas répondre aux menaces potentielles ou aux tentatives hostiles contre les systèmes. Un exemple classique et fréquent de ceci est les échecs de connexion répétés en raison d'un mot de passe incorrect.

Les échecs de journalisation et de surveillance de la sécurité peuvent avoir des impacts significatifs sur une organisation, notamment un manque de visibilité sur les incidents de sécurité. Sans une journalisation et une surveillance appropriées, il peut être difficile de détecter et de répondre aux incidents de sécurité en temps opportun.

De nombreuses réglementations, telles que HIPAA et PCI-DSS, obligent les organisations à conserver des journaux détaillés de leurs activités de sécurité. Ne pas le faire peut entraîner une non-conformité et des amendes. De plus, sans mécanismes de journalisation et de surveillance appropriés, il est beaucoup plus difficile pour les organisations de détecter et d'atténuer les violations, ce qui leur coûte du temps et de l'argent.

Les échecs de journalisation et de surveillance de la sécurité peuvent également entraîner d'autres problèmes. Plus particulièrement, ils peuvent déclencher un contrôle d'accès interrompu - l'élément n ° 1 sur la liste des 2021 meilleurs OWASP 10. L'établissement de stratégies SAST et DAST robustes et complètes peut aider à atténuer ces défaillances.

Quel est l'impact des échecs de journalisation et de surveillance de la sécurité ?

Bien que les échecs de journalisation et de surveillance de la sécurité se produisent en eux-mêmes, ils peuvent également entraîner d'autres problèmes. Plus particulièrement, ils peuvent déclencher un contrôle d'accès interrompu - l'élément n ° 1 sur la liste des 2021 meilleurs OWASP 10. L'établissement de stratégies SAST et DAST robustes peut aider à atténuer ces défaillances.

Malgré le faible taux d'incidents dans les données de l'OWASP, la gravité de l'impact est élevée. Les sondages communautaires montrent qu'il s'agit du premier sujet de préoccupation. Ces types d'attaques sont faciles à exécuter avec succès et peuvent produire des effets particulièrement désagréables.

Qu'est-ce que la contrefaçon de requête côté serveur ?

Ces failles se produisent généralement lorsque les applications Web récupèrent des ressources distantes, mais ne valident pas les URL fournies par l'utilisateur. Les attaquants peuvent alors forcer l'application à se comporter différemment, même lorsqu'elle est protégée par un VPN ou un pare-feu.

Un exemple de ceci serait un attaquant créant sa propre page Web hébergée sur son propre serveur et l'utilisant pour modifier le comportement d'une application. En fait, de nombreux routeurs grand public plus anciens ont exactement ce problème : vous pouvez modifier le mot de passe sans authentification en créant votre propre page Web et en soumettant un nouveau mot de passe.

L'OWASP et les développeurs ont constaté une augmentation de la falsification des demandes côté serveur pour les raisons suivantes :

• Augmentation du taux de récupération d'URL
• Adoption plus large des services cloud
• Complexité architecturale