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

A01:2025 – Contrôle d'accès défaillant

Le contrôle d'accès applique une politique selon laquelle les utilisateurs ne peuvent pas agir en dehors de leurs autorisations prévues. Les défaillances entraînent généralement la divulgation non autorisée, la modification ou la destruction de toutes les données, ou l'exécution d'une fonction métier au-delà 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 – Mauvaise configuration de la sécurité

Une mauvaise configuration de la sécurité se produit 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

• Mesures pour prévenir les mauvaises configurations, y compris l'utilisation d'outils de gestion de configuration et 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 ruptures ou autres compromissions dans le processus de construction, de distribution ou de mise à jour des logiciels. 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 lesquelles le système s'appuie.

A04:2025 – Échecs cryptographiques

En général, toutes les données en transit doivent être chiffrées à la couche de transport (couche 4 du modèle OSI). Les obstacles précédents, tels que la performance du processeur et la gestion des clés privées/certificats, sont désormais pris en charge par des processeurs dotés d'instructions conçues pour accélérer le chiffrement (par exemple la prise en charge de l'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 principaux fournisseurs cloud offrent des services de gestion des 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 et quelles données nécessitent un chiffrement supplémentaire en transit (à la couche d'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'entreprise nécessitent une protection supplémentaire, en particulier si ces données relèvent de lois sur la vie privée, comme le Règlement général sur la protection des données (RGPD) de l'UE, ou de normes telles que le Norme de sécurité des données des cartes de paiement (PCI DSS).

Aspects pratiques

• Analyse détaillée des échecs cryptographiques tels que les algorithmes de chiffrement faibles ou une gestion inadéquate 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 malveillantes (tels que du code SQL ou shell) dans les champs d'entrée d'un programme, induisant le système à exécuter le code ou les commandes comme s'ils faisaient partie du système. Cela peut avoir des conséquences très graves.

Aspects pratiques

• Explication détaillée des injections 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 – Conception insécurisée

La conception insécurisée est une catégorie large représentant diverses faiblesses, exprimées comme une « conception de 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 10. Notez qu'il y a une différence entre une conception insécurisée et une implémentation insécurisée. Nous distinguons les défauts de conception des défauts d'implémentation pour une bonne raison : ils ont des causes profondes différentes, se produisent à différents moments du processus de développement et nécessitent des remédiations différentes.

Une conception sécurisée peut tout de même comporter des défauts d'implémentation menant à des vulnérabilités pouvant ê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 qui contribuent à une conception insécurisée est le manque de profilage des risques métier inhérent au logiciel ou au système en cours de développement, et par conséquent, l'échec à déterminer le niveau de conception de sécurité requis.

Aspects pratiques

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

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

A07:2025 – Échecs d'authentification

Lorsqu'un attaquant réussit à 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 multifactorielle 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 fait que du code ou des données invalides ou non fiables soient traités comme fiables et valides.

Un exemple de cela est lorsqu'une application 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 distribution de contenu (CDN).

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

Un autre exemple est un CI/CD qui extrait du code ou des artefacts de lieux non fiables et/ou qui 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 des données

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

A09:2025 – Défaillances de journalisation et de signalisation de sécurité

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

La journalisation, la surveillance continue, la détection et l'alerte 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 afin de détecter les violations tôt

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 à 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 défaillances suivantes :

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

• Elle ne détecte pas la situation lorsqu'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 de développement logiciel (SDLC) (approche « shift left »)

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

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

4. Exercice pratique : exécuter une analyse SAST sur un dépôt avec des vulnérabilités introduites délibérément, interpréter les résultats, catégoriser les faux positifs vs les vraies vulnérabilités

DAST – Tests dynamiques de sécurité des applications

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

2. Flux de l'analyse DAST, exploration (crawling), floutage (fuzzing), analyse des réponses

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

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

SCA – Analyse de composition logicielle

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

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

3. Aperçu des outils SCA (par exemple Dependency Check, Snyk, GitHub Dependabot)

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