OWASP Top 10 expliqué avec des exemples pratiques
Chaque année, des milliers d'applications web sont compromises en raison des mêmes failles de sécurité récurrentes. Le Top 10 OWASP est un document de sensibilisation standard qui répertorie les risques de sécurité les plus critiques pour les applications web. Dans cet article, nous allons passer en revue chaque risque, montrer un exemple pratique et expliquer comment l'atténuer. Que vous soyez développeur, ingénieur DevOps ou passionné de sécurité, comprendre ces risques est essentiel pour construire des systèmes sécurisés.
1. Contrôle d'accès défaillant
Le contrôle d'accès défaillant se produit lorsque les utilisateurs peuvent agir en dehors de leurs permissions prévues. Par exemple, un utilisateur peut accéder aux données d'un autre utilisateur en modifiant un paramètre d'URL.
Exemple : Une application utilise /api/user/123 pour récupérer les données d'un utilisateur. S'il n'y a pas de vérification que l'utilisateur connecté est bien l'utilisateur 123, un attaquant peut changer l'ID en /api/user/124 et consulter le profil de quelqu'un d'autre.
Atténuation : Mettez en place des contrôles d'accès côté serveur. Refusez par défaut. Utilisez le contrôle d'accès basé sur les rôles (RBAC) et validez les permissions à chaque requête.
2. Défaillances cryptographiques
Anciennement appelé « Exposition de données sensibles », ce risque consiste à ne pas protéger les données sensibles en transit ou au repos.
Exemple : Stocker des mots de passe en clair ou utiliser des algorithmes de hachage faibles comme MD5.
Atténuation : Utilisez un chiffrement fort (par exemple AES-256) pour les données au repos, TLS 1.2+ pour les données en transit, et un hachage de mot de passe robuste (bcrypt, Argon2).
3. Injection
Les failles d'injection, telles que l'injection SQL, NoSQL, OS et LDAP, se produisent lorsque des données non fiables sont envoyées à un interpréteur dans le cadre d'une commande ou d'une requête.
Exemple : Un formulaire de connexion qui construit une requête SQL comme :
SELECT * FROM users WHERE username = '$username' AND password = '$password';
Si un attaquant saisit ' OR '1'='1 comme nom d'utilisateur, il peut contourner l'authentification.
Atténuation : Utilisez des requêtes paramétrées ou des instructions préparées. Échappez les caractères spéciaux et validez les entrées.
4. Conception non sécurisée
La conception non sécurisée fait référence à des failles dans l'architecture et la conception d'une application, et non seulement à des bugs d'implémentation.
Exemple : Une fonctionnalité de réinitialisation de mot de passe qui utilise des questions de sécurité avec des réponses faciles à deviner.
Atténuation : Modélisation des menaces lors de la conception, modèles de conception sécurisés et architectures de référence.
5. Mauvaise configuration de sécurité
Cela inclut les comptes par défaut, les pages inutilisées, les failles non corrigées, les fichiers et répertoires non protégés.
Exemple : Laisser les identifiants administrateur par défaut sur un CMS ou exposer les listages de répertoires.
Atténuation : Durcissez les configurations, supprimez les fonctionnalités inutilisées et automatisez les vérifications de configuration.
6. Composants vulnérables et obsolètes
Utiliser des bibliothèques, frameworks ou logiciels présentant des vulnérabilités connues.
Exemple : Exécuter une ancienne version d'une bibliothèque JavaScript avec une vulnérabilité XSS connue.
Atténuation : Mettez régulièrement à jour les dépendances, utilisez des outils comme npm audit ou OWASP Dependency-Check, et supprimez les dépendances inutilisées.
7. Défaillances d'identification et d'authentification
Faiblesses dans l'authentification et la gestion de session.
Exemple : Autoriser des mots de passe faibles, l'absence de limitation du taux de tentatives de connexion, ou exposer les identifiants de session dans les URL.
Atténuation : Implémentez l'authentification multifacteur, appliquez des politiques de mots de passe forts et utilisez une gestion de session sécurisée.
8. Défaillances d'intégrité des logiciels et des données
Code et infrastructure qui ne protègent pas contre les violations d'intégrité.
Exemple : Utiliser des CDN non fiables pour les scripts sans Subresource Integrity (SRI).
Atténuation : Utilisez SRI, vérifiez les signatures et assurez-vous que les pipelines CI/CD sont sécurisés.
9. Défaillances de journalisation et de surveillance de sécurité
Une journalisation et une surveillance insuffisantes permettent aux attaquants de persister sans être détectés.
Exemple : Ne pas journaliser les tentatives de connexion échouées, de sorte que les attaques par force brute passent inaperçues.
Atténuation : Journalisez les événements liés à la sécurité, surveillez les journaux et configurez des alertes pour les activités suspectes.
10. Falsification de requête côté serveur (SSRF)
La SSRF se produit lorsqu'un attaquant peut amener le serveur à effectuer des requêtes vers des ressources internes.
Exemple : Une fonctionnalité de webhook qui récupère une URL fournie par l'utilisateur. Un attaquant pourrait fournir http://169.254.169.254/latest/meta-data/ pour accéder aux métadonnées du cloud.
Atténuation : Validez et assainissez les URL, utilisez des listes d'autorisation et restreignez le trafic sortant.
Tableau comparatif
| Risque | Exemple | Atténuation |
|---|---|---|
| Contrôle d'accès défaillant | Accéder aux données d'un autre utilisateur via IDOR | Vérifications de permissions côté serveur |
| Défaillances cryptographiques | Stocker des mots de passe en clair | Utiliser un hachage fort et TLS |
| Injection | Injection SQL via un formulaire de connexion | Requêtes paramétrées |
| Conception non sécurisée | Questions de réinitialisation de mot de passe faibles | Modélisation des menaces |
| Mauvaise configuration de sécurité | Identifiants administrateur par défaut | Durcir les configurations |
| Composants vulnérables | Ancienne bibliothèque avec faille XSS | Mises à jour régulières |
| Défaillances d'authentification | Pas de limitation de taux à la connexion | MFA et limitation de taux |
| Défaillances d'intégrité | Scripts CDN non fiables | Subresource Integrity |
| Défaillances de journalisation | Aucun journal pour les connexions échouées | Journalisation centralisée et alertes |
| SSRF | Récupérer des métadonnées internes | Listes d'autorisation d'URL |
Comment démarrer
- Évaluer : Exécutez des scanners automatisés et des revues manuelles par rapport au Top 10 OWASP.
- Prioriser : Corrigez d'abord les problèmes les plus critiques (par exemple, injection, contrôle d'accès défaillant).
- Former : Sensibilisez les développeurs aux pratiques de codage sécurisé.
- Surveiller : Mettez en place la journalisation et les alertes pour les événements de sécurité.
- Itérer : Mettez régulièrement à jour les dépendances et retestez.
FAQ
Qu'est-ce que le Top 10 OWASP ?
Le Top 10 OWASP est une liste régulièrement mise à jour des risques de sécurité les plus critiques pour les applications web, publiée par l'Open Web Application Security Project (OWASP).
À quelle fréquence le Top 10 OWASP est-il mis à jour ?
Il est mis à jour environ tous les trois à quatre ans, la dernière version ayant été publiée en 2021. Cependant, OWASP fournit des conseils et des mises à jour continues.
Puis-je me fier uniquement au Top 10 OWASP pour la sécurité ?
Non, c'est un point de départ. Vous devriez également suivre d'autres projets OWASP comme l'Application Security Verification Standard (ASVS) et effectuer des tests de sécurité réguliers.
Pour analyser rapidement vos journaux Nginx à la recherche de signes d'attaques comme l'injection SQL ou XSS, essayez notre Analyseur de journaux Nginx. Il vous aide à repérer les schémas suspects et à sécuriser votre serveur web.