L’Open Web Application Security Project (OWASP) a corrigé une vulnérabilité dans son Enterprise Security API (ESAPI) qui, si elle n’était pas résolue, aurait pu être utilisée de manière abusive pour exécuter des attaques de traversée de chemin.

Le problème, qui impliquait l’interface du validateur ESAPI et avait un indice de gravité de sécurité de 7,5 sur 10, peut être résolu en appliquant la version corrigée 2.3.0.0.

OWASP ESAPI offre une bibliothèque de contrôles de sécurité qui peuvent aider les développeurs de logiciels d’entreprise à écrire un code plus sécurisé. La technologie est conçue pour être intégrée dans des applications (principalement Web) en tant qu’ensemble proactif de mesures de sécurité.

Bien que le composant vulnérable soit difficilement exploitable, une mise à jour est néanmoins recommandée car l’impact potentiel est important, comme l’explique un avis de l’OWASP :

L’implémentation par défaut de Validator.getValidDirectoryPath (chaîne, chaîne, fichier, booléen) peut traiter de manière incorrecte la chaîne d’entrée testée comme un enfant du répertoire parent spécifié. Cela pourrait potentiellement permettre aux vérifications de contournement du flux de contrôle d’être vaincues si une attaque peut spécifier la chaîne entière représentant le chemin « d’entrée ».

Impact limité

Kevin Wall, co-responsable du projet OWASP ESAPI, a déclaré La gorgée quotidienne que « la plupart des applications utilisant ESAPI n’utilisent probablement même pas la méthode affectée », de sorte que l’impact potentiel de la vulnérabilité est spécifique à l’application.

« Avec toutes les vulnérabilités de bibliothèque, il est difficile d’évaluer à quel point une application générique est exposée pour exploiter une vulnérabilité dans une bibliothèque. »

Wall a ajouté : « Même quand ça Validator.getValidDirectoryPath() est utilisé dans une application, cela ne signifie pas pour autant qu’il est exploitable dans votre application elle-même. Il faut vraiment analyser au cas par cas. »

Selon Wall, dans la plupart des cas d’utilisation, l’ESAPI vulnérable serait utilisée conjointement avec un pare-feu d’application Web (WAF) ou un logiciel de détection d’intrusion – des facteurs limitant davantage l’étendue des dommages.

Sur la question de la gravité, le développeur du logiciel a conclu : « Je ne pense pas que ce soit vraiment une vulnérabilité » élevée « , mais c’est ce que nous allons avoir parce que c’est ce que CVSSv3.1 crache. »

Leçons à apprendre

Bien qu’il soit peu probable que la vulnérabilité en jeu soit exploitée, et encore moins susceptible de causer beaucoup de dommages, le bogue offre des leçons aux développeurs de logiciels, selon Wall.

D’une part, les développeurs d’applications utilisant des bibliothèques doivent utiliser un outil d’analyse de la composition logicielle (SCA) et connaître ses limites.

« Certains outils SCA ne trouvent que les vulnérabilités signalées dans les dépendances directes, mais pas dans les dépendances transitives », a expliqué Wall.

« Et si vous décidez de ne pas appliquer de correctif, vous devez effectuer une analyse approfondie pour voir exactement comment la vulnérabilité de certaines bibliothèques affecte votre application et quels types de contrôles d’atténuation vous pouvez mettre en place (par exemple, peut-être un » correctif virtuel « via un WAF) pour réduire le risque.

N’OUBLIEZ PAS DE LIRE La réputation des développeurs NPM pourrait être mise à profit pour légitimer les logiciels malveillants

La faille peut également être instructive pour les développeurs de bibliothèques car elle illustre l’utilité des outils de test de sécurité des applications statiques (SAST).

« Pour les développeurs de bibliothèques, exécutez des outils SAST de quelque sorte que ce soit et examinez les résultats, mais essayez également d’avoir une couverture de test adéquate et effectuez au moins des révisions manuelles du code des » git diffs « lorsque les PR sont soumis mais avant qu’ils ne soient fusionnés », a conseillé Wall. .

Bien que des erreurs de codage commises lors du développement d’ESAPI aient conduit à la faille, il s’agissait d’erreurs compréhensibles, selon Wall.

Il a conclu: « Je pense que l’endroit où l’ESAPI a laissé tomber la balle est qu’il n’y avait pas de test spécifique qui aurait porté cela à notre attention et c’est sur nous, même si je pense que pour notre défense, c’était surtout l’ignorance de tous ceux qui ont précédemment touché ce code qui Fichier.getCanonicalPath() agit différemment lorsqu’une valeur pour un répertoire n’est pas terminée par ‘/’. Je pense que c’est un peu peu intuitif.

CONSEILLÉ Un bogue de sécurité dans VMWare Workspace ONE pourrait permettre l’accès aux réseaux cloud internes