Les 10 principales vulnérabilités OWASP

Les applications natives du cloud, avec leurs architectures distribuées constituées de plusieurs bibliothèques tierces et de services, sont des cibles de choix pour les hackers. Ceux-ci ont bien compris que le code des applications comporte le plus de vulnérabilités (quelque 82 %) et ils cherchent ainsi à exploiter ce vecteur pour compromettre les réseaux sur lesquels l’application est déployée. C’est pourquoi la sécurité des applications web est aujourd’hui une exigence essentielle.

Qu’est-ce que l’OWASP ?

L’Open Web Application Security Project (OWASP) est une communauté à but non lucratif, ouverte à tous, qui œuvre à promouvoir la sécurité des applications sur le web. L’un des principes fondateurs de l’OWASP est que la base de connaissances soit gratuite et facilement accessible sur son site web. Avec des dizaines de milliers de membres et des centaines de chapitres, l’OWASP jouit d’une grande crédibilité. Les développeurs s’y réfèrent pour la sécurisation de leurs applications web et des API.

Tout développeur d’applications, quelle que soit son expérience, doit s’efforcer d’appréhender les vulnérabilités du code afin de prévenir les défaillances dans la sécurité des applications, qui peuvent s’avérer frustrantes et souvent coûteuses.

Qu’est-ce que le TOP 10 de l’OWASP ?

Tous les trois ou quatre ans, l’OWASP révise et publie sa liste des 10 principales vulnérabilités des applications web. Ce classement recense les risques, mais aussi l’impact potentiel de chaque vulnérabilité et les moyens de les éviter. Ce Top 10 a été obtenu en compilant de nombreuses sources spécialisées rédigées par des experts du domaine (consultants, fournisseurs de sécurité, équipes de sécurité d’entreprises et d’organisations de toute taille et de tous les secteurs, etc.). C’est un guide essentiel des meilleures pratiques en matière de sécurité des applications web.

L’OWASP a récemment publié son Top 10 2021. Il comporte trois nouvelles catégories, quatre catégories dont le nom et le périmètre ont changé, ainsi que quelques consolidations.

Ce classement a pour objectif principal de sensibiliser aux risques. Néanmoins, depuis sa première publication en 2003, les entreprises du secteur l’ont utilisé comme une norme AppSec de facto. En examinant attentivement le document, on constate que l’identifiant associé à chaque CWE (Common Weakness Enumeration) est indiqué.

Dernière publication du Top 10 des vulnérabilités et des risques de sécurité liés aux applications web

À l’occasion de son 20 anniversaire, l’OWASP a publié une nouvelle version de sa liste des 10 principales vulnérabilités, le 24 septembre 2021. Vous remarquerez un grand changement par rapport à la liste de 2020 : la catégorie Contrôle d’accès défaillant a supplanté les attaques par injection SQL à la tête du classement.

1. Contrôle d’accès défaillant (Broken Access Control)

2. Défaillances cryptographiques (Cryptographic Failures)

3. Injection

4. Conception non sécurisée (Insecure Design)

5. Mauvaise configuration de la sécurité (Security Misconfiguration)

6. Composants vulnérables et obsolètes (Vulnerable and Outdated Components)

7. Identification et authentification de mauvaise qualité (Identification and Authentication Failures)

8. Manque d’intégrité des données et du logiciel (Software and Data Integrity Failures)

9. Carence des systèmes de contrôle et de journalisation (Security Logging and Monitoring Failures)

10. Falsification de requête côté serveur (Server-Side Request Forgery)

Les 10 principales vulnérabilités OWASP

Nous allons explorer ici chaque risque du classement afin de mieux en comprendre l’impact et savoir comment l’éviter.

1. Contrôle d’accès défaillant

Le contrôle d’accès sécurisé des sites web doit limiter l’accès uniquement aux pages et sections autorisées suivant le profil de l’utilisateur. Prenons l’exemple d’un site d’e-commerce. Les administrateurs de ce dernier doivent pouvoir ajouter de nouveaux liens ou des offres promotionnelles. Les autres utilisateurs qui se connecteront au site ne devront pas être autorisés à utiliser ces fonctionnalités.

Il faut encourager les développeurs à assimiler une ligne de conduite « security first » pour éviter les écueils, tels que les CMS qui génèrent par défaut des autorisations qui donnent tous les accès (parfois même de niveau administrateur). En cas de défaillance du contrôle d’accès, un utilisateur d’un site web pourrait accéder au panneau administrateur, aux serveurs, aux bases de données et à d’autres applications critiques. Dans les faits, cette faille peut même être exploitée pour rediriger les navigateurs vers d’autres URL cibles.

Remédiation

Il existe plusieurs manières de remédier à cette vulnérabilité :

• Adopter une approche du moindre privilège : affecter à chaque rôle le niveau d’accès le plus faible requis pour exécuter ses tâches.

• Supprimer les comptes qui ne sont plus nécessaires ou actifs.

• Surveiller l’activité sur les serveurs et sites web pour savoir qui fait quoi (et quand).

• S’il y a plusieurs points d’accès, désactiver ceux qui ne sont pas nécessaires pour le moment.

• Améliorer au maximum la performance des serveurs en arrêtant les services inutiles.

2. Défaillances cryptographiques

Les données en transit et au repos (telles que les mots de passe, numéros de carte bleue, dossiers médicaux, informations personnelles et secrets commerciaux) requièrent une protection supplémentaire compte tenu des défaillances cryptographiques possibles (et donc à l’exposition de données sensibles). Cela est particulièrement vrai dans le cas où ces données relèvent de dispositifs réglementés comme le RGPD, le CCPA, etc. Les données sont-elles envoyées en clair ? Des protocoles cryptographiques ou algorithmes de chiffrement obsolètes ou peu sécurisés sont-ils utilisés par défaut ou dans du code plus ancien ? Est-il possible que des clés de chiffrement par défaut soient utilisées, que les clés générées soient trop simples ou utilisées plusieurs fois, ou encore qu’il n’y ait pas de système en place pour la gestion et la rotation des clés ? Est-il possible de trouver des clés de chiffrement dans les référentiels du code source ? Le chiffrement est-il forcé, et les données reçues sont-elles chiffrées ?

Remédiation

• Désactiver l’autocomplétion pour les formulaires permettant la collecte de données.

• Réduire/minimiser la taille de la surface de données.

• Chiffrer les données en transit et au repos.

• Utiliser les techniques de chiffrement les plus récentes.

• Désactiver la mise en cache pour les formulaires de collecte de données.

• Utiliser des fonctions de hachage très adaptatives et salées lors de la sauvegarde des mots de passe.

3. Injection

Ce type de vulnérabilité peut apparaître lorsqu’une requête ou une commande est utilisée pour insérer des données non sécurisées dans un interpréteur via une injection SQL, OS, NoSQL ou LDAP. Les données malveillantes injectées via ce vecteur d’attaque « dupent » l’interpréteur qui poussera l’application à un comportement non prévu, comme générer des commandes indésirables ou accéder à des données sans avoir les identifiants nécessaires.

Toute application autorisant des paramètres saisis peut être la cible d’attaques par injection. Le niveau de menace est en grande partie corrélé à la rigueur des mesures de validation de la saisie dans l’application.

Remédiation

Les attaques par injection peuvent être évitées en combinant les approches suivantes :

• Séparer les commandes des données afin de limiter le risque d’attaques remplaçant les données par l’exécution de commandes indésirables.

• Coder les requêtes SQL avec des paramètres plutôt que structurer la commande uniquement sur la base des saisies de l’utilisateur. On parle alors de requêtes paramétrées ou d’instructions préparées.

• Éliminer complètement l’interpréteur via l’utilisation d’une API sécurisée.

• Implémenter une validation positive côté serveur ainsi qu’un système de détection des intrusions qui identifie les comportements suspects côté client.

4. Conception non sécurisée

La « conception non sécurisée » est un terme assez large qui regroupe diverses failles et désigne l’absence ou la faiblesse de la conception des contrôles.  Une utilisation plus fréquente de la modélisation des menaces, des principes de conception sécurisés et des architectures de références est perçue comme nécessaire ; ils font donc l’objet de nouvelles catégories en 2021. En tant que communauté, nous devons dépasser l’approche « shift-left » pour précoder les tâches importantes selon les principes Secure by Design.

Remédiation

• Pour mieux analyser et concevoir des mesures de protection relatives à la sécurité et la confidentialité, il faut établir et appliquer un cycle de développement sécurisé avec l’aide de professionnels AppSec.

• Créer et utiliser une bibliothèque sécurisée prête à l’emploi contenant des composantes ou des principes de conception.

• Utiliser la modélisation des menaces pour les authentifications, le contrôle d’accès, la logique métier et les principaux flux lorsque ceux-ci revêtent une importance cruciale.

• Les scénarios utilisateurs doivent tenir compte des contrôles et du langage de sécurité.

• Intégrer des contrôles de vraisemblance à chaque niveau de votre application (du frontend au backend).

• Pour veiller à prendre en compte tous les flux importants dans la modélisation des menaces, mettre par écrit les tests unitaires et d’intégration. Rédiger une liste des cas d’utilisation et des cas de mauvaise utilisation pour chaque niveau de votre application.

• En fonction du risque et des exigences de protection, subdiviser les niveaux pour les couches système et réseau.

• Limiter la consommation en ressources des services et des utilisateurs.

5. Mauvaise configuration de la sécurité

Gartner estime que jusqu’à 95 % des violations dans le cloud résultent d’erreurs humaines. Les mauvaises configurations de la sécurité en sont en grande partie responsables. L’OWASP souligne que dans son Top 10, cette vulnérabilité est la plus commune. Il existe de nombreux types de mauvaises configurations pouvant exposer une entreprise à un risque de cybersécurité, notamment :

• La validation de paramètres par défaut non sécurisés

• Un accès trop facile aux ressources dans le cloud

• Des configurations incomplètes

• Des en-têtes HTTP mal configurés

• Des messages d’erreur trop détaillés, contenant des informations sensibles

Remédiation

Les mauvaises configurations de la sécurité peuvent toucher pratiquement tous les points de l’environnement, y compris les périphériques réseaux, les bases de données, les serveurs web et d’applications, et les conteneurs. Les pratiques suivantes peuvent participer au maintien d’un environnement sécurisé :

• Pour le déploiement des environnements de développement, de test et de production, utiliser des modèles préconfigurés pour respecter les stratégies de sécurité de l’entreprise.

• Exploiter des architectures segmentées pour l’application, afin de minimiser les risques liés à un élément mal configuré ; tenir à jour une bibliothèque d’images de conteneurs correctement configurées.

• Déployer des plateformes minimales et supprimer les fonctionnalités et services inutilisés.

• Surveiller en permanence les ressources, applications et serveurs cloud en quête de mauvaises configurations de la sécurité et corriger en temps réel les problèmes détectés, si possible par des workflows automatisés.

6. Composants vulnérables et obsolètes

Les applications web distribuées actuelles intègrent souvent des composants open source tels que des bibliothèques ou des frameworks. Tout composant pour lequel une vulnérabilité est connue devient un maillon faible pouvant impacter la sécurité de l’application dans son l’ensemble.

Bien que l’utilisation de composants open source vulnérables se retrouve en bas du classement de l’OWASP en termes de sévérité, elle n’en reste pas moins la cause principale des violations de données effectives en termes de fréquence.

Remédiation

La meilleure défense est d’analyser en continu tous les composants du code pour rechercher les vulnérabilités connues et déployer un patch ou une autre correction aussi rapidement que possible lorsqu’une vulnérabilité est détectée. Plusieurs bonnes pratiques améliorent l’efficacité de cette ligne de défense :

• Tous les composants intégrés dans les frameworks de l’organisation doivent faire l’objet d’une gestion des configurations.

• Le système d’analyse doit être en mesure de détecter automatiquement tous les composants à surveiller.

• L’analyse doit être réalisée en s’appuyant sur une base de données des vulnérabilités alimentée par des informations sur les menaces.

• Les workflows de gestion des correctifs qui servent à identifier, tester et déployer le correctif approprié, doivent être automatisés autant que possible afin de réduire au mieux le risque opérationnel associé à ce processus.

7. Identification et authentification de mauvaise qualité (Identification and Authentication Failures)

Lorsque les applications n’exécutent pas de manière correcte les fonctions liées à la gestion des sessions ou à l’authentification des utilisateurs, des intrus peuvent compromettre les mots de passe, clés de sécurité ou jetons de sessions et usurper, de manière temporaire ou permanente, les identités et donc les autorisations d’autres utilisateurs. Cette vulnérabilité représente une menace de sécurité grave pour l’application et les ressources auxquelles elle accède, et peut également sévèrement compromettre les autres systèmes connectés au même réseau.

Remédiation

Les meilleures pratiques recommandées par l’OWASP pour limiter les risques liés à l’authentification sont :

• Implémenter l’authentification multi facteur.

• Ne procéder à aucun déploiement avec des identifiants par défaut, en particulier pour les utilisateurs avec des privilèges Administrateur.

• Forcer l’utilisation de mots de passe complexes.

• Surveiller attentivement les tentatives de connexion qui ont échoué.

• Utiliser un système de gestion des sessions sécurisé qui génère des ID de session aléatoires et temporaires. Ne jamais faire figurer les ID de session dans les URL.

8. Manque d’intégrité des données et du logiciel

Cette catégorie englobe les codes et infrastructures qui ne sont pas protégés contre les violations d’intégrité. Un bon exemple pourrait être un programme qui utiliserait des plug-ins, des bibliothèques ou des modules issus de sources, référentiels ou réseaux de diffusion de contenu non fiables. Un pipeline CI/CD non sécurisé peut ainsi s’exposer à des accès non autorisés, du code malveillant ou une compromission du système. Enfin, de nombreux programmes actuels ont été conçus avec des mises à jour automatiques qui sont exécutées sans nécessiter de contrôles d’intégrité. Ces mises à jour sont ensuite appliquées à des applications fiables. Les attaquants pourraient potentiellement distribuer et exécuter leurs propres mises à jour via une telle fonctionnalité.

Remédiation

• Utiliser des signatures numériques ou des mesures similaires pour vérifier que le programme ou les données sont authentifiés et que le contenu est intègre.

• Pour réduire les risques d’intégration de configurations ou de code malveillant dans votre pipeline de développement, il faut s’assurer qu’une procédure de révision pour toutes les modifications (code et configuration) est mise en place et suivie.

• Vérifier que les bibliothèques et dépendances, comme npm ou Maven, utilisent des référentiels fiables. Si votre profil est à risque élevé, il faudrait envisager de créer un référentiel interne, vérifié et approuvé.

• Pour protéger l’intégrité du code au fil des compilations et des déploiements, veillez à ce que votre pipeline CI/CD intègre une séparation des droits, une configuration et un contrôle d’accès adéquats.

• S’assurer de ne pas transmettre de données sérialisées non signées ou non chiffrées à des clients non fiables sans contrôle d’intégrité ou signature numérique afin de détecter les altérations et les attaques par rejeu.

9. Carence des systèmes de contrôle et de journalisation (logs)

Selon certaines études, le délai entre une attaque et sa détection peut aller jusqu’à 200 jours, voire plus. Cela laisse largement le temps aux cybercriminels de manipuler les serveurs, corrompre les bases de données, voler des informations confidentielles et diffuser du code malveillant.

Remédiation

Implémenter des logiciels éprouvés d’audit et de connexion pour détecter les activités suspectes et les tentatives d’accès non autorisées. Ainsi, même lorsqu’une attaque détectée échoue, la journalisation et le contrôle deviennent des outils précieux pour analyser la source et le vecteur de l’attaque et ensuite déterminer comment renforcer les stratégies et contrôles de sécurité.

10. Falsification de requête côté serveur

La falsification de requête côté serveur(SSRF) est une faille de sécurité web qui permet à un attaquant de forcer une application côté serveur à envoyer des requêtes HTTP à n’importe quel domaine de son choix.

Lorsqu’une application web récupère une ressource distante sans avoir validé l’URL saisie par l’utilisateur, elle laisse une brèche aux SSRF. Ainsi même si un programme est protégé par un firewall, un VPN ou un autre dispositif sécurisé, un attaquant peut le forcer à envoyer une requête falsifiée à un emplacement indésirable.

Remédiation

• Implémenter une validation de la saisie.

• Utiliser des expressions régulières (RegEx).

• Autoriser uniquement le format d’adresse IP prévu (IPv4 ou IPv6).

• Pour procéder à la comparaison avec la liste blanche, utiliser la valeur de la bibliothèque de méthode/sortie, comme l’adresse IP.

• Valider les noms de domaines entrants.

• Passer en revue la série d’aide-mémoires de l’OWASP.

Quelles sont les autres vulnérabilités qui ne figurent pas au classement de l’OWASP ?

L’OWASP précise très clairement dans sa méthodologie que son Top 10 ne représente, par définition, qu’un sous-ensemble de problèmes de sécurité majeurs, et que les entreprises doivent avoir conscience des autres risques de sécurité.

Vous devez vous tenir informé des dernières vulnérabilités découvertes, comme la vulnérabilité Log4Shell, divulguée en décembre 2021.

Autres vulnérabilités qui ne figurent pas au classement de l’OWASP

Vulnérabilités OWASP : FAQ