Securly
Le Top 10 de l'OWASP est un rapport régulièrement mis à jour décrivant les problèmes de sécurité des applications web, en se concentrant sur les 10 risques les plus critiques. Le rapport est rédigé par une équipe d'experts en sécurité du monde entier. L'OWASP qualifie le Top 10 de « document de sensibilisation » et recommande à toutes les entreprises d'intégrer le rapport dans leurs processus afin de minimiser les risques de sécurité.
Vous trouverez ci-dessous les risques de sécurité signalés dans le rapport OWASP Top 10 2022 :
1. Contrôle d'accès brisé
Le contrôle d'accès brisé signifie que les attaquants peuvent accéder aux comptes d'utilisateurs et agir en tant qu'utilisateurs ou administrateurs, et que les utilisateurs réguliers peuvent obtenir des fonctions privilégiées involontaires. Des mécanismes d'accès solides garantissent que chaque rôle dispose de privilèges clairs et isolés.
Que faire ?
- Refuser l'accès par défaut, sauf pour les ressources publiques
- Créer des mécanismes de contrôle d'accès et les réutiliser sur l'ensemble de l'application
- Désactiver le listing des répertoires du serveur
- Implémenter le rate limite sur vos APIs
- Valider les jetons JWT après la déconnexion
2. Défaillances cryptographiques
Les défaillances cryptographiques, anciennement connues sous le nom d'exposition de données sensibles, couvrent la protection des données en transit et au repos. Cela inclut les mots de passe, les numéros de carte de crédit, les dossiers médicaux, les informations personnelles et autres informations sensibles.
Cela est particulièrement important pour les entreprises couvertes par des normes la confidentialité des données telles que le RGPD (règlement général sur la protection des données).
Que faire ?
- Identifier les données sensibles et appliquer les contrôles de sécurité appropriés
- Ne pas stocker de données sensibles à moins que cela ne soit absolument nécessaire
- Sécuriser les données confidentielles avec des algorithmes de chiffrement, tels que Argon2, scrypt et bcrypt.
- Chiffrer les données en transit à l'aide de protocoles sécurisés tels que SSL & HTTP HSTS.
- Désactiver la mise en cache des données sensibles.
3. Injection
Une vulnérabilité d'injection dans une application web permet aux attaquants d'envoyer des données hostiles à un interpréteur, provoquant la compilation et l'exécution de ces données sur le serveur. La forme la plus courante d'injection est l'injection SQL.
Que faire ?
- Utiliser une API sécurisée qui évite complètement l'utilisation de l'interpréteur
- Utiliser une validation d'entrée côté serveur positive, dite whitelist (ou "liste blanche")
- Echapper tous les caractères spéciaux
- Utiliser LIMIT et d'autres contrôles SQL dans les requêtes pour empêcher la divulgation d'enregistrements en cas d'injection SQL
4. Conception non sécurisée
La conception non sécurisée est une catégorie de vulnérabilités qui proviennent de contrôles de sécurité manquants ou inefficaces. Certaines applications sont construites sans souci de sécurité. D'autres ont une conception sécurisée, mais ont des défauts de mise en œuvre qui peuvent conduire à des vulnérabilités exploitables.
Par définition, une conception non sécurisée ne peut pas être corrigée par une implémentation ou une configuration appropriée. En effet, il manque des contrôles de sécurité de base qui peuvent protéger efficacement contre les menaces importantes.
Que faire ?
- Tirer parti des pratiques de sécurité des applications dès les premières étapes du développement
- Tirer parti de la modélisation des menaces pour concevoir des fonctionnalités critiques telles que l'authentification et le contrôle d'accès
- Intégrer les préoccupations et les contrôles de sécurité dans toutes les fonctionnalités
5. Mauvaise configuration de la sécurité
La mauvaise configuration de la sécurité est un manque de renforcement de la sécurité. Cela peut inclure une configuration incorrecte des autorisations de service cloud, l'activation de fonctionnalités non-requises, ainsi que des comptes ou des mots de passe d'administrateur (root) par défaut. Cela inclut désormais également les entités externes XML (XXE), qui formaient auparavant une catégorie OWASP distincte.
Que faire ?
- Établir un processus de durcissement des applications, rapide et facile à déployer
- Les configurations doivent être régulièrement mises à jour, en appliquant des correctifs et des avis de sécurité
- Établir un processus automatisé pour vérifier les configurations sécurisées dans tous les environnements
6. Composants vulnérables et obsolètes
Les composants vulnérables et obsolètes incluent les vulnérabilités résultant de logiciels non pris en charge ou obsolètes. Toute personne qui construit ou utilise une application sans connaître ses composants internes, leurs versions et s'ils sont mis à jour, est exposée à cette catégorie de vulnérabilités.
Que faire ?
- Supprimer les dépendances, composants et fichiers inutilisés de votre application
- Analyser en continu les bibliothèques et leurs dépendances à la recherche de composants vulnérables
- N'utiliser que des composants provenant de sources officielles et préférer les packages signés
- Corriger de toute urgence les vulnérabilités, supprimez les composants concernés ou appliquer un correctif virtuel
7. Échecs d'identification et d'authentification
Anciennement connue sous le nom d'authentification brisée, cette catégorie inclut désormais également les problèmes de sécurité liés aux identités des utilisateurs. La confirmation et la vérification des identités des utilisateurs et l'établissement d'une gestion de session sécurisée sont essentiels pour se protéger contre de nombreux types d'intrusions et d'attaques.
Que faire ?
- Implémenter l'authentification multi-facteurs (MFA)
- Ne pas déployer de systèmes avec des informations d'identification par défaut
- Recherchez une liste des 10k pires mots de passe
- Limiter ou retarder les tentatives de connexion infructueuses
8. Échecs de l'intégrité des logiciels et des données
Les défaillances d'intégrité des logiciels et des données impliquent un code et une infrastructure vulnérables aux violations d'intégrité. Cela inclut les mises à jour logicielles, la modification des données sensibles et les modifications du pipeline CI/CD effectuées sans validation. Un pipeline non-sécurisé peut entraîner un accès non autorisé, l'introduction de logiciels malveillants et d'autres vulnérabilités graves.
Il existe une préoccupation mondiale concernant les applications avec des mises à jour automatiques. Dans plusieurs cas, les attaquants ont fait irruption dans la chaîne d'approvisionnement et créé leurs propres mises à jour malveillantes. Des milliers d'organisations ont été compromises en téléchargeant des mises à jour et en appliquant ces mises à jour malveillantes à des applications précédemment approuvées, sans validation d'intégrité.
Que faire ?
- Utiliser des signatures numériques pour vérifier que le logiciel provient de la source attendue
- S'assurer que les bibliothèques et les dépendances, telles que npm, soient extraites de référentiels de confiance
- Établir un processus de révision pour les changements de code (code review)
9. Échecs de journalisation et de surveillance de la sécurité
Les échecs de journalisation et de surveillance de la sécurité, anciennement appelés « journalisation et surveillance insuffisantes », impliquent des faiblesses dans la capacité d'une application à détecter les risques de sécurité et à y répondre. Les violations ne peuvent pas être détectées sans journalisation et surveillance. Les défaillances de cette catégorie affectent la visibilité, les alertes et l'investigation.
Que faire ?
- S'assurer que la connexion, le contrôle d'accès et la validation des entrées côté serveur soient enregistrés
- S'assurer que les logs contiennent suffisamment de contexte pour identifier les comportements suspects et permettre une analyse approfondie
- S'assurer que les logs soient dans un format compatible avec les solutions de gestion des journaux
- Prendre des mesures pour empêcher les attaquants de falsifier les données de log
10. Contrefaçon de requête côté serveur
Une vulnérabilité SSRF (Server-Side Request Forgery) se produit lorsqu'une application web extrait des données d'une ressource distante en fonction d'une URL spécifiée par l'utilisateur, sans valider l'URL. Même les serveurs protégés par un pare-feu ou un VPN peuvent être vulnérables à cette attaque s'ils acceptent des URL non-validées comme input d'utilisateur.
Que faire ?
- Éviter d'accepter les URL dans les inputs
- Isoler toute fonctionnalité d'accès aux ressources à distance dans un réseau séparé pour réduire l'impact
- Désactiver les redirections HTTP
- Ne jamais renvoyer de réponses brutes aux clients