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

A01:2025 – Rupture de contrôle d'accès

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

Aspects pratiques

• Exemples concrets de ruptures de contrôle d'accès

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

A02:2025 – Mauvaise configuration de la sécurité

Une mauvaise configuration de la sécurité survient lorsqu'un système, une application ou un service cloud est configuré de manière incorrecte 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 mauvaises configurations, 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 interruptions ou des 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 repose.

A04:2025 – Défaillances cryptographiques

En général, toutes les données en transit doivent être chiffrées à la couche de transport (couche 4 de OSI). Les obstacles antérieurs, tels que la performance du CPU et la gestion des clés privées/certificats, sont désormais gérés par des processeurs disposant d'instructions conçues pour accélérer le chiffrement (par exemple, la prise en charge de AES) et une simplification de la gestion des clés privées et des certificats par des services tels que LetsEncrypt.org, avec des fournisseurs cloud majeurs offrant des services de gestion de certificats encore plus 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 ainsi que quelles données nécessitent un chiffrement supplémentaire en transit (à la couche applicative, couche 7 de 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'entreprise 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 Standard de Sécurité des Données PCI (PCI DSS).

Aspects pratiques

• Analyse détaillée des défaillances cryptographiques, telles que les algorithmes de chiffrement faibles ou une 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 – Injections

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

Aspects pratiques

• Décomposition détaillée des injections SQL, NoSQL, OS et LDAP

• Techniques d'atténuation utilisant des instructions préparées, des requêtes paramétrées et l'échappement des saisies

A06:2025 – Conception insécurisée

La conception insécurisée est une catégorie large représentant différentes faiblesses, exprimées comme une « conception des contrôles manquante ou inefficace ».

La conception insécurisée n'est pas la source de toutes les autres catégories de risques du Top Ten. Notez qu'il existe une différence entre conception insécurisée et implémentation insécurisée. Nous distinguons les défauts de conception et les défauts d'implémentation pour une raison précise : ils ont des causes racines différentes, surviennent à différents moments du processus de développement et ont des remédiations différentes.

Une conception sécurisée peut encore présenter des défauts d'implémentation entraînant des vulnérabilités qui peuvent être exploitées. Une conception insécurisée ne peut pas être corrigée 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 à une conception insécurisée est le manque de profilage des risques d'entreprise inhérent au logiciel ou au système en cours de développement, et donc l'échec à déterminer le niveau de conception de sécurité requis.

Aspects pratiques

• Nous explorerons les défauts de conception pouvant entraîner des vulnérabilités, comme la validation des saisies inappropriée

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

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 courants d'authentification

• Stratégies d'authentification sécurisées, comme l'authentification multifacteur et la gestion appropriée des sessions

A08:2025 – Défaillances d'intégrité logicielle ou de données

Les défaillances d'intégrité logicielle et de données concernent le code et l'infrastructure qui ne se protègent pas contre le fait que des codes ou des données invalides ou non fiables soient traités comme fiables et valides.

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

Une pipeline CI/CD insécurisée sans vérifier l'intégrité logicielle consommée et fournie peut introduire le potentiel d'accès non autorisé, de code insécure ou malveillant, ou de compromission du système.

Un autre exemple est une 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 tels que les mises à jour logicielles non fiables et la falsification de données

• Mécanismes de mise à jour sûrs et contrôles d'intégrité des données

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

Sans journalisation et supervision, 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 insuffisante, une surveillance continue, une détection et des alertes pour initier des réponses actives sont nécessaires à tout moment.

Aspects pratiques

• Importance de journaliser les informations pertinentes pour la sécurité et de surveiller les 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 les logiciels se produit lorsque les programmes échouent à prévenir, détecter et répondre aux 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 3 carences suivantes :

• L'application n'empêche pas une situation inhabituelle de se produire

• Elle n'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 – Static Application Security Testing

1. Ce qu'est l'analyse statique et quand l'exécuter dans le SDLC (décalage à gauche)

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

3. Aperçu des outils SAST (par exemple, Semgrep, SonarQube, Checkmarx, selon la stack du client)

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

DAST – Dynamic Application Security Testing

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

2. Flux du scan DAST, crawler, fuzzing, analyse des réponses

3. Aperçu des outils DAST (par exemple, OWASP ZAP, Burp Suite)

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

SCA – Software Composition Analysis

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 exemple, Dependency Check, Snyk, GitHub Dependabot)

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