OWASP Top 10 : les plus grosses failles de sécurité des applications web

L’OWASP, acronyme de l’Open Web Application Security Project, est une organisation à but non lucratif qui publie environ tous les 3 ans une liste actualisée des 10 failles de sécurité les plus courantes et sérieuses pesant sur les applications web.

Ce top 10 des failles de sécurité, dressé et affiné depuis 2003 par des experts en sécurité du monde entier, est en libre accès.

Reconnaître – et corriger – les failles de sécurité grâce au top 10 de l’OWASP

Ce classement n’est cependant pas seulement à prendre comme une indication qui pointe sur les 10 risques les plus importants qui pèsent sur les applications web. Mais il comprend aussi des recommandations et bonnes pratiques qui permettent de refermer ces failles de sécurité.

C’est pourquoi le top 10 de l’OWASP s’adresse avant tout aux développeuses et développeurs web pour les sensibiliser aux potentielles failles de leurs applications. Le top 10 de l’OWASP doit permettre d’éviter d’emblée d’éventuelles attaques et d’échapper à des dommages et des pertes occasionnées par des personnes malveillantes.

Le top 10 2021 est le classement actuel de l’OWASP. Il existe quelques différences fondamentales avec sa version précédente, publiée en 2017. Notre formateur en cybersécurité, Yves Kraft, a consulté pour vous le document complet en anglais et explique dans cet article les failles listées au top 10 ainsi que les mesures concrètes et sécuritaires appropriées à mettre en œuvre.

Broken Access Control

Le contrôle des accès permet aux applications web de n’être accessibles qu’à un cercle limité de personnes, par exemple pour des utilisatrices et utilisateurs authentifié qui ne pourront agir qu’à un certain niveau d’autorisation. On parle de contrôle d’accès défaillant (Broken Access Control) lorsque les limitations prévues ne sont pas mises en œuvre correctement. Des personnes non autorisées ont alors accès à des données sensibles, et des pirates peuvent les modifier ou les détruire.

Les failles de sécurité les plus courantes :

• Des hackers peuvent avoir accès librement à des rôles et des fonctions
• Les paramètres et métadonnées peuvent être manipulés
• Des cyberpirates peuvent s’octroyer des droits en se basant sur des bugs ou des défauts de conception dans la programmation

Comment y remédier :

• L’application web doit être implémentée sur un serveur fiable ou par des API sans serveurs
• Les utilisateurs ne doivent pas avoir accès à une nouvelle fonction avant que l’administrateur ne leur accorde expressément l’accès (Deny by Default)
• Journalisez et surveillez les échecs de tentative de connexion ; les admins doivent être alertés en cas d’anomalies
• Si des utilisateurs se déconnectent ou sont inactifs pendant un long laps de temps, la session doit être automatiquement invalidée
• Les JSON Web Tokens sans états qui sont fournis lors de la connexion doivent avoir une durée de vie très courte
• Supprimez les comptes inactifs

Retour en haut ↑

Cryptographic Failures

Cette faille regroupe tous les problèmes liés au chiffrement et à ses erreurs. De telles erreurs peuvent mener à une divulgation de données.

Les failles de sécurité les plus courantes :

• Des données sensibles sont sauvegardées ou transférées en clair
• L’application web utilise des algorithmes et des protocoles de chiffrement désuets ou faibles
• Il n’y a pas de gestion ou de rotation des clés et des clés de chiffrement faibles ou standardisées sont utilisées

Comment y remédier :

• Classifiez les données et implémentez-les conformément au règlement sur la protection des données en vigueur
• Ne stockez pas de données sensibles
• Au repos, les données doivent être cryptées
• N’utilisez pas de protocoles en clair
• Ne mettez pas en cache les réponses utilisateur (User Responses) contenant des données sensibles

Retour en haut ↑

Injection

L’attaque par injection repose sur des données non fiables dans l’application web qui mènent à l’exécution de commandes. Les cybercriminels introduisent des données malveillantes et peuvent en conséquence voir, modifier et supprimer toutes les autres données – voire obtenir le contrôle du serveur.

Les formes les plus fréquentes d’injection :

• SQL-Injection
• Cross Site Scripting (XSS)
• Code-Injection
• Command-Injection

Les failles les plus courantes :

• Les données venant des utilisateurs ne sont pas validées, filtrées ou nettoyées
• L’interpréteur de l’application web utilise des requêtes dynamiques ou des appels non paramétrés
• Des données corrompues ou hostiles sont utilisées ou concaténées

Comment y remédier :

• Utilisez des API et frameworks sécurisés pour vos applications web ; évitez aussi les interpréteurs et utilisez à la place des requêtes paramétrées
• Créez une validation positive des données entrées et du côté du serveur, utilisez donc une “white list” comme filtre
• Utilisez des contrôles de banque de données au sein des requêtes (p. ex. LIMIT) ; en cas d’injection réussie, les données ne pourront pas être accessibles en masse

Retour en haut ↑

Insecure Design

Dans cette catégorie, on retrouve les défauts au niveau du design et de l’architecture logicielle. Ces failles doivent être considérées séparément de l’implémentation. En effet : un design certes bien implémenté, mais non sécurisé, est fragile face aux attaques.

Comment y remédier :

• La sécurité du design doit être intégrée le plus tôt possible lors du développement de l’application web ; exploitez le plus tôt possible les connaissances des experts en la matière
• Définissez des contrôles d’accès, des logiques commerciales et des User Stories
• Faites un test d’intégration pour vérifier la résistance de l’architecture
• Séparer les couches système et réseau de l’application
• Intégrez des bibliothèques avec des modèles sûres ou des composants prêts à l’emploi

Retour en haut ↑

Security Misconfiguration

Les contrôles de sécurité qui ne sont pas sécurisés ou configurés correctement sont également problématiques.

Les failles les plus courantes :

• Manque de durcissement de la sécurisation
• Des autorisations mal configurées
• Des fonctions superflues sont tolérées ou installées
• Les mots de passe par défaut ne sont pas modifiés
• Le logiciel n’est pas à jour

Comment y remédier :

• Implémentez un processus d’installation sécurisé
• Un processus de renfort sécurise le système ; chaque environnement séparé doit être accessible grâce à différentes informations de connexion
• Supprimez les fonctions et composants superflus, utilisez une plateforme minimale
• Les autorisations pour le stockage dans le cloud doivent être contrôlées et les données d’exemples supprimées
• Mettez en œuvre une architecture d’application segmentée pour séparer les utilisateurs des composants
• Une gestion des correctifs permet à l’administrateur de contrôler les mises à jour de l’application web
• Vérifiez l’efficacité des configurations et des paramètres de chaque environnement

Retour en haut ↑

Vulnerable and Outdated Components

Dans le dernier top 10 de l’OWASP, cette menace sécuritaire était encore en 9^e position sous le nom de « Using Components with Known Vulnerabilities ». Malheureusement, la situation ne s’est pas améliorée depuis 2017, bien au contraire. Elle se retrouve aujourd’hui, avec un nouveau nom, en 6^e position.

Les failles les plus courantes :

• Les versions et les composants côté client et côté serveur ne sont pas connus
• Des logiciels vulnérables, qui ne sont plus supportés ou obsolètes, sont encore utilisés
• On ne recherche pas suffisamment régulièrement les vulnérabilités
• Il n’y a pas de tests de compatibilité
• Les configurations des composants ne sont pas sécurisées

Comment y remédier :

• Supprimez les dépendances, fonctionnalités, composants, fichiers et documentations inutiles
• Faites régulièrement l’inventaire des versions des composants client et serveur ainsi que de leurs dépendances. L’OWASP propose pour cela un outil adapté : le Dependency Check
• N’utilisez que des sources officielles et des liens sûrs
• Faites particulièrement attention aux bibliothèques et aux composants dont la maintenance n’est pas assurée et pour lesquels il n’y a plus de patchs de sécurité ou plus que d’anciennes versions

Retour en haut ↑

Identification and Authentification Failures

Pour compromettre un système, il suffit à la personne malveillante d’obtenir quelques accès ou l’accès administrateur. Des erreurs d’authentification sont très courantes en raison d’erreurs de design ou d’implémentation lors de la vérification des identités et des accès. Un pirate peut facilement exploiter une mauvaise authentification avec des méthodes manuelles ou des outils automatisés (listes de mots de passe).

Les failles les plus courantes :

• L’application n’est pas protégée contre les attaques automatisées, des champs de connexion ou des formulaires de contact peuvent être remplis de façon automatisée
• Des mots de passe faibles ou trop courants sont acceptés lors de l’enregistrement
• Les mots de passe sont stockés en clair ou faiblement chiffrés
• Les attaques par la force brute sont rapidement couronnées de succès parce qu’il est possible de deviner facilement les adresses email utilisées pour la connexion
• Les sessions d’utilisateurs ne sont pas invalidées correctement en cas d’inactivité ou de déconnexion de l’utilisateur
• Les identifiants de session sont exposés dans l’URL

Comment y remédier :

• Une authentification à facteurs multiples permet d’éviter les attaques par force brute, le remplissage automatique des champs de connexion et la réutilisation de données de connexion volées
• Les données de connexion standards doivent être modifiées immédiatement
• Vérifiez les mots de passe faibles, orientez-vous pour cela sur le guide 800-63b du NIST
• Les mots de passe doivent être modifiés régulièrement
• Sécurisez l’enregistrement et la récupération des données de connexion en utilisant des messages identiques et neutres. Si des personnes malveillantes reçoivent par exemple l’information « ce nom d’utilisateur est déjà attribué », elles connaissent alors une partie du puzzle et n’ont plus qu’à craquer le mot de passe.
• Limitiez les tentatives de connexion suite à une tentative infructueuse ou utilisez un délai progressif entre les tentatives
• L’utilisation d’un gestionnaire de connexion côté serveur, sécurisé et intégré permet d’augmenter la sécurité, car ce dernier génère des nouvelles ID de session aléatoires avec une entropie élevée après chaque connexion
• Utilisez un timeout absolu

Retour en haut ↑

Software and Data Integrity Failures

Cette faille concerne les mises à jour logiciel, les données critiques et les pipelines CI/CD dont l’intégrité n’est pas vérifiée – par exemple les plug-ins, les bibliothèques ou les modules issus de sources non vérifiables ou non fiables. Les fonctions d’actualisation automatiques des applications sans vérification d’intégrité font aussi partie de cette faille.

Comment y remédier :

• Utilisez des signatures numériques
• N’utilisez que des bibliothèques et dépendances de sources fiables
• Établissez un processus de révision des changements de code et de configuration
• Mettez en œuvre une distinction, configuration et contrôle des accès fondamentaux du pipeline CI/CD
• N’envoyez pas de données sérialisées non sécurisées ou non chiffrées à des clients non fiables

Retour en haut ↑

Security Logging and Monitoring Failures

L’enregistrement et le contrôle sont certes difficiles à tester, mais il faut garder on œil attentif sur cette problématique. En effet, ces erreurs peuvent avoir des conséquences sur la fiabilité, la transparence, l’alerte en cas d’incidents et la criminalistique.

Les failles les plus courantes :

• Les connexions, échecs de connexion ou de transactions sensibles ne sont pas journalisées
• Les alertes ou les erreurs ne font l’objet que de journalisations insuffisantes ou peu claires, s’ils en font l’objet tout court
• Les protocoles d’API et d’application ne sont pas contrôlés pour déceler des activités suspectes
• Les protocoles ne sont stockés qu’en local
• Il n’y a pas de seuil ou un seuil inefficace d’alerte ni de remontée d’information pour y répondre
• Il n’est pas possible d’identifier une attaque en temps réel

Comment y remédier :

• Mettez en œuvre un processus de contrôle et journalisez tout ce qui concerne la connexion
• Conservez les données de journalisation suffisamment longtemps
• Sauvegardez les données dans des formats supportés par les gestionnaires de logs

Retour en haut ↑

Server-Side Request Forgery (SSRF)

Une faille SSRF a lieu lorsque l’application web ne valide pas l’URL entrée par l’utilisateur lors d’une récupération de ressource distante. Une personne malveillante peut alors envoyer une requête manipulée à une destination inattendue. Étant donné qu’une récupération d’URL est un scénario courant des applications web modernes, l’incidence des failles SSRF augmente. L’accès direct de l’utilisateur à l’application et certes impossible grâce à l’authentification, mais les pirates exploitent de plus en plus le serveur web pour obtenir l’accès au système.

Comment y remédier au niveau du réseau :

• Diminuez l’effet des SSRF en segmentant les fonctionnalités d’accès à distance dans des réseaux séparés
• Bloquez la totalité du trafic de données à l’exception du trafic de données essentiel, utilisez le principe de « Deny By Default »

Comment y remédier au niveau de l’application :

• Toutes les données d’entrée fournies doivent être nettoyées
• Utilisez une “Allow List” positive
• Désactivez la redirection HTTP

Retour en haut ↑