Décoder le spectre des menaces : Une vue d'ensemble des 10 principaux risques de sécurité des applications Web de l'OWASP

Le paysage de la cybersécurité évolue sans cesse et des menaces de plus en plus sophistiquées pèsent sur les applications web. Pour aider les entreprises à faire un pas vers un code plus sûr et une culture de développement logiciel responsable, l'Open Web Application Security Project (OWASP) publie depuis 2003 le Top 10 de l'OWASP, une liste des risques de sécurité les plus critiques et les plus courants.

Cet article couvre l'édition 2021, la dernière version du document de sensibilisation standard qui met en lumière le paysage des menaces en constante évolution et fixe le niveau minimum des pratiques de développement sécurisé.

Contrôle d'accès défaillants (A01)

Le contrôle d'accès défaillant occupe la première place du Top 10 de l'OWASP en tant que vulnérabilité la plus fréquente dans 94 % des applications testées, alors qu'il occupait la cinquième place dans l'édition précédente.

Cette catégorie se concentre sur les vulnérabilités liées à des mécanismes de contrôle d'accès défectueux qui permettent aux attaquants d'accéder, de modifier ou de détruire des données ou des fonctionnalités sensibles. Ce risque étant le plus courant, il requiert la plus grande attention de la part des développeurs et des professionnels de la sécurité.

Pour éviter les problèmes de contrôle d'accès, il faut s'assurer que l'attaquant ne peut pas modifier le contrôle d'accès ou les métadonnées. Mettez en œuvre des mécanismes de contrôle d'accès dans un code de confiance côté serveur ou dans une API sans serveur, limitez les taux et refusez l'accès par défaut, et testez l'unité de contrôle d'accès fonctionnelle et l'intégration.

Défaillances cryptographiques (A02)

Précédemment connue sous le nom d'exposition de données sensibles, la catégorie des défaillances cryptographiques a également progressé dans la liste et a atteint la deuxième position. Cette catégorie comprend les défaillances liées à la cryptographie : algorithmes de cryptage faibles, mauvaise gestion des clés de cryptage, certificats non valides ou absence pure et simple de cryptage, entraînant l'exposition de données sensibles ou la compromission du système.

Une mise en œuvre et une gestion correctes des algorithmes et des clés cryptographiques sont essentielles pour garantir la confidentialité et l'intégrité des données. D'autres mesures peuvent être prises :

• Désactiver l'encaissement des données sensibles et nettoyer régulièrement les données inutiles.
• Utiliser des protocoles sécurisés.
• Éviter les fonctions cryptographiques obsolètes.
• Vérifier l'efficacité de la configuration et des paramètres de manière indépendante.

Injection (A03)

L'injection reste une menace importante, avec 33 dénombrements de faiblesses communes (Common Weakness Enumerations, CWE) classés dans cette catégorie et ayant la deuxième occurrence la plus importante dans les applications, y compris des vulnérabilités telles que l'injection SQL et le Cross-Site Scripting (XSS).

Les applications sont vulnérables aux injections lorsqu'elles ne valident pas, ne filtrent pas ou n'assainissent pas les données saisies par l'utilisateur. Cela permet aux attaquants d'injecter des données malveillantes dans des requêtes ou des commandes pour voler, modifier ou supprimer des données.

Les développeurs doivent examiner le code source avec diligence, ainsi que tester, assainir et valider les données d'entrée des utilisateurs pour prévenir les attaques par injection. Les outils de test statique (SAST), dynamique (DAST) et interactif (IAST) de la sécurité des applications dans le pipeline CI/CD permettent d'identifier les failles d'injection avant le déploiement en production.

Conception non sécurisée (A04)

Cette catégorie, introduite pour la première fois, englobe les risques liés non pas à une mauvaise mise en œuvre qui peut être corrigée, mais à une conception de contrôle médiocre ou manquante qui ne comporte pas de contrôles de sécurité pour se défendre contre les attaques, ce qui rend l'application fondamentalement vulnérable.

Parmi les CWE de cette catégorie, citons le CWE-209 : Génération d'un message d'erreur contenant des informations sensibles, CWE-256 : Stockage non protégé d'informations d'identification, et CWE-522 : Informations d'identification insuffisamment protégées.

L'OWASP préconise le respect des principes "Secure by Design" et une analyse des risques plus poussée avant le codage :

• Déterminer le niveau de sécurité requis.
• Modélisation des menaces et des modèles de conception sécurisés.
• Travailler avec des spécialistes de la sécurité tout au long du projet.

Mauvaise configuration de la sécurité (A05)

Alors que les logiciels hautement configurables gagnent en popularité, les vulnérabilités liées à la mauvaise configuration de la sécurité des applications web, des serveurs, des bases de données et des environnements en nuage ont gagné une place dans le classement.

Parmi les exemples de mauvaise configuration, on peut citer les autorisations mal configurées, les fonctionnalités inutiles, les mauvais paramètres de sécurité, les logiciels obsolètes, etc.

De telles erreurs de configuration peuvent entraîner de graves failles de sécurité, et les développeurs doivent donner la priorité à ce domaine en installant les processus de manière sécurisée, en supprimant les fonctionnalités et les cadres inutilisés, et en examinant, en mettant à jour et en vérifiant les configurations, les autorisations et les paramètres dans tous les environnements.

Composants vulnérables et obsolètes (A06)

Précédemment intitulée "Utilisation de composants présentant des vulnérabilités connues", cette catégorie était la deuxième dans l'enquête Top 10 de la communauté. Elle découle de la méconnaissance des versions des composants et dépendances utilisés et de leur compatibilité, de l'utilisation de logiciels non pris en charge ou obsolètes, et du fait que les vulnérabilités ne sont pas analysées et corrigées en temps voulu.

Bien qu'il soit évident de savoir comment répondre à ces risques, l'organisation de cette réponse reste un défi. La proactivité et un plan de gestion de l'inventaire pour la surveillance, le triage et la mise à jour ou la reconfiguration en cours pour la durée de vie de l'application peuvent aider les entreprises à garder le contrôle de l'état de leurs logiciels.

Défauts d'identification et d'authentification (A07)

La catégorie des défaillances d'identification et d'authentification, anciennement connue sous le nom d'authentification défaillante, concerne les défaillances d'identification et les tentatives d'accès non autorisé.

Les vulnérabilités courantes en matière d'authentification sont les suivantes:

• Permettre le bourrage automatisé d'informations d'identification et les attaques par force brute.
• Mots de passe faibles.
• Stockage de mots de passe non cryptés.
• Ne pas tenir compte de l'authentification multifactorielle.
• Ne pas terminer une session après une déconnexion ou une inactivité.

Pour protéger une application contre les échecs d'identification et d'authentification, il convient de confirmer l'identité de l'utilisateur, de mettre en œuvre l'authentification multifactorielle et une politique stricte en matière de mots de passe, de limiter les tentatives de connexion, d'alerter le système en cas d'attaques par force brute et de gérer les sessions de manière sécurisée.

Défauts d'intégrité des logiciels et des données (A08)

Un nouvel ajout au Top 10, les défaillances de l'intégrité des logiciels et des données, se concentre sur les vulnérabilités découlant de l'utilisation de mises à jour logicielles, de données critiques et de pipelines CI/CD sans vérification de leur intégrité. Par exemple, le téléchargement de plugins ou de bibliothèques à partir de sources non fiables, l'absence de vérification de l'intégrité des mises à jour automatiques de logiciels tiers ou l'existence d'un pipeline CI/CD non sécurisé auquel un pirate peut accéder.

Il est essentiel de garantir l'intégrité des logiciels et des données pour empêcher les modifications non autorisées et maintenir la sécurité de l'application. Pour ce faire, il convient de vérifier les signatures des logiciels, de ne télécharger du code qu'à partir de référentiels fiables, d'utiliser un outil de sécurité de la chaîne d'approvisionnement des logiciels, par exemple OWASP Dependency Check ou OWASP CycloneDX, pour vérifier les vulnérabilités connues des composants, et d'employer un processus de révision pour toutes les modifications du code et de la configuration.

Défauts de journalisation et de contrôle de la sécurité (A09)

Anciennement connue sous le nom de Logging & Monitoring Insufficient, la catégorie Security Logging and Monitoring Failures explore le rôle préjudiciable d'un logging et d'un monitoring insuffisants ou inadéquats dans la détection et la réponse aux violations.

Les défaillances se produisent lorsque les événements ne sont pas enregistrés ou surveillés, sont stockés de manière incorrecte ou font l'objet de fuites, et qu'aucune analyse automatique, alerte en temps réel ou processus d'escalade n'est en place. Depuis 2021, cette catégorie comprend les défaillances en matière de visibilité, d'alerte en cas d'incident et d'analyse médico-légale.

Le test des problèmes de journalisation et de surveillance n'est pas trivial et nécessite souvent des entretiens avec des pentesters et des ingénieurs en sécurité. Les développeurs devraient adopter un plan de réponse aux incidents et de récupération et mettre en œuvre des pratiques robustes de journalisation et de surveillance afin de détecter les incidents de sécurité et d'y répondre rapidement.

Falsification des requêtes côté serveur (A10)

Les taux d'incidence de la falsification des requêtes côté serveur (SSRF) sont relativement faibles. Cependant, l'enquête communautaire l'a placé en première position en raison de son potentiel d'exploitation et d'impact.

Il se produit lorsqu'une application web recherche une ressource distante sans valider la requête fournie par l'utilisateur. Cela permet à un attaquant de créer une requête qui oblige l'application à envoyer des données à l'URL de son choix.

Les développeurs peuvent empêcher le SSRF grâce à des contrôles de défense approfondis :

• Séparer les ressources distantes et appliquer les règles de contrôle d'accès au réseau et au pare-feu "refuser par défaut".
• Assainissement et validation de toutes les données d'entrée fournies par l'utilisateur, désactivation des redirections et mise sur liste blanche des URL.
• Utiliser le chiffrement du réseau (par exemple, VPN) sur les systèmes indépendants.

Renforcer la sécurité des applications web avec des tests de pénétration

Si la compréhension des 10 principales menaces de l'OWASP est une étape cruciale pour assurer la sécurité des applications web, les organisations doivent compléter ces connaissances par des mesures proactives telles que les tests de pénétration.

Les services de test de pénétration font appel à des professionnels certifiés de la cybersécurité ou à des équipes spécialisées qui simulent des cyberattaques réelles contre le système cible. Souvent appelés "hackers éthiques", ils exploitent les faiblesses de l'architecture, de la configuration ou du code de l'application afin d'identifier et de corriger les vulnérabilités des applications web et des infrastructures de réseau.

Il est important de noter que les tests de pénétration ne sont pas une activité ponctuelle. Étant donné que le paysage des menaces évolue et que les applications changent au fil du temps, il est essentiel de procéder régulièrement à des tests pour maintenir un niveau de sécurité élevé. En outre, la combinaison des tests d'intrusion avec d'autres évaluations de la sécurité, telles que l'analyse des vulnérabilités et l'examen du code, permet de créer une stratégie de sécurité complète.

Les organisations qui procèdent à des évaluations régulières de la sécurité peuvent garder une longueur d'avance sur les cybermenaces potentielles et garantir la sécurité et l'intégrité de leurs applications web et de leurs données.

Élever le niveau de connaissance : Conférences OWASP Global AppSec

L'Open Web Application Security Project (OWASP) organise également des conférences Global AppSec, qui comptent parmi les événements les plus importants de la communauté de la cybersécurité.

Si vous souhaitez rejoindre des professionnels qui partageront leurs connaissances, leurs meilleures pratiques et leurs idées sur la sécurité des applications web, consultez les prochaines conférences OWASP Global AppSec de l'automne :

• OWASP Global AppSec Singapore 2023, les 4 et 5 octobre 2023, à Singapour.
• OWASP Global AppSec Washington DC 2023 du 30 octobre au 3 novembre 2023 à Washington DC, USA.