Top 10 des vulnérabilités OWASP

Avec leurs architectures distribuées composées de nombreuses bibliothèques et de nombreux services tiers, les applications cloud natives constituent des cibles de choix pour les pirates. Le fait que 82 % des vulnérabilités se trouvent dans le code des applications n’échappe pas aux attaquants, qui cherchent à exploiter ce vecteur pour compromettre les réseaux sur lesquels les applications sont déployées. La sécurisation des applications web est donc devenue un impératif stratégique pour les entreprises.

Qu’est-ce que l’OWASP ?

L’Open Web Application Security Project (OWASP) est une communauté mondiale à but non lucratif qui s’attache à promouvoir la sécurité des applications sur le web. L’un des principes fondamentaux de l’OWASP est de rendre sa base de connaissances librement et facilement accessible sur son site web. Avec ses dizaines de milliers de membres et ses centaines de sections, l’OWASP jouit d’une grande crédibilité. Les développeurs s’appuient sur ses recommandations essentielles en matière de sécurité des applications web et de sécurité des API.

Quel que soit son niveau d’expérience, chaque développeur d’applications doit s’efforcer de comprendre les vulnérabilités de sécurité du code afin d’éviter les défaillances de sécurité des applications, souvent frustrantes et coûteuses. Qu’est-ce que l’OWASP Top 10 ?

Tous les deux ou trois ans, l’OWASP révise et publie sa liste des 10 principales vulnérabilités des applications web. Celle-ci présente non seulement les principales menaces de l’OWASP, mais aussi l’impact potentiel de chaque vulnérabilité et les moyens de l’éviter. Cette liste complète est élaborée à partir de diverses sources expertes, notamment des consultants et des fournisseurs en sécurité, ainsi que des équipes de sécurité d’entreprises et d’organisations de toutes tailles. Elle est reconnue comme un guide essentiel des bonnes pratiques de sécurité des applications web.

L’OWASP a récemment publié l’édition 2021 de l’OWASP Top 10. Elle comprend trois nouvelles catégories, quatre catégories dont le nom et le périmètre ont été modifiés, ainsi que plusieurs regroupements au sein du Top 10.

L’OWASP Top 10 vise principalement à sensibiliser le public. Depuis sa première publication en 2003, les entreprises l’utilisent toutefois comme norme de facto du secteur AppSec. En examinant le document de près, on constate qu’il précise le nombre de CWE (Common Weakness Enumeration) qui lui sont associées.

Dernière liste des 10 principales vulnérabilités OWASP et des risques de sécurité des applications web

La dernière liste OWASP Top 10 a été publiée le 24 septembre 2021, à l’occasion du 20e anniversaire de l’OWASP. Si vous connaissez la liste de 2020, vous remarquerez de nombreux changements dans l’édition 2021 de l’OWASP Top 10 : l’injection SQL a notamment cédé la première place au défaut de contrôle des accès.

1. Défaut de contrôle des accès

2. Défaillances cryptographiques

3. Injection

4. Conception non sécurisée

5. Configuration de sécurité incorrecte

6. Composants vulnérables et obsolètes

7. Défaillances d’identification et d’authentification

8. Défaillances d’intégrité des logiciels et des données

9. Défaillances de journalisation et de surveillance de la sécurité

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

Les 10 principales vulnérabilités OWASP

Dans cette section, nous examinons chacune des 10 principales vulnérabilités OWASP pour mieux comprendre leur impact et savoir comment les éviter.

1. Défaut de contrôle des accès

Les contrôles d’accès d’un site web doivent limiter l’accès des visiteurs aux seules pages ou sections dont ils ont besoin. Par exemple, les administrateurs d’un site de commerce électronique doivent pouvoir ajouter des liens ou des promotions. Ces fonctionnalités ne doivent pas être accessibles aux autres types de visiteurs.

Les développeurs doivent intégrer une approche « la sécurité avant tout » afin d’éviter les pièges, comme les systèmes de gestion de contenu (CMS) qui accordent par défaut tous les droits, y compris ceux d’administrateur. Un défaut de contrôle des accès peut permettre aux visiteurs d’un site web d’accéder aux panneaux d’administration, aux serveurs, aux bases de données et à d’autres applications stratégiques. En fait, cette menace de l’OWASP Top 10 pourrait même servir à rediriger les navigateurs vers d’autres URL ciblées.

Correction des défauts de contrôle des accès

Il existe plusieurs moyens de corriger les vulnérabilités liées aux défauts de contrôle des accès :

• Appliquez le principe du moindre privilège : chaque rôle ne doit disposer que du niveau d’accès minimal nécessaire à l’exécution de ses tâches.

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

• Auditez l’activité sur les serveurs et les sites web afin de savoir qui fait quoi et à quel moment.

• Si plusieurs points d’accès sont disponibles, désactivez ceux qui ne sont pas nécessaires.

• Allégez les serveurs en arrêtant les services superflus.

2. Défaillances cryptographiques

Les données en transit et au repos — mots de passe, numéros de carte bancaire, dossiers médicaux, informations personnelles et secrets commerciaux, par exemple — nécessitent une protection renforcée en raison du risque de défaillances cryptographiques (exposition de données sensibles). C’est particulièrement vrai si les données sont soumises à des lois sur la protection de la vie privée, comme le RGPD, le CCPA ou d’autres réglementations. Certaines données sont-elles transmises en clair ? Des algorithmes ou protocoles cryptographiques obsolètes ou non sécurisés sont-ils utilisés par défaut ou dans du code ancien ? Des clés cryptographiques par défaut sont-elles utilisées, des clés faibles générées puis réutilisées, ou les bonnes pratiques de gestion et de rotation des clés sont-elles négligées ? Des clés cryptographiques risquent-elles d’être intégrées aux dépôts de code source ? Le chiffrement est-il appliqué et les données reçues sont-elles chiffrées ?

Correction des défaillances cryptographiques

• Désactivez la saisie automatique sur les formulaires qui collectent des données.

• Réduisez au minimum la surface d’exposition des données.

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

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

• Désactivez la mise en cache des formulaires qui collectent des données.

• Utilisez des fonctions de hachage robustes, adaptatives et salées pour enregistrer les mots de passe.

3. Injection

Les vulnérabilités d’injection peuvent survenir lorsqu’une requête ou une commande transmet des données non fiables à un interpréteur via une injection SQL, système d’exploitation, NoSQL ou LDAP. Les données malveillantes injectées par ce vecteur d’attaque trompent l’interpréteur et amènent l’application à effectuer des actions pour lesquelles elle n’a pas été conçue, comme générer des commandes inattendues ou accéder à des données sans authentification appropriée.

Toute application qui accepte des paramètres en entrée peut être vulnérable aux attaques par injection. Le niveau de risque dépend fortement de la rigueur des mesures de validation des entrées de l’application.

Correction des vulnérabilités d’injection

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

• Séparez les commandes des données afin d’éviter les attaques qui substituent des données et déclenchent l’exécution de commandes inattendues.

• Écrivez les requêtes SQL avec des paramètres au lieu de construire les commandes à partir des seules entrées utilisateur. On parle alors de requêtes paramétrées ou d’instructions préparées.

• Éliminez complètement l’interpréteur en utilisant une API sécurisée.

• Mettez en place une validation positive côté serveur ainsi qu’un système de détection des intrusions capable de repérer les comportements suspects côté client.

4. Conception non sécurisée

La conception non sécurisée est un terme général qui englobe diverses lacunes. Elle se définit comme une « conception des contrôles absente ou déficiente ». La modélisation des menaces, les modèles de conception sécurisés et les architectures de référence font partie des nouvelles catégories de 2021, qui encouragent un recours accru à ces pratiques. En tant que communauté, nous devons aller au-delà du « shift left » dans le code et intégrer des tâches préalables au codage, essentielles aux principes de sécurité dès la conception.

Correction des problèmes de conception non sécurisée

• Pour analyser et mettre en place des mesures liées à la sécurité et à la confidentialité, établissez et utilisez un cycle de développement sécurisé avec des spécialistes AppSec.

• Créez et utilisez une bibliothèque de modèles ou de composants de conception sécurisés prêts à l’emploi.

• Recourez à la modélisation des menaces pour les principaux flux d’authentification, de contrôle des accès, de logique métier et de gestion des clés.

• Les récits utilisateurs doivent inclure des exigences et des contrôles de sécurité.

• Intégrez des contrôles de plausibilité à chaque niveau de votre application, du frontend au backend.

• Rédigez des tests unitaires et d’intégration pour vérifier que tous les flux importants résistent aux menaces identifiées. Établissez la liste des cas d’utilisation et des cas d’usage abusif pour chaque niveau de votre application.

• Segmentez les couches du système et du réseau en fonction des exigences d’exposition et de protection.

• Limitez la consommation de ressources par les utilisateurs et les services.

5. Configuration de sécurité incorrecte

Selon Gartner, jusqu’à 95 % des violations de sécurité dans le cloud sont dues à des erreurs humaines. Les erreurs de configuration des paramètres de sécurité en sont l’une des principales causes. L’OWASP indique que cette vulnérabilité est la plus fréquente du Top 10. De nombreux types de configuration incorrecte exposent les entreprises à des risques de cybersécurité, notamment :

• L’utilisation de paramètres par défaut non sécurisés

• Des ressources de stockage cloud trop accessibles

• Des configurations incomplètes

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

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

Correction des erreurs de configuration de sécurité

Les erreurs de configuration de sécurité peuvent se produire presque partout dans l’environnement : appareils connectés au réseau, bases de données, serveurs web et applicatifs, ou conteneurs. Les pratiques suivantes peuvent contribuer à maintenir un environnement correctement configuré :

• Utilisez des modèles pour déployer des environnements de développement, de test et de production préconfigurés conformément aux politiques de sécurité de l’organisation.

• Misez sur des architectures applicatives segmentées afin de réduire les risques liés à un élément mal configuré. Maintenez une bibliothèque d’images de conteneurs correctement configurées.

• Déployez des plateformes minimales et supprimez les fonctionnalités et services inutilisés.

• Surveillez en continu les ressources cloud, les applications et les serveurs pour détecter les erreurs de configuration de sécurité et corrigez les problèmes dès leur détection, en automatisant les workflows dans la mesure du possible.

6. Composants vulnérables et obsolètes

Les applications web distribuées modernes intègrent souvent des composants open source, comme des bibliothèques et des frameworks. Tout composant présentant une vulnérabilité connue constitue un maillon faible susceptible de compromettre la sécurité de l’ensemble de l’application.

Bien que l’utilisation de composants open source présentant des vulnérabilités connues soit peu grave parmi les problèmes de sécurité, elle arrive en première position de l’OWASP Top 10 lorsque l’on classe les vulnérabilités selon leur fréquence en tant que cause première d’une violation de données réelle.

Correction des vulnérabilités liées aux composants obsolètes ou vulnérables

La défense la plus efficace consiste à analyser en continu tous les composants du code pour détecter les vulnérabilités connues, puis à déployer un correctif ou une autre solution dès que possible. Plusieurs bonnes pratiques permettent de renforcer cette défense :

• Tous les composants intégrés aux frameworks de l’entreprise doivent être soumis à une gestion de configuration.

• L’outil d’analyse doit pouvoir détecter automatiquement tous les composants à surveiller.

• Les analyses doivent s’appuyer sur une base de données de vulnérabilités complète et enrichie de données de renseignement sur les menaces.

• Les workflows de gestion des correctifs — identification, test et déploiement du correctif adapté — doivent être automatisés autant que possible afin de réduire au minimum les risques opérationnels associés à leur application.

7. Défaillances d’identification et d’authentification

Lorsque les applications exécutent incorrectement des fonctions liées à la gestion des sessions ou à l’authentification des utilisateurs, des intrus peuvent compromettre des mots de passe, des clés de sécurité ou des jetons de session, puis usurper temporairement ou définitivement l’identité et les autorisations d’autres utilisateurs. Cette vulnérabilité constitue une grave menace pour la sécurité de l’application et des ressources auxquelles elle accède. Elle peut également compromettre sérieusement d’autres ressources connectées au même réseau.

Correction des problèmes d’authentification

Voici les principales recommandations de bonnes pratiques de l’OWASP pour limiter les vulnérabilités liées aux défaillances d’authentification :

• Mettez en place l’authentification multifacteur.

• N’effectuez pas de déploiement avec les identifiants par défaut, surtout pour les utilisateurs disposant de privilèges d’administration.

• Imposez l’utilisation de mots de passe robustes.

• Surveillez attentivement les tentatives de connexion échouées.

• Utilisez un gestionnaire de sessions sécurisé qui génère des identifiants aléatoires à durée limitée. N’incluez jamais d’identifiants de session dans les URL.

8. Défaillances d’intégrité des logiciels et des données

Les défaillances de l’intégrité des logiciels et des données désignent le code et l’infrastructure qui ne protègent pas contre les atteintes à l’intégrité. Un programme qui utilise des plug-ins, des bibliothèques ou des modules provenant de sources, de dépôts ou de réseaux de diffusion de contenu (CDN) non fiables en est un exemple. Un pipeline CI/CD non sécurisé peut présenter des risques d’accès non autorisé, de code malveillant ou de compromission du système. Enfin, de nombreux programmes disposent désormais de fonctionnalités de mise à jour automatique qui permettent de récupérer des mises à jour et de les appliquer à des applications auparavant fiables, sans vérification d’intégrité adéquate. Des attaquants pourraient ainsi distribuer et exécuter leurs propres mises à jour sur tous les systèmes concernés.

Corriger les défaillances de l’intégrité des logiciels et des données

• Utilisez des signatures numériques ou d’autres mesures similaires pour garantir l’authenticité du programme ou des données et vérifier qu’ils n’ont pas été altérés.

• Pour réduire le risque d’introduire du code ou une configuration malveillants dans votre pipeline de développement, veillez à mettre en place une procédure de revue des modifications de code et de configuration.

• Vérifiez que les bibliothèques et dépendances, telles que celles de npm ou Maven, utilisent des dépôts de confiance. Si votre profil de risque est élevé, envisagez d’héberger un dépôt interne approuvé contenant des versions réputées sûres.

• Pour protéger l’intégrité du code tout au long des processus de build et de déploiement, veillez à ce que votre pipeline CI/CD comporte une séparation adéquate, une configuration appropriée et des contrôles d’accès.

• Veillez à 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é ni signature numérique permettant de détecter toute modification ou rejeu.

9. Journalisation et surveillance insuffisantes

Des études indiquent que le délai entre une attaque et sa détection peut atteindre 200 jours, voire davantage. Cette période laisse aux cybercriminels tout le temps nécessaire pour manipuler des serveurs, corrompre des bases de données, voler des informations confidentielles et implanter du code malveillant.

Correction

Mettez en œuvre des outils de journalisation et d’audit disponibles sur le marché pour détecter rapidement les activités suspectes et les tentatives d’accès non autorisées. Même si une attaque détectée a échoué, la journalisation et la surveillance sont des outils précieux pour analyser sa source et son vecteur, et déterminer comment renforcer les politiques et les contrôles de sécurité afin d’empêcher les intrusions.

10. Falsification de requêtes côté serveur (SSRF)

La falsification de requêtes côté serveur (également appelée SSRF) est une faille de sécurité web qui permet à un attaquant de contraindre une application côté serveur à envoyer des requêtes HTTP vers le domaine de son choix.

Une faille SSRF se produit lorsqu’une application web récupère une ressource distante sans valider l’URL fournie par l’utilisateur. Même si le programme est protégé par un pare-feu, un VPN ou un autre type de liste de contrôle d’accès réseau, un attaquant peut le contraindre à envoyer une requête falsifiée vers une destination inattendue.

Correction

• Validez les entrées.

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

• N’acceptez que le format d’adresse IP prévu (IPv4 ou IPv6).

• Pour effectuer la comparaison avec la liste d’autorisation, utilisez comme adresse IP la valeur renvoyée par la méthode ou la bibliothèque.

• Validez les noms de domaine entrants.

• Consultez la collection de fiches pratiques de l’OWASP.

Quelles sont les autres vulnérabilités non répertoriées par l’OWASP ?

L’OWASP précise clairement dans sa méthodologie que la liste Top 10 ne représente, par définition, qu’un sous-ensemble des problèmes de sécurité importants et que les organisations doivent également connaître les autres risques de sécurité.

Vous devez rester informé des nouvelles vulnérabilités zero-day découvertes dans la nature et prévoir un plan d’intervention pour y faire face lorsqu’elles surviennent.

Graphique d’autres vulnérabilités hors OWASP

Vulnérabilités OWASP : FAQ