.png)
TL;DR
L'OWASP ASVS est une liste de contrôle détaillée, élaborée par la communauté, pour vérifier la sécurité des applications web. Elle est utilisée par les développeurs, les testeurs et les architectes.
Couvre des domaines tels que AuthN, AuthZ, cryptographie, sécurité des API - divisé en L1 (basique) à L3 (applications critiques).
Il ne s'agit pas d'un certificat, mais il est idéal pour définir des lignes de base en matière de sécurité, guider des tests de pénétration ou créer des applications sécurisées à partir de zéro.
Résumé du tableau de bord ASVS de l'OWASP :
- Effort du développeur : Modéré à élevé (nécessite de comprendre les contrôles de sécurité détaillés dans de nombreux domaines et de les mettre en œuvre correctement pendant le développement ; utilisé comme référence pendant les tests).
- Coût de l'outillage : Faible à modéré (la norme elle-même est gratuite ; les coûts sont liés aux outils utilisés pour tester les exigences de l'ASVS - SAST, DAST, IAST, outils de test d'intrusion).
- Impact sur le marché : élevé (norme industrielle largement respectée pour la vérification de la sécurité des applications web ; souvent utilisée comme base pour définir les exigences de sécurité et la portée des tests).
- Flexibilité : élevée (les niveaux permettent une adaptation en fonction du risque ; des exigences spécifiques peuvent être considérées comme non applicables).
- Intensité de l'audit : N/A (il ne s'agit pas d'une norme d'audit formelle pour la certification, mais elle est utilisée lors des évaluations/tests de sécurité qui peuvent être intenses).
Qu'est-ce que l'OWASP ASVS ?
L'OWASP Application Security Verification Standard (ASVS) est un projet open-source qui fournit un cadre d'exigences et de contrôles de sécurité spécifiquement destinés à vérifier la sécurité des applications web. Il répond à deux objectifs principaux :
- Pour les développeurs : Fournit une liste détaillée des exigences de sécurité pour guider les pratiques de développement sécurisé.
- Pour les testeurs : Fournit une base pour tester les contrôles de sécurité technique des applications web lors des évaluations de sécurité, des tests de pénétration ou des revues de code sécurisées.
L'OWASP ASVS est structuré en chapitres couvrant les principaux domaines de la sécurité :
- V1 : Architecture, conception et modélisation des menaces
- V2 : Authentification
- V3 : Gestion des sessions
- V4 : Contrôle d'accès
- V5 : Validation, assainissement et codage
- V6 : Cryptographie stockée
- V7 : Gestion des erreurs et journalisation
- V8 : Protection des données
- V9 : Sécurité des communications
- V10 : Code malveillant
- V11 : Logique d'entreprise
- V12 : Dossier et ressources
- V13 : API et service web
- V14 : Configuration
Dans chaque chapitre, des exigences de vérification spécifiques (contrôles) sont énumérées. L'ASVS de l'OWASP définit trois niveaux de vérification de la sécurité (niveaux ASVS), indiquant des niveaux croissants de profondeur et de rigueur :
- Niveau 1 (assurance faible) : Destiné aux applications à faible risque ou à une première étape. Il se concentre sur les vulnérabilités et les contrôles facilement détectables qui peuvent souvent être vérifiés automatiquement (par exemple, les tests de pénétration de base). Toute application devrait viser au moins le niveau 1.
- Niveau 2 (assurance standard) : Recommandé pour la plupart des applications, en particulier celles qui traitent des données sensibles ou effectuent des transactions importantes. Nécessite des vérifications plus approfondies couvrant la protection contre les risques courants liés à la sécurité des applications (comme le Top 10 de l'OWASP). Nécessite des tests automatisés et manuels, y compris des éléments de révision de la conception et du code.
- Niveau 3 (haute assurance) : Pour les applications critiques traitant des données très sensibles (par exemple, dans les domaines de la finance, de la santé et de l'administration). Nécessite une vérification complète de la sécurité, y compris un examen approfondi de la conception et du code, ainsi que des tests rigoureux pour résister à des attaquants expérimentés.
Le niveau requis détermine les exigences de vérification spécifiques à chaque chapitre qui doivent être satisfaites.
Pourquoi est-ce important ?
L'OWASP ASVS est une pierre angulaire de la sécurité des applications web modernes, parce que.. :
- Normalisation : Offre une norme cohérente et reproductible pour ce qui constitue une application web sécurisée, allant au-delà des tests ad hoc.
- Des orientations concrètes : Donne aux développeurs des exigences concrètes et aux testeurs des éléments spécifiques à vérifier, comblant ainsi le fossé entre les principes de haut niveau et la mise en œuvre.
- Approche basée sur le risque : Le système de niveaux permet aux organisations d'adapter les efforts de vérification en fonction du profil de risque de l'application.
- Complète le Top 10 de l'OWASP : Alors que le Top 10 énumère les risques courants, l'ASVS fournit les contrôles détaillés nécessaires pour atténuer ces risques (et bien d'autres).
- Reconnaissance de l'industrie : Largement respecté et utilisé dans le monde entier par les développeurs, les professionnels de la sécurité et les organisations qui achètent des logiciels.
- Prend en charge le cycle de développement durable (SDLC) sécurisé : Il peut être intégré tout au long du cycle de développement durable - en définissant les exigences, en guidant la conception et le codage, et en constituant la base des tests de vérification.
- Open Source & Community Driven : Disponible gratuitement et constamment mis à jour par une communauté mondiale d'experts en sécurité.
L'utilisation de l'OWASP ASVS permet de s'assurer que les tests de sécurité sont complets, cohérents et axés sur les contrôles qui comptent réellement pour la protection des applications web.
Quoi et comment mettre en œuvre (technique et politique)
La mise en œuvre de l'OWASP ASVS ne consiste pas à obtenir une certification, mais à utiliser la norme pour créer et vérifier des applications sécurisées :
- Déterminer le niveau requis : En fonction de la sensibilité des données de l'application, de la criticité de l'activité et des exigences réglementaires, choisissez le niveau ASVS cible (1, 2 ou 3).
- Intégration dans les exigences (phase de conception) : Utiliser les exigences de l'ASVS pour le niveau choisi (et les chapitres pertinents) pour définir les exigences de sécurité au cours des phases de conception et de planification.
- Exemple (contrôle d'accès V4) : Si vous créez une application nécessitant différents rôles d'utilisateur, examinez les exigences du chapitre V4 de l'ASVS, telles que V4.1.1 ("Vérifier que l'application applique les règles de contrôle d'accès sur une couche de service de confiance..."), et concevez le système en conséquence.
- Élaboration du guide (phase de codage) : Les développeurs utilisent les exigences de l'ASVS comme une liste de contrôle pour s'assurer que les pratiques de codage sécurisées sont respectées.
- Exemple (validation d'entrée V5) : Lors de la création de formulaires de saisie, il convient de se référer aux exigences de la V5 telles que V5.1.1 ("Vérifier que l'application dispose de défenses contre la pollution des paramètres HTTP...") et V5.2.1 ("Vérifier que les données structurées sont fortement typées..."). Mettre en œuvre des bibliothèques et des routines de validation des entrées qui répondent à ces exigences.
- Test de sécurité informatique (phase de vérification) : Les testeurs de sécurité (pen testers, code reviewers) utilisent la liste de contrôle ASVS pour le niveau cible afin de structurer leur évaluation. Ils vérifient si chaque exigence applicable a été respectée.
- Exemple (authentification V2) : Un testeur vérifiant le niveau 2 contrôlerait des exigences telles que V2.2.1 ("Vérifier que la longueur minimale du mot de passe est de 12 caractères..."), V2.1.1 ("Vérifier que les informations d'identification ne sont jamais stockées sous une forme récupérable...") et V2.4.1 ("Vérifier qu'il existe un mécanisme de verrouillage du compte...").
- Intégration de l'outillage :
- Outils SAST/DAST : Configurer les scanners pour vérifier les violations liées aux exigences de l'ASVS (par exemple, trouver des failles d'injection potentielles liées à la V5).
- Gestion de la liste de contrôle : Utilisez des feuilles de calcul ou des outils tels que SecurityRAT pour gérer les exigences ASVS, suivre l'applicabilité et enregistrer les résultats des vérifications.
- Documentation : Documenter la manière dont les exigences de l'ASVS ont été satisfaites (ou la raison pour laquelle elles ont été jugées non applicables) dans le cadre des documents de conception, des commentaires sur le code et des rapports d'essai.
La mise en œuvre consiste à utiliser activement la liste ASVS tout au long du cycle de développement durable (SDLC) - comme un guide pour construire en toute sécurité et comme une liste de contrôle pour vérifier la sécurité.
Les erreurs courantes à éviter
Lors de l'utilisation de l'OWASP ASVS, il convient d'être attentif à ces erreurs courantes :
- Choix du mauvais niveau : Choisir le niveau 1 pour une application à haut risque, ou viser le niveau 3 lorsque les ressources ne permettent qu'une vérification de niveau 2, ce qui conduit à des évaluations inadéquates ou incomplètes.
- Le considérer comme une simple liste de contrôle de pentest : L'ASVS est plus large que le simple pentesting ; les niveaux 2 et 3 requièrent des aspects de conception et d'examen du code. En s'appuyant uniquement sur l'analyse dynamique, on passe à côté de vulnérabilités cruciales.
- Ignorer l'applicabilité : Essayer aveuglément d'appliquer chaque exigence sans se demander si elle est pertinente pour l'architecture, la pile technologique ou les caractéristiques de l'application spécifique.
- Manque de formation des développeurs : Attendre des développeurs qu'ils répondent aux exigences de l'ASVS sans les former aux concepts de sécurité sous-jacents et aux pratiques de codage sécurisées nécessaires.
- Application incohérente : Application rigoureuse de l'ASVS lors d'un test, mais superficielle lors du suivant, ce qui conduit à une posture de sécurité incohérente.
- Ne pas l'intégrer dès le début : N'utiliser ASVS qu'à la toute fin pour les tests, au lieu de l'utiliser pour informer la conception et le développement sécurisés dès le début (ce qui est beaucoup plus efficace).
- Mauvaise interprétation des exigences : Ne pas comprendre les nuances ou l'intention qui sous-tendent les exigences spécifiques de la vérification ASVS.
Ce que les auditeurs et les testeurs demanderont (accent mis sur les développeurs)
Les testeurs de sécurité qui utilisent l'OWASP ASVS demanderont essentiellement aux développeurs (directement ou par le biais d'un examen du code/de la conception) de démontrer comment des exigences spécifiques sont satisfaites :
- (V1) "Pouvez-vous me montrer le modèle de menace pour cette application ?" (1.1.1 - L2+)
- (V2) "Comment les mots de passe des utilisateurs sont-ils stockés ? Pouvez-vous montrer l'implémentation du hachage ?" (2.2.2 - L1+)
- (V3 ) "Comment les jetons de session sont-ils générés et protégés contre le détournement ?" (3.1.1, 3.3.1 - L1+)
- (V4) "Démontrer comment l'application empêche un utilisateur standard d'accéder aux fonctionnalités d'administration." (4.1.1, 4.1.2 - L1+)
- (V5) "Montrez-moi les routines de validation des entrées utilisées pour ce point de terminaison critique de l'API." (5.1.3, 5.2.1 - L1+)
- (V6) "Où et comment les clés cryptographiques sont-elles gérées dans l'application ?" (6.2.1 - L2+)
- (V7) "Comment l'application gère-t-elle les erreurs sans laisser échapper d'informations sensibles ?" (7.1.1 - L1+)
- (V8) "Comment les données sensibles sont-elles protégées lorsqu'elles sont stockées dans la base de données (cryptage, masquage) ?" (8.1.1 - L2+)
- (V13) "Comment l'authentification et l'autorisation sont-elles gérées pour les demandes d'API ?" (13.1.1, 13.2.1 - L1+)
Ils rechercheront des preuves concrètes dans le code, la configuration, les documents de conception ou l'application en cours d'exécution pour vérifier la conformité avec chaque exigence ASVS pertinente pour le niveau cible.
Des gains rapides pour les équipes de développement
Les développeurs peuvent commencer à intégrer facilement les principes ASVS de l'OWASP:
- Se concentrer sur les éléments de base du niveau 1 : Commencez par examiner et mettre en œuvre les exigences de niveau 1 dans des domaines clés tels que l'authentification (V2), le contrôle d'accès (V4) et la validation des entrées (V5). Ces exigences couvrent de nombreuses failles courantes.
- Utiliser les paramètres par défaut du cadre sécurisé : Exploitez les fonctions de sécurité intégrées de votre cadre web (par exemple, pour la gestion des sessions, la protection CSRF, l'encodage de sortie) qui s'alignent souvent sur ASVS.
- Valider et encoder : Valider de manière cohérente toutes les entrées et coder toutes les sorties destinées aux navigateurs, aux API ou aux bases de données. (cœur de la V5)
- Mettre en œuvre la journalisation de base : S'assurer que les principaux événements de sécurité (connexions, échecs, transactions importantes) sont consignés dans un journal (élément essentiel de la V7).
- Examiner le Top 10 de l'OWASP : Comprendre les 10 principaux risques et comment les contrôles ASVS contribuent à les atténuer.
- Utiliser les outils SAST : Configurer les outils SAST pour signaler les violations liées aux exigences ASVS courantes (par exemple, traitement non sécurisé des mots de passe, points d'injection potentiels).
Ignorez ceci et... (Conséquences de la non-conformité)
Ignorer les principes et les exigences énoncés dans l'OWASP ASVS revient à négliger les contrôles fondamentaux de la sécurité des applications web. Les conséquences sont directes :
- Probabilité accrue de violations : Les applications seront plus vulnérables aux attaques courantes telles que XSS, SQL Injection, authentification défaillante, contrôle d'accès défaillant, etc. (directement liées aux chapitres ASVS).
- Perte ou vol de données : Les vulnérabilités permettent aux attaquants de voler les données sensibles des utilisateurs, ce qui entraîne des violations de la vie privée et des amendes réglementaires (par exemple, GDPR).
- Perturbation des services : Les attaques peuvent mettre les applications hors ligne, entraînant une interruption des activités et une perte de revenus.
- Atteinte à la réputation : Les incidents de sécurité érodent la confiance des clients et nuisent à l'image de marque de l'entreprise.
- Échec des audits et pentests de sécurité : Si les clients ou les partenaires exigent des tests de sécurité, une application qui n'a pas été conçue en tenant compte des principes ASVS échouera probablement, ce qui risque de bloquer les transactions ou les déploiements.
- Augmentation des coûts de remédiation : Trouver et corriger les vulnérabilités à un stade avancé du cycle ou après une violation est beaucoup plus coûteux que de mettre en place une sécurité en utilisant l'ASVS comme guide.
Pour l'essentiel, ne pas adhérer à l'OWASP ASVS revient à créer des applications web intrinsèquement peu sûres.
FAQ
L'OWASP ASVS est-il une norme de conformité comme SOC 2 ou ISO 27001 ?
L 'OWASP ASVS est une norme de vérification, essentiellement une liste de contrôle détaillée pour tester la sécurité des applications web. Elle n'implique pas d'audits formels ou de certifications comme SOC 2 ou ISO 27001, qui couvrent des systèmes de gestion plus larges. Cependant, le respect des niveaux ASVS peut aider à satisfaire les exigences de contrôle technique dans ces cadres plus larges.
Quelle est la différence entre OWASP ASVS et OWASP Top 10 ?
Le Top 10 de l'OWASP énumère les dix risques les plus critiques pour la sécurité des applications web, sur la base d'un consensus et de données de la communauté. L 'OWASP ASVS fournit les contrôles de sécurité détaillés et les exigences de vérification nécessaires pour prévenir et tester ces risques (et bien d'autres). Le Top 10 vous indique quels sont les principaux problèmes ; l'ASVS vous indique comment vérifier vos défenses contre ces problèmes.
Quel niveau ASVS devons-nous viser ?
Cela dépend du risque. Le niveau 1 est la base minimale pour toutes les applications. Le niveau 2 est recommandé pour la plupart des applications traitant des données ou des transactions sensibles. Le niveau 3 est réservé aux applications hautement critiques pour lesquelles une défaillance a de graves conséquences (par exemple, données financières ou médicales).
Doit-on satisfaire à 100 % des exigences d'un niveau spécifique ?
En général, oui, pour toutes les exigences applicables. La norme permet de marquer les exigences comme "non applicables" si elles ne s'appliquent vraiment pas à la technologie ou à la fonctionnalité de l'application, mais cela nécessite une justification. Des contrôles compensatoires peuvent parfois être acceptés si une exigence spécifique ne peut être satisfaite directement.
L'ASVS est-il réservé aux tests de pénétration ?
Bien qu'ils soient largement utilisés dans les tests de pénétration (en particulier au niveau 1), les niveaux 2 et 3 de l'ASVS exigent explicitement une vérification allant au-delà des tests dynamiques, y compris des examens de l'architecture, de la conception et du code source. Ils sont destinés à la vérification globale de la sécurité des applications.
Quelle est la fréquence des vérifications par rapport à l'ASVS ?
La vérification devrait être intégrée dans le cycle de développement durable. Il peut s'agir de vérifier les exigences pertinentes lors des revues de code, d'exécuter des tests automatisés alignés sur l'ASVS dans le cadre du processus CI/CD et d'effectuer des évaluations complètes de l'ASVS (au niveau cible) avant les versions majeures ou périodiquement (par exemple, une fois par an) pour les applications critiques.
ASVS peut-il être utilisé pour les API et les applications mobiles ?
Le chapitre V13 de l'OWASP ASVS traite spécifiquement de la vérification des API et des services Web. Bien qu'il soit principalement axé sur les applications web, de nombreux principes s'appliquent de manière générale. Pour les applications mobiles, l'OWASP propose également la norme MASVS (Mobile Application Security Verification Standard).
