Formation Tests de sécurité des applications : OWASP Top 10, SAST, DAST et SCA

A01:2025 – Violation du contrôle d'accès

Le contrôle d'accès applique une politique garantissant que les utilisateurs ne puissent pas agir au-delà de leurs autorisations prévues. Les défaillances entraînent typiquement une divulgation, une modification ou une destruction non autorisée de toutes les données, ou l'exécution d'une fonction d'affaires hors des limites de l'utilisateur.

Aspects pratiques

• Exemples pratiques de contrôles d'accès défaillants

• Contrôles d'accès sécurisés et meilleures pratiques

A02:2025 – Erreurs de configuration de sécurité

Une erreur de configuration de sécurité survient lorsqu'un système, une application ou un service cloud est configuré incorrectement d'un point de vue sécuritaire, créant ainsi des vulnérabilités.

Aspects pratiques

• Exemples réels de mauvaises configurations

• Étapes pour prévenir les erreurs de configuration, y compris la gestion de la configuration et les outils d'automatisation

A03:2025 – Défaillances de la chaîne d'approvisionnement logicielle

Les défaillances de la chaîne d'approvisionnement logicielle sont des pannes ou d'autres compromissions dans le processus de construction, de distribution ou de mise à jour du logiciel. Elles sont souvent causées par des vulnérabilités ou des modifications malveillantes dans le code tiers, les outils ou d'autres dépendances sur lesquels le système s'appuie.

A04:2025 – Défaillances cryptographiques

D'une manière générale, toutes les données en transit doivent être chiffrées à la couche de transport (couche 4 du modèle OSI). Les obstacles antérieurs, tels que les performances CPU et la gestion des clés privées/certificats, sont désormais gérés par des CPU disposant d'instructions conçues pour accélérer le chiffrement (par ex. prise en charge AES) et par la simplification de la gestion des clés privées et des certificats grâce à des services comme LetsEncrypt.org, tandis que les grands fournisseurs cloud proposent des services de gestion de certificats encore plus étroitement intégrés pour leurs plateformes spécifiques.

Au-delà de la sécurisation de la couche de transport, il est important de déterminer quelles données nécessitent un chiffrement au repos et quelles données nécessitent un chiffrement supplémentaire en transit (à la couche application, couche 7 du modèle OSI).

Par exemple, les mots de passe, les numéros de cartes de crédit, les dossiers médicaux, les informations personnelles et les secrets d'affaires nécessitent une protection supplémentaire, en particulier si ces données sont soumises à des lois sur la vie privée, comme le Règlement général sur la protection des données (RGPD) de l'UE, ou à des réglementations telles que le PCI Data Security Standard (PCI DSS).

Aspects pratiques

• Analyse détaillée des défaillances cryptographiques, telles que les algorithmes de chiffrement faibles ou la mauvaise gestion des clés

• Importance des mécanismes cryptographiques robustes, des protocoles sécurisés (SSL/TLS) et exemples de cryptographie moderne dans la sécurité web

A05:2025 – Injection

Une vulnérabilité d'injection est un défaut du système qui permet à un attaquant d'insérer un code ou des commandes malveillants (tels que du code SQL ou shell) dans les champs d'entrée d'un programme, trompant le système pour exécuter le code ou les commandes comme s'ils faisaient partie intégrante du système. Cela peut avoir de graves conséquences.

Aspects pratiques

• Décomposition détaillée de l'injection SQL, NoSQL, OS et LDAP

• Techniques d'atténuation à l'aide de déclarations préparées, de requêtes paramétrées et de l'échappement des entrées

A06:2025 – Design insécurisé

Le design insécurisé est une catégorie large représentant différentes faiblesses, exprimées comme « absence ou inefficacité du design des contrôles ».

Le design insécurisé n'est pas la source de toutes les autres catégories de risques du Top Ten. Notez qu'il y a une différence entre un design insécurisé et une implémentation insécurisée. Nous faisons la distinction entre les défauts de conception et les défauts d'implémentation pour une raison : ils ont des causes racines différentes, se produisent à des moments différents du processus de développement et ont des corrections différentes.

Un design sécurisé peut encore présenter des défauts d'implémentation menant à des vulnérabilités potentiellement exploitables. Un design insécurisé ne peut pas être corrigé par une implémentation parfaite, car les contrôles de sécurité nécessaires n'ont jamais été créés pour se défendre contre des attaques spécifiques.

L'un des facteurs contribuant au design insécurisé est le manque de profilage des risques commerciaux inhérent au logiciel ou au système en cours de développement, et donc l'échec à déterminer le niveau de design de sécurité requis.

Aspects pratiques

• Nous explorerons les défauts de conception qui peuvent mener à des vulnérabilités, comme la validation des entrées inappropriée

• Nous étudierons les stratégies d'architecture sécurisée et les principes de design sécurisé

A07:2025 – Défaillances d'authentification

Lorsqu'un attaquant parvient à tromper un système pour qu'il reconnaisse un utilisateur invalide ou incorrect comme légitime, cette vulnérabilité est présente.

Aspects pratiques

• Problèmes d'authentification courants

• Stratégies d'authentification sécurisées, comme l'authentification multi-facteurs et la bonne gestion des sessions

A08:2025 – Défaillances d'intégrité du logiciel ou des données

Les défaillances d'intégrité du logiciel et des données concernent le code et l'infrastructure qui ne protègent pas contre le traitement de code ou de données invalides ou non fiables comme s'ils étaient fiables et valides.

Un exemple de cela est une application qui s'appuie sur des plugins, des bibliothèques ou des modules provenant de sources non fiables, de dépôts et de réseaux de diffusion de contenu (CDN).

Un pipeline CI/CD non sécurisé qui ne consomme pas et ne fournit pas de vérifications d'intégrité du logiciel peut introduire le potentiel d'accès non autorisé, de code non sécurisé ou malveillant, ou de compromission du système.

Un autre exemple est un pipeline CI/CD qui récupère du code ou des artefacts de lieux non fiables et/ou ne les vérifie pas avant utilisation (en vérifiant la signature ou un mécanisme similaire).

Aspects pratiques

• Focus sur des problèmes comme les mises à jour logicielles non fiables et la falsification de données

• Mécanismes de mise à jour sûrs et vérifications de l'intégrité des données

A09:2025 – Défaillances de journalisation et d'alerte de sécurité

Sans journalisation et surveillance, les attaques et les violations ne peuvent pas être détectées, et sans alerte, il est très difficile de répondre rapidement et efficacement lors d'un incident de sécurité.

Une journalisation, une surveillance continue, une détection et des alertes insuffisantes pour initier des réponses actives se produisent à tout moment.

Aspects pratiques

• Importance de la journalisation des informations pertinentes pour la sécurité et de la surveillance des activités suspectes

• Outils et pratiques pour une journalisation appropriée et une surveillance en temps réel pour détecter tôt les violations

A10:2025 – Mauvaise gestion des conditions exceptionnelles

La mauvaise gestion des conditions exceptionnelles dans le logiciel se produit lorsque les programmes échouent à prévenir, détecter et répondre à des situations inhabituelles et imprévisibles, ce qui entraîne des plantages, des comportements inattendus et parfois des vulnérabilités.

Cela peut impliquer une ou plusieurs des trois défaillances suivantes :

• L'application ne prévient pas la survenue d'une situation inhabituelle

• Elle ne identifie pas la situation alors qu'elle se produit

• Elle répond mal ou ne répond pas du tout à la situation par la suite

SAST – Tests statiques de sécurité des applications

1. Qu'est-ce que l'analyse statique et quand l'exécuter dans le cycle de vie du développement logiciel (SDLC) (shift left)/p>

2. Types de vulnérabilités détectables par SAST, code vulnérable vs code sécurisé

3. Aperçu des outils SAST (par ex. Semgrep, SonarQube, Checkmarx, selon la pile technologique du client)/p>

4. Exercice pratique : exécuter un scan SAST sur un dépôt avec des vulnérabilités introduites intentionnellement, interpréter les résultats, trier les faux positifs par rapport aux vulnérabilités réelles

DAST – Tests dynamiques de sécurité des applications

1. Différence entre SAST et DAST, test boîte noire sur l'application en cours d'exécution

2. Flux du scan DAST, exploration (crawling), brouillage (fuzzing), analyse des réponses

3. Aperçu des outils DAST (par ex. OWASP ZAP, Burp Suite)/p>

4. Exercice pratique : exécuter un scan DAST sur une application de test vulnérable (par ex. OWASP Juice Shop), identifier et valider les constats

SCA – Analyse de composition du logiciel

1. Risque des dépendances et bibliothèques tierces, vulnérabilités héritées

2. SBOM (Software Bill of Materials), ce que c'est et pourquoi c'est important

3. Aperçu des outils SCA (par ex. Dependency Check, Snyk, GitHub Dependabot)/p>

4. Exercice pratique : exécuter un scan SCA sur un projet réel, identifier les dépendances vulnérables et élaborer un plan de correction (mise à jour, correctif, atténuation)/p>