liste des 10 principales vulnérabilités OWASP-vous L’utilisez probablement mal

Quelle est la liste des 10 principales vulnérabilités OWASP?

publiée pour la première fois en 2004 par le projet Open Web Application Security, La désormais célèbre liste OWASP Top 10 des vulnérabilités (incluse au bas de l’article) est probablement la plus proche que la communauté de développement ait jamais connue d’un ensemble de commandements sur la façon de sécuriser leurs produits.,

cette liste représente les menaces les plus pertinentes pour la sécurité logicielle aujourd’hui selon OWASP, au grand dam de beaucoup qui se demandent comment les injections SQL sont encore une préoccupation après toutes ces années. Ils jugent les types de vulnérabilité en fonction de quatre critères:

  1. facilité d’exploitabilité
  2. prévalences
  3. détectabilité
  4. impact commercial

fait intéressant, OWASP déclare qu’ils ne prennent pas réellement en compte dans leur équation la probabilité que les attaquants tentent d’exploiter une certaine vulnérabilité.,

quand il a commencé, les auteurs ont décidé que la meilleure façon de couvrir le plus de terrain était de mettre des vulnérabilités similaires qu’ils croyaient être les plus préoccupantes dans les groupes. Ils ont reconnu que faute de statistiques appropriées, il pouvait toujours y avoir une question sur les vulnérabilités qui étaient nécessairement les principales préoccupations, d’autant plus que cela peut être une question subjective selon le modèle de menace de chaque organisation.

cependant, après de nombreux débats, ils ont proposé leur liste de ce qu’ils croyaient s’adresser au plus large ensemble d’organisations, mais pas dans un ordre particulier.,

avec le temps, la liste des 10 principales vulnérabilités de L’OWASP a été adoptée comme norme pour les meilleures pratiques et les exigences par de nombreuses organisations, établissant une norme dans un sens pour le développement. Un adoptant bien connu de la liste est les normes de traitement des paiements de PCI-DSS.

malheureusement, comme la liste des 10 principales vulnérabilités D’OWASP a atteint un public plus large, ses intentions réelles en tant que guide ont été mal interprétées, blessant les développeurs au lieu d’aider. Alors, comment devrions-nous comprendre le but de cette liste et encourager réellement les développeurs à coder de manière plus sécurisée?,

comprendre les mises à jour de la liste 2017

Au cours des années qui ont suivi, ils ont actualisé et réorganisé les entrées, ajoutant de nouveaux types de vulnérabilités à mesure qu’ils deviennent pertinents, même si d’autres ont été supprimés de la liste. De nouvelles versions ont été publiées en 2010, 2013 et 2017. La nouvelle liste a été dressée après une longue et ardue étude qui a examiné plus de 50 000 applications et analysé quelque 2,3 millions de vulnérabilités.,

Les adeptes réguliers de la liste auront remarqué qu’avec quelques changements dans l’ordre — malgré le fait que les attaques par injection restent au sommet — il y a quelques nouveaux venus dans la version mise à jour 2017 de la famille de vulnérabilités OWASP Top 10.

battre la concurrence pour se frayer un chemin sur le terrain en lançant des redirections et des avants non validés est la question des API non protégées., Son inclusion sur la liste au numéro A10 est probablement le résultat du fait que les développeurs sont tout simplement beaucoup plus dépendants des API qu’auparavant, interagissant avec beaucoup plus de composants et de produits externes qu’auparavant. Venir à L’endroit A7 est une protection contre les attaques insuffisante, ce qui frappe les développeurs de ne pas être assez complet dans l’ajout de protections pour détecter, enregistrer, et bien sûr répondre aux tentatives de nuire à leurs produits.,

l’autre changement majeur ici dans la version 2017 est la combinaison des références d’objet direct non sécurisées D’A4 et du contrôle d’accès au niveau de la fonction manquante D’A7, créant une vulnérabilité unifiée de contrôle d’accès cassé et soulignant la nécessité d’établir correctement des contrôles pour qui peut et ne peut pas accéder,

mauvaise interprétation de la liste des 10 principales vulnérabilités D’OWASP

a force for good, cette liste est malheureusement devenue un outil pour faire honte aux développeurs qui ne suivent pas ses enseignements, utilisé comme un club pour les réprimander de ne pas être parfait en matière de sécurité. Cette approche est contre-productive et manque à la mission D’OWASP d’encourager et d’équiper les développeurs pour coder de manière plus sécurisée. En outre, il ne reconnaît pas les réalisations des scores de développeurs qui poussent des quantités massives de nouveaux logiciels à un rythme jamais vu auparavant.,

dans une récente interview, le président de L’OWASP, Martin Knobloch, a exprimé sa déception quant à l’utilisation de la liste comme une sorte de liste de contrôle pour une dernière exécution avant une publication, servant plus de mécanisme de validation que de guide.

en tant que personne qui croit fermement en une approche de la sécurité décalée à gauche, je suis sans surprise d’accord avec la frustration de Knobloch quant au nombre de personnes qui ont pris la liste des 10 meilleurs de L’OWASP comme un instrument de FUD, et non l’ensemble de principes directeurs qu’il était prévu d’être.,

des approches industrielles difficiles en matière de sécurité

Les stratégies de sécurité organisationnelles qui dépendent de l’attente d’un échec de la part des éléments humains dans la façon dont elles sécurisent les logiciels au profit d’outils brillants sont vouées à l’échec.

ces dernières années, le message de beaucoup trop de fournisseurs, en particulier du côté du réseau, a été que « le périmètre est mort” et que les entreprises doivent rechercher la sécurité en profondeur pour trouver les méchants qui sont déjà à l’intérieur de leur réseau., Beaucoup trop de titres lors de conférences ont essayé de convaincre les CISO que des équipes de pirates d’élite les mitraillent avec des exploits 0-day rares qui les laisseront sans défense à moins qu’ils n’achètent leur produit qui les rendra inexpugnables à ces attaques autrement imparables.

Cette vision de l’état de la sécurité est inutilement fataliste, dégoulinante de battage publicitaire, et manque certains des concepts de base de la façon dont les professionnels de la sécurité devraient penser au risque.,

Une approche globale de la sécurité ne devrait pas prêcher la suppression des développeurs humains du processus, juste pour apporter les outils de sécurité d’un fournisseur à réparer après avoir terminé leur travail. Cela suppose que les développeurs ne peuvent pas faire confiance, est insultant, et ne fait rien pour rendre votre équipe plus forte en matière de sécurité et de gestion des risques.

Qu’est-ce que la liste des vulnérabilités OWASP Top 10 Est et N’est pas

quelques fois par an, il y a le billet de blog obligatoire demandant comment il est possible qu’en 2017 nous parlions encore d’attaques de niveau script kiddie., J’en ai probablement écrit moi-même quelques-uns, pour lesquels je m’excuse.

le Top 10 OWASP n’est pas configuré pour résoudre toutes les attaques du livre, mais pour aider les équipes à éviter les erreurs courantes qui sont beaucoup plus susceptibles d’obtenir leurs applications violées. Un attaquant déterminé peut trouver de nombreuses voies pour atteindre sa cible. Cependant, les avis sur la gestion intelligente des risques ne se concentrent pas sur une minorité de cas, mais cherchent plutôt à aborder les problèmes auxquels est confronté le plus large public.,

pour tirer parti des concepts du domaine de la sécurité physique, le gestionnaire de risque moyen devrait être beaucoup plus inquiet de voir son client tomber dans un accident sur la route que les ninjas formés par SEAL Team 6 qui passent par les fenêtres, guidés par L’IA (et la blockchain).

la sécurité réelle consiste à former les gens sur la façon de travailler en toute sécurité et à leur donner les technologies, les connaissances et les processus pour leur permettre de rester plus facilement en sécurité., Bien qu’il soit toujours important d’exécuter des contrôles D’assurance qualité et de sécurité finaux avant une publication, la sécurité doit commencer dès les premières étapes du fonctionnement de votre équipe, tout au long du processus de développement du produit. Des erreurs se produiront, mais il est beaucoup plus rentable et carrément plus intelligent d’essayer d’éviter autant de problèmes que possible en premier lieu.

pour de nombreux développeurs, l’objectif principal est de faire fonctionner le produit, en se concentrant moins sur la sécurité ou non. Ce n’est pas de leur faute.,

tout au long de leur éducation, ils ont appris que s’ils produisaient un produit avec un minimum de bugs, ils obtenaient un A. La Sécurité serait de toute façon gérée par un autre département. Au lieu de cela, les gestionnaires doivent profiter de l’occasion pour leur montrer une meilleure façon de travailler qui comprend la façon dont ils codent, et les composants avec lesquels ils travaillent, impact sur la sécurité de leur produit.,

OBTENIR 451 RESEARCH, LE la SÉCURISATION de l’OPEN SOURCE LOGICIEL Gratuit de Téléchargement

des Mesures Concrètes Pour Permettre de Meilleures Pratiques en matière de Sécurité

Une erreur fréquemment commise qui sont venus les jours de la cascade de développement était d’attendre jusqu’à la fin du cycle de développement, pour effectuer les contrôles de sécurité, dans lequel les développeurs de recevoir une liste de blanchisserie de failles à corriger, retarder la libération et l’augmentation de la friction entre eux et l’équipe de sécurité.,

dans l’espoir de passer à la vitesse supérieure et de suivre la vitesse du DevOps, les organisations recherchent de nouveaux moyens de sécuriser leur code dès le départ et de maintenir l’harmonie entre leurs services.

une méthode de plus en plus populaire pour introduire la sécurité dans les premières étapes du développement de produits consiste à créer des équipes de pollinisation croisée avec un mélange de développeurs et de spécialistes de la sécurité, permettant à chaque partie de donner son avis et d’apprendre les uns des autres., Cela peut être une excellente occasion pour les experts en sécurité d’évoquer de nombreux problèmes que le Top 10 de L’OWASP tente de résoudre dans un environnement moins conflictuel, à un stade qui pourrait réellement avoir un impact.

en ce qui concerne les outils qui peuvent aider à promouvoir une meilleure mise en œuvre de la sécurité, nous devons réfléchir non seulement à la façon dont la technologie peut détecter nos erreurs ou nos violations après coup, mais aussi nous aider à travailler plus intelligemment et en toute sécurité dès les premières étapes., Cette perspective fait partie intégrante de la mentalité de changement à gauche, à la recherche d’opportunités pour résoudre les problèmes avant qu’ils ne deviennent des problèmes coûteux.

intégrer des Technologies pour augmenter les capacités des développeurs

Un exemple clair de la façon dont les technologies de déplacement vers la gauche peuvent aider les développeurs à utiliser le Top 10 OWASP est livré avec l’entrée numéro 9 qui met en garde contre l’utilisation de composants avec des vulnérabilités connues. L’un des problèmes les plus courants qui se posent dans cet espace est de gagner en visibilité sur ce qui se trouve dans les composants open source qu’ils ont ajoutés à leur produit.,

Les développeurs se tournent presque toujours vers les composants open source pour les aider à construire leur produit plus rapidement et plus efficacement, en ajoutant des fonctionnalités puissantes sans avoir à écrire le nouveau code eux-mêmes.

dans la plupart des cas, il est peu probable qu’ils vérifient si le composant présente des vulnérabilités connues avant de l’ajouter à leur produit. Même s’ils effectuent une vérification rapide pour voir s’il y a des problèmes spécifiques, il est peu probable qu’ils soient au courant de problèmes dans les dépendances du composant.,

cependant, s’ils utilisent un outil D’analyse de Composition logicielle, ils peuvent effectivement recevoir des informations utiles pour savoir si un composant open source a des vulnérabilités connues qui lui sont associées tout au long du cycle de développement logiciel (SDLC), ce qui leur fait gagner du temps qui pourrait autrement être passé à déchirer et à remplacer le composant après une vérification de l’équipe de sécurité plus tard avant la publication après qu’il a été commis à leur code.,

soyez un facilitateur de sécurité au sein de votre organisation

D’après ma lecture du Top 10 OWASP et les commentaires de Knobloch, la liste doit être considérée comme un outil permettant aux équipes d’inclure la sécurité dans leur processus de réflexion sur la façon dont elles codent, configurent et expédient leurs produits.

Les équipes de sécurité qui ne dialoguent pas avec leurs développeurs, faisant l’effort de comprendre comment elles peuvent leur permettre de faire de la sécurité un élément inhérent à leur flux de travail, se retrouveront rapidement mises à l’écart.,

Si vous voulez rester pertinent, devenez un facilitateur et utilisez la liste OWASP Top 10 comme un moyen de démarrer des conversations, pas de menacer. En fin de compte, vous constaterez peut-être que vous attrapez plus de guêpes (O)avec du miel que du vinaigre.

la liste officielle des 10 principales vulnérabilités D’OWASP

A1. Injection-les défauts D’Injection, tels que L’injection SQL, NoSQL, OS et LDAP, se produisent lorsque des données non fiables sont envoyées à un interpréteur dans le cadre d’une commande ou d’une requête. Les données hostiles de l’attaquant peuvent inciter l’interpréteur à exécuter des commandes involontaires ou à accéder aux données sans autorisation appropriée.

A2., Authentification interrompue-les fonctions D’Application liées à l’authentification et à la gestion des sessions sont souvent implémentées de manière incorrecte, ce qui permet aux attaquants de compromettre les mots de passe, les clés ou les jetons de session, ou d’exploiter d’autres failles d’implémentation pour assumer temporairement ou définitivement l’identité d’autres utilisateurs.

A3. Exposition aux données sensibles-de nombreuses applications web et API ne protègent pas correctement les données sensibles, telles que les données financières, les soins de santé et les PII. Les attaquants peuvent voler ou modifier ces données faiblement protégées pour commettre une fraude par carte de crédit, un vol d’identité ou d’autres crimes., Les données sensibles peuvent être compromises sans protection supplémentaire, comme le cryptage au repos ou en transit, et nécessitent des précautions particulières lorsqu’elles sont échangées avec le navigateur.

A4. Entités externes XML (XXE) – de nombreux processeurs XML plus anciens ou mal configurés évaluent les références d’entités externes dans les documents XML. Les entités externes peuvent être utilisées pour divulguer des fichiers internes à l’aide du gestionnaire d’URI de fichier, des partages de fichiers internes, de l’analyse de port interne, de l’exécution de code à distance et des attaques par déni de service.

A5.,Contrôles d’accès brisés-les Restrictions sur ce que les utilisateurs authentifiés sont autorisés à faire ne sont souvent pas correctement appliquées. Les attaquants peuvent exploiter ces failles pour accéder à des fonctionnalités et/ou des données non autorisées, accéder aux comptes d’autres utilisateurs, Afficher des fichiers sensibles, modifier les données d’autres utilisateurs, modifier les droits d’accès, etc.

A6. Erreur de configuration de sécurité – une erreur de configuration de sécurité est le problème le plus fréquemment rencontré., Ceci est généralement le résultat de configurations par défaut non sécurisées, de configurations incomplètes ou ad hoc, de stockage cloud ouvert, d’en-têtes HTTP mal configurés et de messages d’erreur verbeux contenant des informations sensibles. Non seulement tous les systèmes d’exploitation, frameworks, bibliothèques et applications doivent être configurés de manière sécurisée, mais ils doivent également être corrigés/mis à niveau en temps opportun.

A7.,Cross Site Scripting (XXS)-les failles XSS se produisent chaque fois qu’une application inclut des données non fiables dans une nouvelle page web sans validation ni échappement appropriés, ou met à jour une page Web existante avec des données fournies par l’utilisateur à l’aide d’une API de navigateur pouvant créer du HTML ou du JavaScript. XSS permet aux attaquants d’exécuter des scripts dans le navigateur de la victime qui peuvent détourner des sessions utilisateur, défigurer des sites web, ou rediriger l’utilisateur vers des sites malveillants.

A8. Désérialisation non sécurisée-la désérialisation non sécurisée conduit souvent à l’exécution de code à distance., Même si les défauts de désérialisation n’entraînent pas d’exécution de code à distance, ils peuvent être utilisés pour effectuer des attaques, notamment des attaques par relecture, des attaques par injection et des attaques par escalade de privilèges.

A9. Utilisation de composants avec des vulnérabilités connues-les composants, tels que les bibliothèques, les frameworks et autres modules logiciels, s’exécutent avec les mêmes privilèges que l’application. Si un composant vulnérable est exploité, une telle attaque peut faciliter la perte de données grave ou la prise de contrôle du serveur., Les Applications et API utilisant des composants avec des vulnérabilités connues peuvent saper les défenses des applications et permettre diverses attaques et impacts.

A10. Journalisation insuffisante& surveillance – une journalisation et une surveillance insuffisantes, associées à une intégration manquante ou inefficace avec la réponse aux incidents, permettent aux attaquants d’attaquer davantage les systèmes, de maintenir la persistance, de pivoter vers plus de systèmes et de falsifier, extraire ou détruire des données., La plupart des études de violation montrent que le temps nécessaire pour détecter une violation est supérieur à 200 Jours, Généralement détecté par des parties externes plutôt que par des processus ou une surveillance internes.

Leave a Comment