Ce que vous pensez savoir sur le Top 10 de l'OWASP peut être erroné – Bien choisir son serveur d impression

Le projet de sécurité des applications Web ouvertes (OWASP) est une communauté ouverte dédiée à la mission de permettre aux entreprises de développer, d’acquérir et de gérer des applications et des API fiables. Depuis 2003, OWASP publie une liste des 10 risques de sécurité des applications les plus répandus toutes les quelques années.

Malheureusement, l’utilisation du protocole OWASP en tant que norme de l’industrie en amène beaucoup à en abuser et à ne pas comprendre ce qu’OWASP fait ou ne fait pas. Laissez-moi expliquer.

Vulnérabilités vs Risques

L'objectif du Top 10 de l'OWASP est de sensibiliser les utilisateurs aux exploits les plus courants utilisés par les pirates pour infiltrer et compromettre des données dans des applications Web. En conséquence, il est devenu une norme industrielle non officielle qui guide et dirige l'approche de sécurité de nombreuses entreprises aujourd'hui et sert de base à de nombreux mécanismes de notation des produits de test de vulnérabilité.

Même s'il est utilisé dans l'évaluation des produits de sécurité, le Top 10 de OWASP répertorie les risques de sécurité les plus critiques et ne constitue pas un système de classification des vulnérabilités. Le risque XSS (A-7 dans OWASP 2017) en est une bonne illustration. Il peut être exploité par différentes vulnérabilités, non seulement par les vulnérabilités XSS (Cross-Site Scripting), mais également par les vulnérabilités de type Response Splitting (ou CRLF-injection) et bien d'autres. Le fait que OWASP utilise les mêmes noms pour les risques en tant que catégories communes de vulnérabilités est source de confusion.

Existe-t-il un meilleur système alternatif de classification des vulnérabilités? Malheureusement, il n’existe pas de système à la fois complet et universellement accepté par l’industrie. La tentative la plus prometteuse d’un système de classification et d’évaluation est le CWE (Common Weakness Enumeration), mais il reste incomplet et compliqué. CWE se concentre exclusivement sur les applications Web et est conçu pour classer diverses erreurs logicielles, y compris des problèmes de sécurité. WASC est une autre bonne tentative, conçue pour classer les menaces. Bien que complètement obsolète (2010), il reste un outil utile en raison de sa simplicité.

Les types de vulnérabilité et les classes existantes ne sont plus que des balises. Une classification et une ontologie complètes des problèmes de sécurité nous échappent encore. L'absence d'un bon système de classification est l'une des raisons pour lesquelles les attaquants réussissent encore malgré les efforts déployés par le secteur de la sécurité.

Cartographie des chevauchements de risques

Comme le montre le diagramme ci-dessous, non seulement il existe une confusion entre les risques et les vulnérabilités, mais les risques eux-mêmes présentent des chevauchements importants.

Par exemple, il est facile de voir que A6 (Sécurité Configuration incorrecte) est une super-classe de tout. Il est assez évident que vous réalisiez que chaque fois qu’un autre risque est réalisé, le risque A6 est également réalisé. Cela signifie que tous les risques de A1 à A5 et de A7 à A10 sont également couverts par les erreurs de configuration de sécurité A6. Nous pouvons également revendiquer cette zone externe de A6 et tous les autres risques du Top 10 de l’OWASP comme «principaux problèmes de mauvaise configuration de la sécurité autres que l’OWASP» qui devraient être couverts par le processus de sécurité.

Deuxièmement, nous affirmons que tous les problèmes se chevauchent quelque peu avec A9 (problèmes connus). Cela est dû au fait que tout problème mettant en évidence un risque parmi les 10 meilleurs du programme OWASP peut être connu et sera connu après un certain temps. Cette zone externe de l'A9 et tous les autres 10 principaux risques de l'OWASP peuvent être nommés «10 principaux problèmes connus de l'OWASP» et indiquer ce qui devrait être couvert par la gestion des correctifs.

L'authentification (A2) et l'autorisation (A5, également appelé contrôle d'accès) se croisent et A3 (exposition de données sensibles), comme décrit en détail plus loin dans cet article.

Le format XML étant un format de sérialisation des données, A4 (XXE) est complètement inclus dans A8 (sérialisation des données non sécurisée).

Toutes les autres classes n'ont pas d'intersection, à l'exception de A6 et A9, que je qualifie d '«orbites OWASP supérieures et inférieures 10».

Regard en profondeur sur le Top 10 de l'OWASP

Examinons plus en détail tous les 10 meilleurs points.

A1. Les injections

Cela signifie précisément des problèmes d'injection côté serveur. Techniquement, nous pouvons réclamer XSS sous forme d'injections HTML et JavaScript. Mais à ce stade, les auteurs ne mentionnent que les protocoles côté serveur tels que SQL, NoSQL (document / objet, valeurs-clés, graphiques, etc.), LDAP, Bash (aka commandes de système d’exploitation), etc. en théorie, nous pouvons également réclamer tous les bogues d’authentification en tant qu’injections dans certains protocoles d’authentification. Mais ceci est exclu ici.

A2. Authentification brisée

Il s’agit principalement de la gestion des sessions et des mots de passe. C’est un peu étrange de mélanger des attaques de données d’identité, la divulgation d’ID de session dans des URL et le stockage de mots de passe non hachés dans une base de données en un seul risque, mais OK.

A3. Exposition de données sensibles

Dans le document officiel, seuls les cas cryptographiques sont couverts, tels que les mots de passe non hachés (oui, encore une fois, nous les avons déjà comptés comme A2), les protocoles de transport en clair / texte, les erreurs de mise en œuvre des protocoles de cryptage (tels que CA, CNAME, CRL / OCSP vérifie), etc. Maintenant, vous pouvez demander: «Ne serait-il pas préférable d'appeler ces erreurs de cryptage?» Non, car techniquement, vos traces de pile et les erreurs d'application divulguées dans le monde entier sont également exposées à ce risque. Le même risque!

A4. XXE

XML External Entities ou XXE est un nouveau numéro de la liste des 10 meilleurs de 2017. C’est le seul nouveau numéro de cet ensemble qui a été introduit sur la base de preuves directes provenant de la base de données des problèmes de sécurité. Comme nous l'avons mentionné précédemment, les structures de données complexes et les métadonnées prévalent. Outre les protocoles d'API basés sur XML tels que WSDL, SOAP et autres, XML est le langage de choix pour les métadonnées de tout, des films aux conteneurs Docker. De plus, dans les applications uniques, plusieurs interpréteurs XML en chaîne peuvent exister, en fonction du niveau de l’application traitant de la partie des données. Cette capacité potentielle à injecter une entité externe à différents points de la pile d'applications via un interpréteur XML est ce qui rend XXE si dangereux.

C'est l'un de nos problèmes préférés. Les fondateurs de Wallarm ont gagné de l'argent grâce à différents programmes de prime aux insectes en 2011-2015. Il est maintenant mentionné dans OWASP pour la première fois. Bienvenue à la maison!

En fait, XXE n'est pas un bogue, mais une fonctionnalité bien documentée de tout analyseur XML. Oui, c’est vrai, un format de données XML vous permet d’inclure le contenu d’un fichier texte externe dans un document XML. Pour éviter XXE, vous devez initialiser votre analyseur XML de manière sécurisée. Il existe principalement deux options différentes qui devraient être désactivées:

• Entités externes
• Schéma DTD externe

Et le second est vraiment important. Cette vulnérabilité, qui repose sur le schéma de la DTD externe, est à l'origine de nombreux problèmes, même lorsque des entités externes sont désactivées. Néanmoins, le document de l'OWASP ne contient aucun exemple d'exploitation à ce sujet. Veuillez le trouver ci-dessous:

wlrm

La différence est que nous mettons un attribut «SYSTEM» dans une directive «DOCTYPE», pas dans une «ENTITÉ» elle-même. S'il vous plaît soyez prudent et fixez les deux!

A5. Contrôle d'accès cassé

Il s’agit d’une fusion des références d’objet direct non sécurisées et du contrôle d’accès au niveau de fonction manquant du précédent Top 10 de l’OWASP en 2013. Selon le livre blanc, tous les problèmes liés à l’autorisation existent déjà et même davantage. C'est étrange, mais les bogues côté serveur sont ici associés aux bogues côté client tels que la stratégie CORS manquante.

Dans le même temps, de nombreux problèmes tels que /.git / log.txt et d’autres références directes d’objet non sécurisées classiques doivent être classés en A3 (exposition de données sensibles) et en A5. En outre, de nombreux problèmes A2 (authentification brisée) seront également classés en A5. C’est pourquoi j’aimerais dire que, selon moi, l’ensemble des risques identifiés par A5 relève totalement de l’union A2 + A3.

A6. Mauvaise configuration de la sécurité

Tous les mots de passe par défaut, les logiciels non corrigés, les problèmes connus et les erreurs seulement sont ici. Techniquement, cela signifie que tous les autres risques OWASP Top 10 2017 sont également présents. Chaque fois qu'un autre risque OWASP se déclenche, le risque A6 est également déclenché. L'inverse n'est pas vrai. Le simple fait que A6 soit déclenché ne signifie pas nécessairement qu’un autre risque lié au programme OWASP est également déclenché. Rappelez-vous juste ceci.

A7. XSS (Cross-Site Scripting)

Je suis sûr que tout le monde sait ce que c'est. Mais encore une fois, ce risque XSS dans OWASP ne signifie pas nécessairement qu’il existe une vulnérabilité XSS sous les couvertures. Le même risque A7 peut survenir en raison du fractionnement de la réponse (injection CRLF), des domaines génériques décrits dans crossdomain.xml, de l'en-tête Access-Control-Allow-Origin et d'autres. N'oubliez pas que le risque lié à l'OWASP A7 peut être réalisé non seulement par le biais de systèmes XSS stockés (persistants), réfléchis ou basés sur le DOM.

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

Ceci est mon truc préféré. Si vous avez lu la partie précédente de ce message, vous avez peut-être remarqué que j’ai déjà mentionné A4 (Entités externes XML, XXE) comme mon numéro préféré. Vous avez raison, mais j’ai aussi raison en même temps. Le fait que XML soit un format de sérialisation signifie automatiquement que A4 XXE est complètement inclus et couvert par le risque de désérialisation A8 Insecure. Chaque fois que nous pouvons affirmer que le risque A4 s'est produit, cela signifie immédiatement que le risque A8 s'est également produit.

Outre XML, ces dernières années, certains autres formats de données sont devenus populaires grâce aux attaques qu’ils ont provoquées. Rappelons-nous ici le format de sérialisation OGNL, qui a été exploité dans Struts2 et utilisé pour pirater Equifax en septembre 2017. D'autres exemples incluent les exploits de sérialisation Java (jetez un coup d'œil immédiatement à l'outil yso si vous ne l'avez jamais rencontré auparavant) pour JBoss, Jenkins, Liferay, etc., et Ruby marshaller (aka yaml-exploit).

A9. Problèmes connus

C'est un type de risque «Je vous l'avais bien dit» que nous nous souvenons de toujours lorsque quelqu'un nous exploite, bien qu'il s'agisse d'un exploit disponible publiquement et bien connu. De toute évidence, tous les autres types de risques recoupent ce risque. J'appelle ce risque «orbite inférieure», ce qui signifie que tous les autres risques, sauf A6, se situent quelque part dans cette orbite.

A10. Enregistrement et surveillance insuffisants

Il s'agit d'un risque d'ignorance, ce qui signifie que vous ne devez pas seulement disposer d'un système de journalisation et de surveillance, mais également que toutes les alertes doivent être configurées. De mon point de vue, cela signifie que vous avez mis en place un processus de sécurité continu pour atténuer ce risque. À ce stade, je peux vous diriger vers le langage SDL fourni par Microsoft et en particulier vers la dernière phase de réponse, qui décrit à peu près la même chose.

Conclusions

OWASP Top 10 est un projet très utile qui formalise l'expérience de l'industrie et aide la communauté à faire face aux principaux risques de sécurité. Cependant, de nombreux experts en sécurité et des personnes impliquées dans la sécurité ont une perception fausse de ce système de classification des vulnérabilités.

Il est déraisonnable de s'attendre à une protection à 100% contre les 10 risques principaux de l'OWASP car certains risques sont provoqués par des vulnérabilités inconnues et que d'autres groupes de risques ne sont pas officiellement mappés vers des classes de vulnérabilités.

OWASP Les 10 principaux groupes à risque présentent des chevauchements. Comprendre ces chevauchements et la correspondance entre les risques OWASP et les vulnérabilités réelles est extrêmement important pour la mise en place d'une stratégie de sécurité de défense en profondeur englobant toutes les couches, de l'architecture à la réponse aux incidents.