FORMATION

CONCEPTION SECURISEE DES APPLICATIONS

Du 24 au 28 Février 2025, Ouagadougou

1
 FORMATEUR

Seriba Barro

Ingénieur Senior Cybersécurité

Consultant, Formateur
Gérant cabinet IT PROTECT CONSULTING

Domaines de compétences

Stratégie de sécurité d’entreprise & sécurité opérationnelle

Architecture réseau
Management des opérations IT
Conception des applications

2
 Présentation des participants
➢ Nom & Prénom
➢ Fonction/emploi
➢ Attentes de la formation
➢ Connaissance/ expérience en cybersécurité

Directives
Chef de classe
Horaires
Participation active de tous
Ouverture d’esprit a de nouvelles idées
Respect mutuel
Partage d’expérience
Ponctualité et assiduité

3
 PRESENTATION DU CABINET IT PROTECT CONSULTING

IT PROTECT CONSULTING est un cabinet de sécurité informatique qui offre des services
d’expertises et innovants dans la modernisation et la sécurisation des systèmes
d’information.
Mission du cabinet
Accompagner les entreprises dans la modernisation et la sécurisation de leurs systèmes
d’information afin de mettre des solutions secure by design.
Moderniser= Améliorer l’architecture informatique existante afin de
répondre aux objectifs actuels et futurs de l’entreprise
Sécuriser= étude & élaboration d’une stratégie de sécurité
d’entreprise et implémentation des solutions techniques
de sécurité

➢ IT Protect accompagne également les entreprises pour renforcer les

compétences techniques et opérationnelles de leurs employés

4
OBJECTIF GENERAL :

➢ Intégrer la sécurité dans le cycle de vie des applications

➢ Utiliser un processus de conception sécurisé des applications pour prévenir les

vulnérabilités connues

OBJECTIFS SPECIFIQUES :

➢ Concevoir une application Secure by design

➢ Maîtriser les standards et les bonnes pratiques dans le cycle de vie du développement
logiciel

➢ Savoir appliquer le Threat Modeling

➢ Connaitre les exigences de sécurité de chaque phase du cycle de vie du développement

logiciel

5
➢ Connaitre les principales failles de sécurité des applications Web OWASP

➢ Connaitre les principales failles de sécurité des applications mobile OWASP

➢ Savoir utiliser un outil SAST pour l’analyse statique du code source

➢ Savoir utiliser un outil DAST pour l’analyse dynamique d’une application

6
 PLAN DE TRAVAIL
JOUR1

Introduction à la sécurité des systèmes d’information

Les exigences de sécurité des phases du SDLC
Le cycle de vie du développement sécurisé chez Microsoft
JOUR2

Le Threat Modeling pour identification des menaces et des vulnérabilités

Analyse de la surface d’attaque
Etude de cas

JOUR3

démarche OWASP et sécurité des applications web

JOUR4

OWASP et sécurité des applications mobiles

DevOps security
Présentation de la démarche sécure coding

7
Simulation d’une attaque SQL Injection
JOUR5

Analyse de code source avec outil SAST (SONARQUBE)

Analyse d’une application avec outil DAST(OWASP ZAP)

INTRODUCTION A LA SECURITE DES S.I

Définition
La sécurité des systèmes d’information (SSI) est l’ensemble des moyens techniques,
organisationnels, juridiques et humains nécessaires et mis en place pour sécuriser le système
d’information contre un certain nombre de menaces et nuisances existantes ou potentielles.

8
Objectifs de la sécurité des systèmes d’information
➢ CONFIDENTIALITE
➢ INTEGRITE
➢ DISPONIBILITE
Fonctions associées
➢ Authentification
➢ Non-repudiation

Quelques définitions importantes

Vulnérabilité : une vulnérabilité est un manque de protection ou une défaillance dans la protection
Common Vulnerabilities and Exposures Database (CVE Database), supervisée par l’organisme
MITRE.
National Vulnerability Database (NVD) de l’organisme NIST : détails techniques des vulnérabilités
Menace : Une menace (threat en Anglais) est n’importe quel évènement pouvant vous porter un
préjudice. C’est tout danger potentiel.

9
Risque : Le risque (risk en Anglais) est la conjonction de la vulnérabilité et de la menace et son
impact sur l’entreprise.

Principales sources de vulnérabilité

➢ Défaut de conception
➢ Défaillance dans la configuration
➢ Panne technique
Exemples :
➢ Conception niveau système
➢ Conception des OS
➢ Conception des applications
➢ Configuration non adéquate d’un firewall
➢ Configuration non optimale d’un serveur
➢ Utilisation d’un firewall non adéquat dans la protection des services
➢ Panne d’un serveur ou d’un composant

Principales catégories de solutions de sécurité

➢ Préventives
➢ Dissuasives

10
 ➢ Detectives
➢ Correctives

Les enjeux d'un système d'information

Enjeux stratégiques & opérationnels
➢ Améliorer et optimiser la production
➢ Automatiser les processus
➢ Outil de communication & de collaboration
➢ Ouverture vers l’extérieur
Quelques types d’attaques du Système d’Information
➢ Attaques applicatives
➢ Logiciel malveillant
➢ Ingénierie sociale
➢ Attaque DOS/DDoS
➢ MiTM
➢ Etc.
Types de solution de cybersécurité
➢ Sécurité du réseau
➢ Sécurité applicative

11
 ➢ Sécurité physique
➢ Sécurité de l’Internet des objets
➢ Sécurité mobile
➢ Sécurité des postes de travail
➢ Sécurité des données
Les profils des attaquants et leurs objectifs
➢ Black Hat hackers
➢ White Hat hackers
➢ Gray Hat hackers
➢ Script kiddies
➢ APT
Les méthodes et les outils des attaquants
➢ Utilisation de logiciels malveillants
➢ Ingénierie sociale
➢ Outils de scans de réseaux
➢ Outils de scan de vulnérabilité
Les vecteurs d'attaque d'un système d'information
➢ Vecteur d’attaque : voie utilisée par un hacker pour accéder à une ressource illégalement
➢ Messagerie électronique

12
 ➢ Ingénierie sociale
➢ Vol de paramètres de connexion
➢ Logiciel malveillant

Les différentes phases d'une attaque (Cyber Kill Chain)

13
14
 LES EXIGENCES DE SECURITE DU SDLC

Définition du SDLC
Le cycle de vie du développement logiciel (SDLC ) est un processus structuré qui permet de
développer des logiciels de haute qualité, à faible cout et dans les meilleurs délais.
La collecte ou définition des exigences répond aux questions :
Pourquoi ? pourquoi créer cette application
Quoi ? Qu’est-ce que l’application va faire
Qui ? pour qui l’application est créée
La conception
Elle répond à la question comment ? comment l’application va accomplir les objectifs
précédemment identifiés.
Le développement
Detaille en code source les spécifications du modèle établi.
Test/Validation

15
Valider l’application en s’assurant que les objectifs sont correctement realises et que l’application
fonctionne comme prevu.
Release/Maintenance
Déployer l’application et s’assurer qu’elle est bien configuree, patche et monitore.

Pourquoi parle-t-on de SDLC sécurisé ?

According to GitLab half of security professionals in 2023 report that developers fail to identify 75%
of vulnerabilities.

Vrai ou Faux ???

Il existe une différence entre une conception non sécurisée et une implémentation non sécurisée.
Nous différencions les défauts de conception et les défauts d'implémentation car ils ont des
causes racines et des mesures correctives différentes.
Une conception sécurisée peut toujours présenter des défauts d'implémentations conduisant à
des vulnérabilités pouvant être exploitées.

16
Une conception non sécurisée ne peut pas être corrigée par une implémentation parfaite car, par
définition, les contrôles de sécurité nécessaires n'ont jamais été créés pour se défendre contre des
attaques spécifiques.

17
Qu’est-ce que le SDLC sécurisé ?
Le SDLC sécurisé intègre la sécurité dans le processus du SDLC, ce qui signifie que les exigences
de sécurité sont recueillies en même temps que les exigences fonctionnelles.

18
Les exigences de sécurité du SDLC Sécurisé
➢ Utilisez un processus de développement sécurisé pour prévenir les vulnérabilités applicatives
connues et utiliser les contrôles de sécurité pour réduire ou solutionner les vulnérabilités
imprévues
➢ La mise en œuvre de la sécurité du SDLC concerne chaque phase du cycle de vie
➢ Cette methode est beaucoup plus efficace et beaucoup moins coûteuse
➢ Ce processus du cycle de vie de développement logiciel la sécurité en tant que composant
de chaque phase du SDLC.
➢ Les exigences de sécurité de l’application sont définies en termes de confidentialité, intégrité
et de disponibilité

Exigences de sécurité de la phase de collecte d’information

➢ Dans cette première étape, il s’agit d’identifier les besoins de sécurité en même temps que
les fonctionnalités.
➢ Il est important d’identifier toutes les considérations de sécurité pour les exigences
fonctionnelles recueillies.
➢ Les considérations en matière de sécurité à prendre en compte sont les suivantes :
▪ Les exigences de sécurité (standards & règlements, politique de sécurité, chiffrement,
RBAC etc)

19
 ▪ Evaluation des risques de sécurité
▪ Evaluation des risques liés à la vie privée
▪ Niveau de risque acceptable ( par exemple risque dont l’impact est faible et la
probabilité est faible)
➢ Les questions dépendent du type d’application, du type de business, de l’environnement etc.
▪ L’application traite-t-elle des données sensibles (bancaires, médicales, etc.)
▪ Quel type de sécurité est requise pour l’application et à quel degré ?
➢ L’application est-elle exposée publiquement ?
➢ Exemple
▪ Exigence fonctionnelle : le client doit pouvoir vérifier le solde de son compte bancaire
▪ Exigence de sécurité associée : Le client ne peut accéder qu’à son compte en mode
lecture seule

➢ Après une évaluation des risques de sécurité lies à la vie privée, on peut passer à une
évaluation d’impact sur la vie privée

P1 Niveau de risque élevé lié à la vie privée

Le système enregistre ou transfère des données PII

20
 P2 Niveau de risque modéré

P3 Niveau de risque bas

Les critères du niveau de risque acceptable doivent être élaborés pour s’assurer que les efforts de
réduction des risques sont priorisés.

Exigences de sécurité de la phase de conception

➢ La phase de conception traduit les exigences fonctionnelles de façon concrète de
l’application
➢ Les exigences fonctionnelles décrivent ce que doit se produire
➢ Les considérations de sécurité de cette phase sont les suivantes :
▪ Le Threat Modeling (modélisation des menaces)
▪ Attack surface analysis( analyse de la surface d’attaque)

21
➢ La modélisation des menaces est une activité structurée qui a pour but d’identifier, d’évaluer
et de gérer les menaces du système, les défauts de conception de l’architecture et de
recommander des mesures de sécurité.
➢ La surface d'attaque d’un système peut être décrite comme l’ensemble des points d'entrée et
de communication qu'un système possède avec l'extérieur.
➢ Objectif de l’analyse de la surface d’attaque est d’identifier et de réduire la quantité de code
ou le nombre de fonctionnalités accessibles à un utilisateur non fiable.

22
Exigences de sécurité de la phase de développement
Les faiblesses, problèmes ou défauts de codage d’ordre général

23
[Link]

24
25
26
 ➢ Les exigences de sécurité de cette phase sont catégorisées comme suit :

▪ Les exigences CID

▪ Les exigences du triple AAA
▪ La gestion des sessions
▪ La validation des entrées utilisateur
▪ La gestion des exceptions et des erreurs
▪ Utilisation de code tiers
▪ La gestion de la mémoire
▪ Etc
En plus de la mise en œuvre sécurisée des fonctionnalités ci-dessus, les activités suivantes font
partie de la phase de développement :
▪ L’analyse statique du code source
▪ La revue de code

La phase de test/validation
Cette phase comporte essentiellement les différents types de tests.

27
 ▪ Test unitaire
▪ Test d’intégration
▪ Test d’acceptance
▪ Test de régression

La phase de release/maintenance
➢ Une fois l’application déployée, des problèmes d’interopérabilités peuvent apparaitre ou
même certaines configurations peuvent impacter sur des fonctionnalités.
➢ Un plan de changement et de réponse aux incidents doit être prévu. Les besoins de
changement doivent être pris en compte dans le code, le code alors re-testé et redéployé en
respectant les procédures.

28
 LE CYCLE DE VIE DU DEVELOPPEMENT LOGICIEL CHEZ MICROSOFT
Le cycle de vie du développement logiciel de Microsoft

Microsoft utilise un modèle en 7 phases pour produire des applications sécurisées et moins
couteuse
➢ Formation
➢ Prise en compte des exigences
➢ Architecture/Modélisation
➢ Implémentation/Développement
➢ Vérification
➢ Release/publication
➢ Réponse

29
The Microsoft Security Development Lifecycle - Simplified

30
 LE THREAT MODELING

➢ Dans le paysage complexe des cybermenaces actuel, les organisations ont besoin
d’approches structurées pour identifier, analyser et atténuer les risques potentiels pour la
sécurité
➢ La modélisation des menaces (Threat Modeling) est une activité fondamentale pour identifier
et traiter les failles dès la conception avant la phase de développement d’un logiciel ou d’un
système
➢ L’approche de la modélisation des menaces cherche à identifier ceux qui sont susceptible de
nous attaquer et comment ils peuvent parvenir à réussir cela

➢ Le threat modeling s’applique à chaque categorie de bien de l’entreprise : les équipements

mobiles, les serveurs, le réseau, les applications & bases de données, etc

➢ La modélisation des menaces est une approche proactive de la cybersécurité qui aide les
organisations à identifier et à traiter les menaces de sécurité potentielles

31
 ➢ Contrairement aux évaluations de sécurité traditionnelles qui peuvent se concentrer
uniquement sur les vulnérabilités actuelles, la modélisation des menaces adopte une
approche proactive et prospective
Les avantages de la modélisation des menaces
➢ gestion proactive des risques : Au lieu de réagir aux menaces après qu’elles se
produisent, la modélisation des menaces permet d’identifier et de traiter les
vulnérabilités dès le début du cycle de vie du développement. Cette approche proactive
réduit la probabilité de violations et les coûts de résolution.

➢ Prioriser les efforts de sécurité : toutes les menaces ne sont pas égales en termes
d’impact et de probabilité. La modélisation des menaces permet aux organisations de
classer les risques et d’allouer les ressources efficacement, en se concentrant sur les
vulnérabilités les plus critiques.

➢ Soutenir la conformité réglementaire : De nombreux secteurs sont soumis à des

réglementations strictes en matière de protection des données (par exemple, RGPD,
HIPAA). La modélisation des menaces permet de s’assurer que les mesures de sécurité
répondent aux exigences réglementaires en identifiant les lacunes et en documentant
les efforts de gestion des risques

32
 ➢ Amélioration de la communication entre les équipes : Les modèles de menaces
fournissent un cadre commun pour discuter des risques de sécurité entre les équipes
de développement, informatiques et de sécurité. Cette compréhension partagée
favorise la collaboration et accélère la résolution des problèmes de sécurité
Un modèle de menace complet se compose généralement des composants suivants :
➢ Actifs : Il s’agit d’éléments précieux qui doivent être protégés, comme les données sensibles,
la propriété intellectuelle ou les fonctions critiques du système
➢ Menaces : Les menaces représentent des dangers qui pourraient nuire aux actifs.
➢ Vulnérabilités : Toute faiblesse du système pourrait être exploitée par des menaces.
L’identification des vulnérabilités est essentielle pour comprendre comment un hacker peut
obtenir un accès non autorisé ou perturber les services.
➢ Vecteurs d’attaque : Il s’agit des chemins ou des méthodes que les attaquants peuvent
utiliser pour exploiter les vulnérabilités. Les vecteurs d’attaque courants incluent les e-mails,
les vulnérabilités logicielles et les contrôles d’accès mal configurés.
➢ Atténuations : Il s’agit de mesures de sécurité qui peuvent réduire la probabilité ou l’impact
d’une menace exploitant une vulnérabilité. Par exemple le chiffrement, la segmentation
réseau et l’authentification sont des mesures d’atténuation.
➢ Évaluation des risques : L’évaluation de l’impact potentiel et de la probabilité de chaque
menace permet de prioriser la mise en œuvre des mesures d’atténuation. Ce processus

33
 consiste généralement à évaluer les menaces en fonction de facteurs tels que le potentiel de
dommages et l’exploitabilité.
Les méthodes de modélisation des menaces
➢ Plusieurs méthodologies existent parmi lesquelles nous avons STRIDE, PASTA, DREAD
STRIDE
➢ STRIDE est développé par Microsoft et orienté menace.

Violation du principe Description

de sécurité

S Spoofing Authentification Attaquant prétend être quelque chose ou quelqu’un pour

avoir accès

T Tampering Intégrité Attaquant modifies les donnes au repos ou en transit

R Repudiation Nonrepudiation Attaquant exécute une action sur un système qui ne lui est
pas attribuable

I Information disclosure Confidentialité L’attaquant peut avoir accès à des données sensibles

D Denial of service Disponibilité L’attaquant empêche l’accès au

système par les utilisateurs

34
 E Elevation of privilege autorisation L’attaquant gagne des droits d’acces eleves

PASTA
➢ PASTA (Process for Attack Simulation and Threat Analysis), contrairement à STRIDE, est une
méthodologie focalisée sur l’attaquant et centrée sur les risques

➢ Il est plus détaillé que STRIDE et analyse les menaces d’un point de vue stratégique

➢ PASTA est une méthodologie en 7 phases

1 Définition des objectifs

2 Définition du périmètre technique

35
 3 Décomposition de l'application

4 Analyse des menaces

5 Analyse des vulnérabilités et des faiblesses

6 Modélisation des attaques

7 Analyse des risques et des impacts

Etapes pour créer un modèle de menace

➢ PASTA suit une approche systématique en sept étapes distinctes, chacune s’appuyant sur la
précédente pour créer un modèle de menace complet

36
Définition des objectifs
➢ La première étape consiste à aligner les initiatives de sécurité sur les objectifs de l’entreprise
➢ Les principales activités sont les suivantes :

▪ Identifier les objectifs commerciaux critiques et leurs implications en matière de

sécurité
▪ Définir des exigences de sécurité et des besoins de conformité spécifiques
▪ Établir des indicateurs de réussite pour le processus de modélisation des menaces
▪ Déterminer les parties prenantes clés et leurs rôles

Définition du périmètre technique

➢ L’étape du périmètre technique consiste à cartographier les composants, l’architecture, les
flux de données et les limites du système afin de mieux comprendre l’environnement
technique

➢ Voici quelques-unes des activités proposées :

▪ Documenter tous les composants du système et leurs interactions

▪ Identifier les flux de données et les limites de confiance
▪ Créer une documentation technique détaillée
▪ Établir le périmètre de l’analyse

37
Décomposition de l’application
➢ Au cours de cette étape, l’accent est mis sur la compréhension du fonctionnement interne de
l’application
➢ L’application est divisée en composants plus petits pour comprendre l’architecture de
l’application, notamment les modules, les magasins de données et les canaux de
communication :
▪ Décomposer l’application en composants centraux
▪ Analyse des flux de données entre les composants
▪ Identifier les contrôles de sécurité et leur placement
▪ Documentation des dépendances et des points d’intégration
Analyse des menaces
➢ Cette étape consiste à identifier les menaces potentielles susceptibles d’exploiter les
vulnérabilités du système
➢ Des techniques telles que le brainstorming, l’utilisation de bibliothèques de menaces (p. ex.
Top 10 OWASP) sont utilisées
➢ L’objectif est de créer une liste exhaustive des menaces possibles, qui peuvent ensuite être
priorisées en fonction de leur impact potentiel sur le système
➢ L’étape d’analyse des menaces implique :
▪ Identifier les acteurs potentiels des menaces et leurs motivations
▪ Analyser les schémas et techniques d’attaque

38
 ▪ Créer des profils de menaces basés sur des données historiques et des informations
sectorielles
▪ Cartographie des menaces sur des composants systèmes spécifiques
➢ Cette étape aide les organisations à comprendre qui pourrait les attaquer et quelles sont les
méthodes qu’elles pourraient utiliser, ce qui permet d’élaborer des stratégies de défense plus
ciblées
Analyse de vulnérabilité/faiblesse
➢ Cette étape vise à identifier les faiblesses spécifiques qui pourraient être exploitées par les
menaces identifiées à l’étape précédente
➢ Cette étape critique implique :
▪ Réalisation des évaluations complètes des vulnérabilités
▪ Analyse des faiblesses du système et des défauts de conception
▪ Cartographier les vulnérabilités en fonction des menaces identifiées
▪ Prioriser les vulnérabilités en fonction de l’impact potentiel
Modélisation et simulation des attaques
➢ A ce stade, les attaques potentielles sont modélisées pour simuler les actions qu’un hacker
pourrait entreprendre
➢ L’étape de modélisation des attaques rassemble les menaces et les vulnérabilités :
▪ Créer des scénarios d’attaque détaillés
▪ Simuler des chemins d’attaque potentiels

39
 ▪ Tester les contrôles de sécurité dans différentes conditions
▪ Validation de l’efficacité des défenses existantes

Analyse des risques et de l’impact

➢ La dernière étape consiste à quantifier les risques associés aux menaces et vulnérabilités
identifiées
➢ Il s’agit notamment d’évaluer les dommages potentiels et la probabilité de chaque risque, à
l’aide de matrices de risques ou d’autres méthodes quantitatives
▪ Calcul de l’impact potentiel des menaces identifiées pour l’entreprise
▪ Évaluer la probabilité de réussite des attaques
▪ Hiérarchiser les risques en fonction de leur impact
▪ Développement de stratégies d’atténuation des risques
➢ Cette analyse aide les organisations à prendre des décisions éclairées concernant les
investissements en matière de sécurité et l’acceptation des risques

➢ Les résultats sont utilisés pour prioriser les efforts d’atténuation en fonction des risques les
plus importants.
Outils de modélisation des menaces
➢ Divers outils sont disponibles pour faciliter la création de modèles de menace
➢ Voici quelques-unes des options les plus populaires :

40
 ▪ Outil de modélisation des menaces Microsoft : cet outil gratuit aide les utilisateurs à
créer des diagrammes de flux de données et à identifier les menaces à l’aide de STRIDE

▪ OWASP Threat Dragon : cet outil open source prend en charge la modélisation des
menaces par diagramme. Il permet une visualisation facile des menaces et s’intègre à
GitHub pour le contrôle de version

▪ ThreatModeler : Cette solution complète de modélisation des menaces s’intègre aux

flux de travail DevOps, ce qui permet une gestion continue des menaces tout au long du
cycle de développement logiciel.

Bonnes pratiques pour une modélisation efficace des menaces

➢ Pour optimiser les avantages de la modélisation des menaces :
▪ Intégrez la modélisation des menaces dès le début du cycle de vie du développement
▪ La résolution précoce des risques de sécurité peut réduire considérablement les coûts
de correction et minimiser les vulnérabilités en production
▪ Adoptez une approche collaborative : Impliquez plusieurs parties prenantes,
notamment des développeurs, des experts en sécurité et des analystes métier

41
 ▪ Tirez parti des outils automatisés lorsque cela est possible : Les outils automatisés de
modélisation des menaces peuvent accélérer le processus et garantir la cohérence, en
particulier pour les systèmes volumineux ou complexes
▪ Mettre à jour régulièrement le modèle de menace : les modèles de menace doivent être
traités comme des documents vivants qui évoluent avec le système. Des mises à jour
régulières garantissent leur exactitude et leur pertinence
▪ Hiérarchiser en fonction du risque : toutes les menaces ne nécessitent pas une action
immédiate. Utilisez des techniques d’évaluation des risques pour vous concentrer
d’abord sur les problèmes les plus critiques, afin de garantir une utilisation efficace des
ressources

Les étapes de modélisation des menaces

Phase 1 : Définition du périmètre de travail
Phase 2 : Détermination des menaces
Phase 3 : Détermination des contremesures
Phase 4 : Evaluation du travail

Définition du périmètre de travail

42
La première étape du processus de modélisation des menaces consiste à comprendre ce sur quoi
vous travaillez.
Cela peut impliquer de :

➢ Dessiner des diagrammes, souvent des diagrammes de flux de données.

➢ Identifier les points d’entrée pour voir où un attaquant potentiel pourrait interagir avec
l’application
➢ Essayer d’identifier les « ressources »
➢ Identifier les niveaux de confiance qui représentent les droits d’accès que l’application
accordera aux entités externes.
➢ Elaborer un scénario d’abus
Les diagrammes de flux de données (DFD) sont fréquemment utilisés pour montrer sur quoi nous
travaillons. Les DFD montrent les différents chemins à travers le système, en mettant en évidence
les limites de privilèges ou de confiance.
Cela s’appelle parfois « décomposer l’application », une approche que les consultants utilisent
lorsqu’ils sont amenés à effectuer un modèle de menace ou une analyse architecturale. Les
consultants fournissent souvent un résultat sous la forme d’un document de modèle de menace.

43
Détermination des menaces
L’utilisation d’une méthodologie pour catégoriser les menaces est essentielle à l’identification des
menaces. STRIDE est fréquemment utilisé dans la modélisation des menaces, du point de vue de
l’attaquant.

L’objectif de la catégorisation des menaces est d’aider à identifier les menaces provenant de
l’attaquant (STRIDE). Les DFD produits à l’étape 1 aident à identifier les cibles potentielles des
menaces du point de vue de l’attaquant, telles que les sources de données, les processus, les flux
de données et les interactions avec les utilisateurs.

Ces menaces peuvent être organisées plus en détail à l’aide d’arbres de menaces ; il existe un arbre
pour chaque objectif de menace. Des listes de menaces courantes avec des exemples peuvent
aider à identifier ces menaces. Les cas d’utilisation et d’abus peuvent illustrer comment les
mesures de protection existantes pourraient être contournées, ou les cas où une telle protection
est absente.
Détermination des contremesures
Une vulnérabilité peut être atténuée par la mise en œuvre d'une contre-mesure. Ces contre-
mesures peuvent être identifiées à l'aide d’une liste de mappage de menaces et de contre-mesures.
La priorisation des contre-mesures est un sujet complexe.

44
De nombreuses approches existent et les organisations doivent sélectionner celles qui leur
conviennent. Les facteurs fréquemment inclus sont la probabilité d'une attaque, les dommages
causés par une attaque et la complexité ou le coût de la correction.

La stratégie d'atténuation des risques peut impliquer l'évaluation de ces menaces en fonction de
l'impact sur le business qu'elles représentent. Une fois l'impact possible identifié, les options pour
gérer le risque incluent :
Accepter : décider que l'impact sur le business est acceptable
Eviter : supprimer les composants qui rendent la vulnérabilité possible
Atténuer : ajouter des contrôles ou des contrôles qui réduisent l'impact du risque ou les chances de
son apparition
Transférer : transférer le risque à un assureur ou à un client.

Étape 4 : Evaluez votre travail

Tout d’abord, déterminez si vous avez effectué le travail. Existe-t-il du contenu montrant un
diagramme, une liste des menaces et une liste de contrôle ?

45
Proposer un modèle de menaces de compromission de mots de passe d’une application ouvert
sur Internet utilisant une Base de données.

46
47
 LA SURFACE D’ATTAQUE D’UNE APPLICATION

➢ La surface d'attaque d’une application constitue l’ensemble des points d'entrée/sortie d'une
application avec son environnement (OS, librairies, accès en lecture/écriture, etc.)

➢ Évaluer sa surface d’attaque est un préalable à toute bonne politique de sécurité du système
d’information.

➢ L'analyse de la surface d'attaque est simplement le fait d'établir une cartographie précise et
documentée de tous les points d'entrée du système d'information
➢ La surface d’attaque d’une application peut être constituée du OS, serveur BD, applications
tierces, API, etc.

Etude de cas
Un site ecommerce met différents services en ligne pour ses clients;
• un port ouvert;
• les services actifs du serveur;

48
 • etc.

➢ Analyse de la surface d’attaque

port 80 ouvert
Identifier tout ce qui peut être recherché par un attaquant pour profiter de l’exposition de ce port.
Lors de l'analyse de la surface d'attaque, on peut établir une hiérarchie et une suite dans les points
d'entrée. Voici un schéma qui peut illustrer une partie de l'analyse de la surface d’attaque.

49
 @IP:[Link]

Port : 80

Service Apache

App1 App2

Formulaires Formulaires

Ici, l'analyse de la surface d'attaque commence par le point d'entrée qui est l'IP et le port de la
machine.
Également nous avons l’OS du serveur qui pourrait avoir ses propres vulnérabilités

50
Nous avons un service Apache, 2 applications qui tournent pouvant chacune avoir ses propres
vulnérabilités et des points d’entrée supplémentaires.
Sur un service web il peut s'agir de possibilité d'uploader des fichiers, de faire des paiements, de
saisir du texte stocké sur le serveur. Chacun de ces points est une partie de la surface d'attaque.

51
DEMARCHE OWASP POUR LA SECURISATION DES APPLICATIONS WEB

➢ Open Web Application Security Project (OWASP) est une fondation impartiale,
mondiale et à but non lucratif qui constitue un outil pour comprendre et anticiper les
vulnérabilités courantes des applications web

➢ En intégrant la démarche OWASP on peut proactivement prévenir beaucoup de failles

de sécurité pour améliorer la qualité et la fiabilité des applications

➢ Le Top 10 de OWASP, régulièrement mis à jour, liste les vulnérabilités les plus critiques
auxquelles les applications web sont exposées. Ce classement, issu d’un consensus
mondial parmi les experts en cybersécurité, sert de guide pour les développeurs,
les pentesters, et les RSSI.

52
Pourquoi ce Top 10 est-il si crucial ?
➢ Il permet de prioriser les efforts de sécurité en ciblant les menaces les plus fréquentes et les
plus dangereuses

➢ Les tests d’intrusion (ou pentests) sont souvent utilisés pour détecter les vulnérabilités avant
qu’elles ne soient exploitées par des hackers non éthiques

53
54
1. Broken Access Control (contrôle d’accès insuffisant)
➢ Le contrôle d’accès garantit que seuls les utilisateurs autorisés accèdent à certaines
ressources.
➢ Les failles dans ce domaine permettent aux attaquants de contourner les restrictions
d’accès
➢ Le contrôle d'accès applique une stratégie telle que les utilisateurs ne peuvent pas agir en
dehors de leurs autorisations prévues
➢ Les défaillances entraînent généralement la divulgation, la modification ou la destruction
d'informations non autorisées de toutes les données ou l'exécution d'une fonctionnalité
métier en dehors des limites de l'utilisateur

➢ Les vulnérabilités courantes du contrôle d'accès incluent :

▪ Violation du principe du moindre privilège, où l'accès ne doit être accordé que pour
des besoins et des rôles

▪ Contourner les contrôles d'accès en modifiant l'URL (falsification de paramètres ou

navigation forcée), l'état interne de l'application ou la page HTML, ou en utilisant un
outil d'attaque modifiant les requêtes API

▪ Autoriser l'affichage ou la modification du compte de quelqu'un d'autre, en

fournissant son identifiant unique (références directes d'objet non sécurisées)

55
 ▪ Accès à l'API avec des contrôles d'accès manquants

▪ Élévation de privilège. Agir en tant qu'utilisateur sans être connecté ou agir en tant
qu'administrateur lorsqu'il est connecté en tant qu'utilisateur
▪ Manipulation de métadonnées, comme le rejeu ou la falsification de JSON Web
Token (JWT), de cookies ou de champs cachés, afin d'élever les privilèges ou abuser
de l'invalidation JWT
▪ La mauvaise configuration de CORS permettant l'accès à l'API à partir d'origines non
autorisées/non approuvées
▪ Forcer la navigation vers des pages authentifiées en tant qu'utilisateur non
authentifié ou vers des pages privilégiées en tant qu'utilisateur standard

➢ Plusieurs types d'attaques peuvent exploiter ces faiblesses. Nous allons explorer ici trois
types d'attaques spécifiques :
▪ L’attaque par découverte d'URL
▪ Les références directes d'objets non sécurisés (ou IDOR, pour Insecure Direct
Object Reference)
▪ L’attaque CSRF (Cross-Site Request Forgery)

56
L’attaque par découverte d’URL

Description
Imaginez une application web qui distingue deux catégories d'utilisateurs : les « Employés » et les
« Clients », chacun ayant des droits d'accès spécifiques à certaines parties de l'application.
Lorsqu'un client se connecte à l'application, il est dirigé vers une page principale dont l'URL est la
suivante, pour y saisir ses identifiants et mot de passe : [Link] .
Cette URL révèle une structure définie où client_login.html est désigné comme la page de
connexion pour les clients. Cependant, cette apparence inoffensive cache un risque potentiel.
En effet, un attaquant pourrait intuitivement essayer d'accéder à la page de connexion des
employés en modifiant légèrement l'URL, peut-être en essayant quelque chose
comme employee_login.html . Dans cet exemple, il restera encore à saisir des identifiants et mots
de passe valides, mais c’est déjà une étape de moins pour l’attaquant.
Cet exemple met en lumière un problème de sécurité : la prévisibilité et la transparence des URL
peuvent servir d'indices aux personnes malveillantes.
L’attaque par références directes d’objets non sécurisées
Imaginez-vous en tant qu'utilisateur naviguant sur une application web. Vous accédez à
votre compte et, naturellement, vous arrivez sur une page principale. C'est là que les choses
deviennent intéressantes. Prenez un moment pour observer l'URL :
[Link]

57
Vous remarquerez que le paramètre account"13" semble être un identifiant unique,
probablement lié à votre compte spécifique dans la base de données de l'application.
Que se passe-t-il si on remplace cette valeur “account=13” par “account=1” ?
Un attaquant va se poser exactement la même question.
Pour tester, ce dernier va simplement manipuler la requête comme dans cet exemple :
[Link]

58
59
L’attaque CSRF (Cross-Site Request Forgery)

L’objet de l’attaque CSRF (ou injections de requêtes illégitimes par rebond) est de transmettre à un
utilisateur authentifié une requête HTTP falsifiée qui pointe sur une action interne au site, afin qu'il
l'exécute sans en avoir conscience et en utilisant ses propres droits.
Ces attaques sont possibles car les navigateurs envoient automatiquement certains types
de jetons d'authentification à chaque requête adressée à un site Web. L’attaque profite donc de la
session préalablement authentifiée de l’utilisateur avec l’application en question.
Vous êtes l’administrateur du site [Link]
a. Marie se connecte à son compte sur le site [Link], pour vérifier ses dernières
transactions. Le processus d'authentification est sécurisé, et un cookie d'authentification est
stocké dans son navigateur.
b. Plus tard, en naviguant sur Internet, Marie tombe sur un site web proposant de participer à un
jeu-concours pour gagner un smartphone. Ce site, à l'apparence innocente, est en réalité contrôlé
par un attaquant.
c. Sur ce site, un formulaire HTML est discrètement intégré dans une page. Ce formulaire est
configuré pour envoyer une requête à [Link], avec une action précise : transférer de
l'argent du compte de Marie vers un compte contrôlé par l'attaquant.

60
d. Lorsque le formulaire est soumis, le navigateur de Marie envoie la requête à [Link], y
compris le cookie d'authentification valide. La banque traite la requête comme légitime puisqu'elle
provient d'une session authentifiée, réalisant ainsi le transfert d'argent sans que Marie en ait
conscience.
Comment s'en prémunir
Le contrôle d'accès n'est efficace que dans le code de confiance côté serveur ou des API
serverless, où l'attaquant ne peut pas modifier la vérification du contrôle d'accès ou les
métadonnées.
• A l'exception des ressources publiques, tout doit être bloqué par défaut
• Centraliser l'implémentation des mécanismes de contrôle d'accès et les réutiliser dans
l'ensemble de l'application. Cela comprend de minimiser l'utilisation de CORS.
• Le modèle de contrôle d'accès doit imposer l'appartenance des enregistrements, plutôt que
de permettre à l'utilisateur de créer, lire, modifier ou supprimer n'importe quel
enregistrement.
• Les exigences métier spécifiques de l'application doivent être appliquées par domaines.
• Désactiver le listing de dossier sur le serveur web, et vérifier que les fichiers de métadonnées
et de sauvegardes ne se trouvent pas dans l'arborescence web.

61
 • Tracer les échecs de contrôles d'accès, alerter les administrateurs quand c'est approprié (ex :
échecs répétés).
• Limiter la fréquence d'accès aux API et aux contrôleurs d'accès, afin de minimiser les dégâts
que causeraient des outils d'attaques automatisés.
• Les identifiants de session avec état doivent être invalidés côté serveur après une
déconnexion. Les JWT, sans état, doivent être à durée de vie relativement courte pour que la
fenêtre d'opportunité d'un attaquant soit minimisée. Pour les JWT avec une durée de vie plus
longue, il est fortement recommandé de suivre le standard OAuth de révocation d'accès.

2. Cryptographic Failures (défaillances cryptographiques)

Les failles dans les systèmes cryptographiques exposent des données sensibles. Cela inclut
l’utilisation de protocoles obsolètes ou de clés de chiffrement faibles.
Déterminer d’abord quelles données doivent bénéficier d’une protection chiffrée (mots de passe,
données patients, numéros de cartes, données personnelles, etc.), lors de leur transfert ou leur
stockage. Pour chacune de ces données :
• Les données circulent-elles en clair ? Ceci concerne les protocoles tels que HTTP, SMTP et
FTP. Le trafic externe sur internet est particulièrement dangereux. Vérifiez tout le réseau

62
 interne, par exemple entre les équilibreurs de charge, les serveurs Web ou les systèmes
backend
• Des algorithmes faibles ou désuets sont-ils utilisés, soit par défaut, soit dans le code source
existant ?
• Est-ce que des clé de chiffrement par défaut sont utilisées ? Des clés de chiffrement faibles
sont-elles générées ou réutilisées ? Leur gestion et rotation sont-elles prises en charge ? Est-
ce que des clés sont présentes dans l'outil de versioning de code source ?
• Les réponses transmises au navigateur incluent-elles les directives/en-têtes de sécurité
adéquats ?
• Est-ce que le certificat serveur reçu et la chaîne de confiance sont correctement validés ?
• Est-ce que les vecteurs d'initialisation sont ignorés, réutilisés ou générés avec une sécurité
insuffisante pour le mode d'opération cryptographique ?
• Est-ce que les mots de passe sont utilisés sans fonction de dérivation de clé ?
• Est-ce que la fonction de génération aléatoire utilisée a été conçue pour répondre aux
exigences cryptographiques ? Même si la bonne fonction est utilisée, est-ce que la graine
aléatoire doit être fournie par le développeur, et sinon, le développeur a-t-il réécrit la fonction
robuste embarquée de génération de graine par une graine aléatoire qui manque d'entropie
ou d'imprévisibilité ?

63
 • Est-ce que des fonctions de hachage dépréciées telles que MD5 ou SHA1 sont utilisées ou
est-ce que des fonctions de hachage non cryptographiques sont utilisées là où des fonctions
de hachage cryptographiques sont nécessaires ?
• Est-ce que des méthodes cryptographiques de remplissage dépréciées, comme PKCS 1 v1.5
sont utilisées ?
• Est-ce que des messages d'erreurs cryptographiques ou des informations par canal auxiliaire
sont exploitables, par exemple sous la forme d'attaque par oracle de remplissage ?
Comment s'en prémunir
On veillera au minimum à suivre les recommandations suivantes, mais il reste nécessaire de
consulter les références
• Classifier les données traitées, stockées ou transmises par l'application. Identifier quelles
données sont sensibles selon les lois concernant la protection de la vie privée, les exigences
réglementaires ou les besoins métier.
• Ne pas stocker de données sensibles sans que cela ne soit nécessaire. Les rejeter ou utiliser
une tokenisation conforme à la norme de sécurité de l’industrie des cartes de paiement (PCI
DSS) ou même une troncature. Les données que l’on ne possède pas ne peuvent être volées.
• S'assurer de chiffrer toutes les données sensibles au repos.

64
• Choisir des algorithmes éprouvés et générer des clés robustes. S'assurer qu'une gestion des
clés est en place.
• Chiffrer toutes les données transmises avec des protocoles sécurisés tels que TLS .
• Désactiver le cache pour les réponses contenant des données sensibles
• Appliquer les contrôles de sécurité requis selon la classification de la donnée.
• Ne pas utiliser de vieux protocoles tels que FTP et SMTP pour échanger des données
sensibles.
• Stocker les mots de passe en utilisant des fonctions de hachage avec salt.
• Les vecteurs d'initialisation doivent être choisis de façon appropriée au mode d'opération.
Pour la plupart des modes, cela signifie utiliser un générateur de nombres pseudo-aléatoires
cryptographiquement sécurisé.
• Les clés devraient toujours être générées de façon cryptographiquement aléatoire et stockées
en mémoire sous la forme de tableau d'octets. Si un mot de passe est utilisé, alors il faut
obligatoirement le transformer en clé via une fonction de dérivation de clé appropriée.
• S'assurer qu'une génération cryptographiquement aléatoire est utilisée là où c'est approprié
• Ne pas utiliser de fonctions cryptographiques et de méthodes de remplissage dépréciées
telles que MD5, SHA1, PKCS 1 v1.5

65
 • Vérifier indépendamment l'efficacité de la configuration et des paramètres.

3. Injection
L’injection (comme l’injection SQL) permet à un attaquant d’exécuter des commandes
malveillantes dans une application. C’est l’une des failles les plus dangereuses du Top 10.
Une application est vulnérable quand :
• les données venant de l'utilisateur ne sont pas validées, filtrées ou nettoyées par
l'application ;
• des requêtes dynamiques ou des appels non paramétrés sans échappement par rapport au
contexte sont envoyés à l'interpréteur ;
• des données hostiles sont utilisées au sein de paramètres de recherche de mapping objet -
relationnel (ORM) pour extraire des données supplémentaires sensibles ;
• des données hostiles sont utilisées directement ou concaténées, par exemple lors de la
construction de requêtes dynamiques, de commandes ou de procédures stockées pour des
requêtes SQL ou des commandes OS.
Les injections les plus courantes se font dans le SQL, l'injection Cross-Site Scripting, ou XSS, qui
est également une vulnérabilité de sécurité courante dans les applications web. Elle permet aux

66
attaquants d'injecter des scripts malveillants, généralement en JavaScript, dans des pages web
vues par d'autres utilisateurs. Ces scripts peuvent être utilisés pour voler des informations,
manipuler l'affichage de la page ou rediriger l'utilisateur vers des sites malveillants.

Comment s'en prémunir

Prévenir l’injection exige de séparer les données non fiables des commandes et requêtes :
• la meilleure option est d’utiliser une API saine qui évite complètement l’utilisation de
l’interpréteur ou fournit une interface paramétrable, ou bien de migrer pour utiliser les outils
d'Object Relational Mapping Tools (ORMs).

• pour les données en entrée, une liste autorisée avec normalisation est recommandée, mais
n’est pas une défense complète dans la mesure où de nombreuses applications requièrent
des caractères spéciaux, par exemple les zones de texte ou les API pour les applications
mobiles ;
• pour les requêtes dynamiques restantes, vous devriez soigneusement échapper les
caractères spéciaux en utilisant la syntaxe d’échappement spécifique à l’interpréteur.
Note : Les structures SQL telles que les noms de table, les noms de colonne, et d'autres ne
peuvent pas être échappées et les noms de structures venant de l'utilisateur doivent donc
être considérés comme dangereuses

67
• il est conseillé d'utiliser LIMIT et autres contrôles SQL à l'intérieur des requêtes pour
empêcher les divulgations massives de données dans le cas d'injection SQL.

• Exemple de scénarios d'attaque

• Scenario #1 Imaginons que votre application web utilise un formulaire de connexion où les
utilisateurs entrent leur nom d'utilisateur et leur mot de passe. Lorsqu'un utilisateur soumet
ce formulaire, l'application construit et exécute une requête SQL pour vérifier les identifiants.

• Une requête typique pourrait ressembler à ceci :

• SELECT * FROM users WHERE username = '[username]' AND password = '[password]';
• Dans un scénario d'attaque par injection SQL, plutôt que d'entrer un nom d'utilisateur
légitime, l'attaquant pourrait saisir un payload tel que'OR '1'='1. Lorsque l'application insère
cette entrée dans la requête SQL, cela donne :
• SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '[password]';
• Cette requête sera toujours vraie à cause de la condition '1'='1', ce qui permet à l'attaquant
de contourner le processus d'authentification.

68
 • Scenario #2 : L’application utilise des données non fiables dans la construction de l’appel
SQL vulnérable suivant :

Cas concret : un hacker injecte du code malveillant dans une base de données via un formulaire
web, accédant ainsi à toutes les informations stockées.
Utilisation en pentest : les tests d’intrusion simulent ces attaques pour identifier les points d’entrée
vulnérables.

4. Insecure Design (conception non sécurisée)

Ce risque concerne les choix de conception qui compromettent la sécurité de l’application, comme
l’absence de validation des entrées utilisateur ou l’utilisation de composants non sécurisés.
Conception non sécurisée est une vaste catégorie représentant différentes insuffisances,
exprimées par « contrôles de conception manquants ou inefficaces ». La conception non sécurisée
n'est pas la source de toutes les autres catégories de risques du Top 10. Une conception non
sécurisée fait référence à l'absence de prise en compte des aspects de sécurité dans la phase de
conception de votre application web. Cela peut inclure (sans se limiter) :
• Le manque de contrôles d'accès,
• L'insuffisance de chiffrement des données sensibles,

69
 • Ou la négligence des pratiques de sécurité dans la gestion des interactions entre différents
composants du système.

La conception sécurisée est une culture et une méthodologie qui évalue en permanence les
menaces et garantit que le code est conçu et testé de manière robuste pour empêcher les
méthodes d'attaques connues.
La modélisation des menaces doit être intégrée aux sessions de raffinement (ou activités
similaires) et rechercher des changements dans les flux de données et le contrôle d'accès.
Cycle de développement sécurisé
Un logiciel sécurisé nécessite un cycle de vie de développement sécurisé, une méthode de
conception sécurisée, une bibliothèque de composants sécurisés, des outils et une modélisation
des menaces. Faites appel à vos spécialistes de la sécurité tout au long du projet et de la
maintenance de votre logiciel.
Comment s'en prémunir
• mettez en place et utilisez un cycle de vie de développement sécurisé avec des
professionnels de la sécurité applicative pour aider à évaluer et à concevoir des contrôles liés
à la sécurité et à la confidentialité ;
• mettez en place et utilisez une bibliothèque de modèles de conception sécurisés ou de
composants prêts à l'emploi;

70
 • utilisez la modélisation des menaces pour l'authentification critique, le contrôle d'accès, la
logique métier et la gestion de clés ;
• intégrez les contrôles de sécurité dans les user stories ;
• intégrez des contrôles de vraisemblance à chaque niveau de votre application (du frontend au
backend) ;
• écrivez des tests unitaires et d'intégration pour valider que tous les flux critiques sont
résistants aux modèles de menaces
• séparez les couches systèmes et réseaux en fonction de l'exposition et des besoins de
protection ;
• séparez les tenants via une conception robuste sur l'ensemble des niveaux ;
• restreignez les ressources par utilisateur ou service.

Cas concret : une application conçue sans validation des entrées peut permettre des injections de
code ou des accès non autorisés.
Utilisation en pentest : évaluer la conception pour intégrer des pratiques de sécurité dès le début.

71
5. Security Misconfiguration (mauvaise configuration de la sécurité)
Une mauvaise configuration des paramètres de sécurité expose les systèmes aux attaques. Elle est
l’une des causes de failles les plus répandues. Cela inclut des mots de passe par défaut ou des
services non sécurisés activés par défaut.
L'application peut être vulnérable si :
• elle n'a pas fait l'objet d'un durcissement de la sécurité approprié sur l'ensemble des couches
protocolaires applicatives, ou si les permissions sont mal configurées sur les services cloud ;
• des fonctionnalités inutiles sont activées ou installées (ex : des ports, des services, des
pages, des comptes ou des privilèges inutiles) ;
• les comptes par défaut et leurs mots de passe sont toujours activés et inchangés ;
• le traitement des erreurs révèle aux utilisateurs des traces des piles protocolaires ou d'autres
messages d'erreur laissant transpirer trop d'informations ;
• pour les systèmes à jour ou mis à niveau, les dernières fonctionnalités de sécurité sont
désactivées ou ne sont pas configurées de manière sécurisée ;
• les paramètres de sécurité dans les serveurs d'application, les frameworks applicatifs (ex :
Struts, Spring, [Link]), les bibliothèques, les bases de données, etc. ne sont pas
paramétrés avec des valeurs correctes du point de vue de la sécurité ;

72
 • le serveur n'envoie pas d'en-têtes ou de directives de sécurité, ou s'ils ne sont pas paramétrés
avec des valeurs correctes du point de vue de la sécurité ;
• La version du logiciel est obsolète ou vulnérable

Comment s'en prémunir

Des processus d'installation sécurisés doivent être mis en œuvre, avec notamment :
• un processus de durcissement répétable qui permette de déployer rapidement et facilement
un autre environnement correctement sécurisé avec une configuration verrouillée. Les
environnements de développement, d'assurance qualité et de production doivent tous être
configurés de manière identique, avec des droits différents pour chaque environnement. Ce
processus devrait être automatisé afin de réduire au minimum les efforts requis pour mettre
en place un nouvel environnement sécurisé ;
• une tâche pour revoir et mettre à jour les configurations appropriées, toutes les mises à jour
et tous les correctifs dans le cadre du processus de gestion des correctifs
• une architecture d'application segmentée qui fournit une séparation efficace et sécurisée
entre les composants ou les environnements hébergés, avec de la segmentation, de la mise
en conteneurs ou l'utilisation de groupes de sécurité dans le Cloud (ACL) ;
• l'envoi de directives de sécurité aux clients, par exemple En-têtes de sécurité ;

73
 • un processus automatisé pour vérifier l'efficacité des configurations et des réglages dans tous
les environnements.

• Exemple
• Scénario 1 : Le serveur d'application est livré avec des applications classiques qui ne sont
pas supprimées du serveur mis en production. Ces mêmes applications ont des failles de
sécurité connues que les attaquants utilisent afin de compromettre le serveur. Si l'une de ces
applications est la console d'administration, et que les comptes par défaut n'ont pas été
modifiés, l'attaquant se connecte avec les mots de passe par défaut et prend la main sur la
cible.

6. Vulnerable and Outdated Components (composants vulnérables et obsolètes)

Les logiciels obsolètes sont des cibles faciles pour les attaquants. Les mises à jour de
sécurité doivent être appliquées régulièrement pour protéger les systèmes.
Vous êtes probablement vulnérable :
• si vous ne savez pas quels sont tous les composants que vous utilisez (à la fois côté client et
côté serveur). Cela comprend les composants que vous utilisez directement ou par
l'intermédiaire des dépendances imbriquées ;

74
• si le logiciel est vulnérable, sans support ou obsolète. Cela concerne le système
d'exploitation, le serveur web/application, le système de gestion de base de données (SGBD),
les applications, API et autres composants, les environnements d'exécution et les
bibliothèques ;
• si vous ne faites pas de recherche régulière de vulnérabilités et de souscription aux bulletins
de sécurité des composants que vous utilisez ;
• si vous ne corrigez pas ni mettez à jour vos plateformes sous-jacentes, vos frameworks et
leurs dépendances sur la base d'une analyse de risque, dans un délai convenable. Cela
apparaît fréquemment dans les environnements où les mises à jour sont faites sur une base
mensuelle ou trimestrielle au rythme des évolutions logicielles, ce qui laisse les organisations
exposées inutilement, des jours et des mois, à des failles avant de corriger les vulnérabilités ;
• si les développeurs de logiciels ne testent pas la compatibilité des évolutions, des mises à
jour et des correctifs des bibliothèques ;
• si vous ne sécurisez pas les configurations des composants
Comment s'en prémunir
Vous devez mettre en place une gestion des mises à jour pour :
• supprimer les dépendances inutiles et les fonctionnalités, composants, fichiers et
documentation non nécessaires ;

75
 • faire un inventaire en continu des versions de composants à la fois client et serveur (ex :
frameworks, bibliothèques) et de leurs dépendances avec des outils tels que versions,
OWASP Dependency Check, [Link], etc. Surveiller en permanence les sources
comme Common Vulnerability and Exposures (CVE) et National Vulnerability Database (NVD)
pour suivre les vulnérabilités des composants. Utiliser des outils d'analyse de composants
logiciels pour automatiser le processus. Souscrire aux alertes par courriel concernant les
vulnérabilités sur les composants que vous utilisez ;
• ne récupérer des composants qu'auprès de sources officielles via des liens sécurisés.
Préférer des paquets signés pour minimiser les risques d'insertion de composants modifiés
malveillants
• surveiller les bibliothèques et les composants qui ne sont plus maintenus ou pour lesquels il
n'y a plus de correctifs de sécurité. Si les mises à jour ne sont pas possibles, penser à
déployer des mises à jour virtuelles pour surveiller, détecter et se protéger d'éventuelles
découvertes de failles.
• Chaque organisation doit s'assurer d'avoir un projet continu de surveillance, de tri,
d'application des mises à jour et de modification de configuration pour la durée de vie d'une
application ou de sa gamme.
Exemple de scénarios d'attaque
Scénario 1 : Les composants s'exécutent généralement avec le même niveau de privilèges que
l'application, et donc les failles d'un quelconque composant peuvent aboutir à un impact sévère.

76
Les failles peuvent être accidentelles (ex : erreur de développement) ou intentionnelles (ex : porte
dérobée dans un composant). Voici quelques exemples de découvertes de vulnérabilités de
composants exploitables :
• CVE-2017-5638, une vulnérabilité d'exécution à distance de Struts 2, qui permet l'exécution
de code arbitraire sur le serveur, a été responsable d'importantes violations ;
• bien que l'internet des objets (IoT) soit souvent difficile, voire impossible à mettre à jour,
l'importance de ces mises à jour peut être énorme (ex : objets biomédicaux).
• Il existe des outils automatiques qui aident les attaquants à trouver des systèmes mal
configurés ou non mis à jour.

7. Identification and Authentication Failures (échecs d’identification et d’authentification)

Les failles dans les mécanismes d’authentification permettent à des attaquants de se faire passer
pour d’autres utilisateurs, incluant des attaques de force brute.
La confirmation de l'identité, de l'authentification et de la session de l'utilisateur sont essentielles
pour se protéger des attaques liées à l'authentification. Il peut y avoir des faiblesses
d'authentification si l'application :
• autorise les attaques automatisées telles que le bourrage des informations d'identification,
où l'attaquant dispose d'une liste de noms d'utilisateurs valides et mots de passe ;

77
 • permet la force brute ou d'autres attaques automatisées ;
• autorise les mots de passe par défaut, faibles ou bien connus, tels que "Password1" ou
"admin / admin" ;
• utilise des processus de récupération des informations d'identification faibles ou inefficaces
et des processus de mot de passe oublié, tels que « Questions secrètes », qui ne peuvent être
sécurisées ;
• utilise des mots de passe en texte brut, chiffrés ou faiblement hachés
• absence ou utilisation inefficace de l’authentification multifacteur ;
• exposition des identifiants de session dans l'URL ;
• réutilisation de l'identifiant de session après une connexion réussie ;
• n'invalide pas correctement les identifiants de session. Les sessions utilisateurs ou les jetons
d'authentification (en particulier les jetons SSO) ne sont pas correctement invalidés lors de la
déconnexion ou après une période d'inactivité.

Comment s'en prémunir

78
• lorsque cela est possible, implémentez l'authentification multifacteur pour éviter les attaques
automatisées, le bourrage des informations d'identification, la force brute et la réutilisation
des informations d'identification volées ;
• ne pas livrer ou déployer avec des informations d'identification par défaut, en particulier pour
les utilisateurs avec privilèges ;
• intégrer des tests de mots de passes faibles, à la création ou au changement. Comparer ce
mot de passe avec la liste des 10000 mots de passe les plus faibles ;
• respecter la longueur, la complexité et la rotation des mots de passe par rapport aux
directives du National Institute of Standards and Technology (NIST) 800-63 B à la section 5.1.1
ou autres directives modernes ;
• assurez-vous que l'inscription, la récupération des informations d'identification et les
chemins d'accès aux API sont durcis contre les attaques d'énumération de compte en
utilisant le même message pour tous les résultats ;
• limitez ou retardez de plus en plus les tentatives de connexion échouées, mais veillez à ne
pas créer un scénario de déni de service. Enregistrer tous les échecs et alerter les
administrateurs lors du bourrage des informations d'identification, de brute force ou d'autres
attaques détectées ;
• utilisez un gestionnaire de session intégré et sécurisé côté serveur qui génère un nouvel
identifiant de session aléatoire avec une entropie élevée après la connexion. Les identifiants

79
 de session ne doivent pas se trouver dans l'URL, ils doivent être stockés de manière sécurisée
et être invalidés après la déconnexion, une inactivité et une certaine durée.

• Exemple de scénarios d'attaque

• Scénario 1 : La réutilisation de mots de passe, l’utilisation de mots de passe connus, est une
attaque classique.

• Scénario 2 : La plupart des attaques d’authentification se produisent en raison de l’utilisation

de mots de passe comme facteur unique.

• Scénario 3 : Les timeouts de session d’application ne sont pas paramétrés correctement. Un

utilisateur utilise un ordinateur public pour accéder à une application. À la place de se
déconnecter correctement, l’utilisateur ferme le navigateur et quitte l’ordinateur. Un
attaquant utilise ensuite le même navigateur quelque temps après et l’utilisateur est toujours
authentifié.

8. Software and Data Integrity Failures (défaillances d’intégrité des logiciels et des données)
Ces failles surviennent lorsque des logiciels ou des données sont modifiés de manière non
autorisée, compromettant ainsi la sécurité de l’application.

80
Les défaillances de l'intégrité des logiciels et des données sont liées au code et à l'infrastructure qui
ne sont pas protégés contre les violations de l'intégrité. C'est le cas, par exemple, lorsqu'une
application s'appuie sur des plugins, des bibliothèques ou des modules provenant de sources, de
dépôts et de réseaux de diffusion de contenu (CDN) non fiables. Un pipeline CI/CD non sécurisé
peut introduire un risque d'accès non autorisé, de code malveillant ou de compromission du
système.
Enfin, de nombreuses applications intègrent désormais une fonctionnalité de mise à jour
automatique, où les mises à jour sont téléchargées sans vérification d'intégrité suffisante et
appliquées à l'application précédemment fiable.
Les attaquants pourraient potentiellement télécharger leurs propres mises à jour pour les distribuer
et les exécuter sur toutes les installations.
Comment s'en prémunir
• utilisez des signatures numériques ou des mécanismes similaires pour vérifier que le logiciel
ou les données proviennent de la source prévue et n'ont pas été modifiés ;
• assurez-vous que les bibliothèques et les dépendances, telles que npm ou Maven,
consomment des dépôts de confiance. Si vous avez un profil de risque plus élevé, envisagez
d'héberger un dépôt interne connu et approuvé ;

81
• assurez-vous qu'un outil de sécurité de la chaîne logistique logicielle, tel que OWASP
Dependency Check ou OWASP CycloneDX, est utilisé pour vérifier que les composants ne
contiennent pas de vulnérabilités connues ;
• veillez à ce qu'il existe un processus de révision des changements de code et de configuration
afin de minimiser les risques d'introduction de code ou de configuration malveillants dans
votre pipeline logiciel ;

Exemple de scénarios d'attaque

• Scénario n°1 mise à jour sans signature : de nombreux routeurs domestiques, décodeurs,
firmwares de périphériques et autres ne vérifient pas les mises à jour via un firmware signé.
Les microprogrammes non signés constituent une cible de plus en plus importante pour les
attaquants et leur nombre ne devrait cesser d'augmenter.

Il s'agit d'une préoccupation majeure car, bien souvent, il n'y a pas de mécanisme pour y
remédier, si ce n'est de corriger dans une version future et d'attendre que les versions
précédentes soient périmées.

• Scénario n°2 mise à jour malveillante de SolarWinds : les États-nations sont connus pour
attaquer les mécanismes de mise à jour, avec une attaque récente notable, l'attaque
SolarWinds Orion. La société qui développe le logiciel a mis en place des processus
sécurisés de construction et d'intégrité des mises à jour. Néanmoins, ces processus ont pu
être contournés et, pendant plusieurs mois, la société a distribué une mise à jour

82
 malveillante très ciblée à plus de 18 000 organisations, dont une centaine ont été touchées. Il
s'agit de l'une des violations de cette nature les plus étendues et les plus importantes de
l'histoire.

9. Security Logging and Monitoring Failures (échecs de journalisation et de surveillance de la

sécurité)
L’absence de journalisation et de surveillance efficaces empêche la détection et la réponse
rapide aux incidents de sécurité.
De retour dans le Top 10 2021 de l'OWASP, cette catégorie a pour but d'aider à la détection, à
l'escalade et à la réponse aux brèches actives. Sans journalisation et surveillance, les brèches ne
peuvent être détectées. Une journalisation, une détection, une surveillance et une réponse active
insuffisantes peuvent survenir à tout moment :
• les traces d’audit, telles que les accès réussis ou échoués et les transactions sensibles, ne
sont pas enregistrées ;
• les alertes et les erreurs générées ne sont pas enregistrées, ou leur journalisation est
inadéquate, ou imprécise ;
• les journaux des applications et des API ne sont pas contrôlés pour détecter les actions
suspectes ;

83
 • les journaux ne sont stockés que localement ;
• aucun processus de seuil d’alerte convenable ni de remontées d'information pour y répondre
n'ont été définis, ou ils sont inadéquats, ou inefficaces ;
• les tests d'intrusion et de balayage avec des outils de test dynamique de sécurité des
applications (DAST), tels que OWASP ZAP, ne génèrent pas d'alertes ;
• l’application est incapable de détecter, de générer des remontées d'information et des alertes
en temps réel, ou assimilé, en cas d’attaque active.
Vous êtes vulnérable à une fuite d’information en rendant les enregistrements de journalisation et
d’alertes accessibles à vos utilisateurs ou attaquants.
Comment s'en prémunir
Les développeurs doivent mettre en œuvre tout ou partie des contrôles suivants, en fonction du
risque de l'application :
• s'assurer que toutes les authentifications, les erreurs de contrôle d'accès et de contrôle des
entrées côté serveur sont enregistrées, avec un contexte utilisateur suffisant pour identifier
les comptes suspects ou malveillants, et conservées suffisamment longtemps pour
permettre une analyse légale différée ;
• s'assurer que les enregistrements des journaux sont dans un format standard pour permettre
de les intégrer facilement à une solution de gestion de logs centralisée ;

84
 • veiller à ce que les données des journaux soient correctement encodées afin d'éviter les
injections ou les attaques sur les systèmes de journalisation ou de surveillance ;
• s'assurer que les transactions à haute valeur ajoutée ont une piste d'audit, avec un contrôle
d'intégrité, pour éviter la modification ou la suppression, comme des tables de bases de
données en ajout seul ou équivalent ;
• les équipes DevSecOps devraient mettre en place une supervision et une gestion d'alertes
efficaces pour détecter et réagir aux actions suspectes en temps opportun ;
• définir ou adopter un plan de réaction et de reprise sur incident, comme celui du National
Institute of Standards and Technology (NIST) 800-61r2 ou ultérieur.
On trouve des logiciels, commerciaux ou open source, de protection d'applications tels que OWASP
ModSecurity Core Rule Set, et des logiciels de corrélation de journaux, comme la pile
Elasticsearch, Logstash, Kibana (ELK), qui propose des tableaux de bord et d'alertes configurables.
Exemple de scénarios d'attaque
Scénario n°1 : l'opérateur du site Web d'un fournisseur de soins de santé pour enfants n'a pas pu
détecter une violation en raison d'un manque de surveillance et de journalisation. Une partie
externe a informé le fournisseur du plan de santé qu'un attaquant avait accédé et modifié des
milliers de dossiers médicaux sensibles de plus de 3,5 millions d'enfants. Un examen postérieur à
l'incident a révélé que les développeurs du site Web n'avaient pas corrigé d'importantes

85
vulnérabilités. Comme il n'y avait pas de journalisation ou de surveillance du système, la violation
de données pourrait être en cours depuis 2013, soit une période de plus de sept ans.
Scénario n°2 : une grande compagnie aérienne indienne a subi une violation de données portant
sur plus de dix ans de données personnelles de millions de passagers, y compris des données de
passeport et de carte de crédit. La violation des données s'est produite chez un fournisseur tiers
d'hébergement en nuage, qui a informé la compagnie aérienne de la violation après un certain
temps.
Scénario n°3 : une grande compagnie aérienne européenne a subi une violation à déclarer au titre
de la RGPD. La violation aurait été causée par des vulnérabilités de sécurité des applications de
paiement exploitées par des attaquants, qui ont récolté plus de 400 000 enregistrements de
paiement de clients. La compagnie aérienne a été condamnée à une amende de 20 millions de
livres sterling en conséquence par le régulateur de la vie privée.

10. Server-Side Request Forgery (SSRF) (falsification de requêtes côté serveur)

Le SSRF permet à un attaquant de manipuler les serveurs pour envoyer des requêtes malveillantes,
compromettant ainsi la sécurité du réseau.
Une faille SSRF se produit lorsqu'une application web récupère une ressource distante sans valider
l'URL fournie par l'utilisateur. Elle permet à un attaquant de contraindre l'application à envoyer une

86
requête élaborée à une destination inattendue, même si elle est protégée par un pare-feu, un VPN
ou un autre type de liste de contrôle d'accès au réseau (ACL).
Comme les applications Web modernes offrent aux utilisateurs finaux des fonctions pratiques, la
récupération d'une URL devient un scénario courant. Par conséquent, l'incidence d'une SSRF
augmente. De même, la gravité de ce phénomène augmente en raison des services en nuage et de
la complexité des architectures.
Comment s'en prémunir
Les développeurs peuvent prévenir ce type de vulnérabilité en mettant en œuvre tout ou partie des
contrôles de défense en profondeur suivants :
Couche réseau :
• segmenter la fonctionnalité d'accès aux ressources à distance dans des réseaux distincts
pour réduire l'impact d'une SSRF ;
• appliquer des politiques de pare-feu ou des règles de contrôle d'accès au réseau "refusant
par défaut" afin de bloquer tout le trafic intranet sauf celui qui est essentiel.

87
 • Conseils:

• Établir une propriété et un cycle de vie pour les règles du pare-feu en fonction des
applications.
• Consigner tous les flux réseau acceptés et bloqués sur les pare-feu
Couche applicative :
• assainir et valider toutes les données d'entrée fournies par le client ;
• imposer le schéma d'URL, le port et la destination avec une liste positive d'autorisation ;
• ne pas envoyer de réponses brutes aux clients ;
• désactiver les redirections HTTP ;
• veiller à la cohérence des URL pour éviter les attaques telles que le rebinding DNS et les
situations de concurrence de type "time of check, time of use" (TOCTOU).
N'atténuez pas les SSRF par l'utilisation d'une liste de refus ou d'une expression régulière. Les
attaquants disposent de dictionnaires, d'outils et de compétences pour contourner les listes de
refus.

88
Mesures complémentaires :
• ne pas déployer d'autres services liés à la sécurité sur les systèmes frontaux (par exemple,
OpenID). Contrôlez le trafic local sur ces systèmes (par exemple, localhost) ;
• pour les frontaux avec des groupes d'utilisateurs dédiés et gérables, utilisez le chiffrement du
réseau (par exemple, les VPN) sur des systèmes indépendants pour prendre en compte les
besoins de protection très élevés.

Exemple de scénarios d'attaque

• Les attaquants peuvent utiliser SSRF pour attaquer des systèmes protégés derrière des pare-
feu d'applications web, des pare-feu ou des ACL de réseau, en utilisant des scénarios tels
que :
• Scénario n°1 : Analyse des ports des serveurs internes - Si l'architecture du réseau n'est pas
segmentée, les attaquants peuvent cartographier les réseaux internes et déterminer si les
ports sont ouverts ou fermés sur les serveurs internes à partir des résultats de connexion ou
du temps écoulé pour connecter ou les connexions rejetées

89
Cas d’utilisation et recommandations
Pour les RSSI et experts en cybersécurité :
• Intégration du top 10 OWASP dans les processus de sécurité : testez régulièrement les
applications en fonction de ce guide.
• Formation des équipes : éduquez les développeurs sur les risques et bonnes pratiques pour
éviter ces failles.
• Utilisation d’outils de pentest : testez vos applications contre les vulnérabilités du top 10
avec des outils comme OWASP ZAP ou Burp Suite.
Pour les développeurs :
• Adoptez des pratiques sécurisées : validation des entrées, chiffrement fort, mise à jour des
composants.
• Collaborez avec les pentesters : travaillez avec eux pour comprendre et corriger les failles
identifiées.

Intégrer la sécurité à votre application dès le départ

Les développeurs d'applications Web peuvent intégrer la sécurité dans leurs applications dès le
départ dans le contexte du Top 10 de l'OWASP :

90
• Comprendre le risque. Soyez conscient des vulnérabilités courantes.
• Suivre des pratiques de codage sécurisées. Un codage sécurisé qui atténue les dix principaux
risques.
• Entraînement régulier. Les équipes de développement doivent apprendre le codage sécurisé
et les meilleures pratiques OWASP.
• Tester la sécurité. Effectuez des tests de sécurité continus, y compris des analyses statiques
et dynamiques.
• Effectuer des revues de code. Révisions régulières du code avec un accent sur la sécurité.
• Adopter la sécurité dès la conception. La sécurité ne peut pas être renforcée plus tard.
• Utiliser la modélisation des menaces. Identifiez les faiblesses de sécurité potentielles et
corrigez-les dans l’architecture.

91
 SECURITE DES APPLICATIONS MOBILES

OWASP Top 10 des applications mobiles

92
93
94
M1: Improper Credential Usage (Utilisation incorrecte des informations d'authentification)
La plupart des applications mobiles sont toujours confrontées à un risque élevé d'utilisation
incorrecte des identifiants. Cette vulnérabilité se produit lorsque les applications ne parviennent
pas à gérer correctement les identifiants des utilisateurs, les codent en dur ou les placent dans des
emplacements non sécurisés. Le non-respect des bonnes pratiques en matière d'identifiants peut
conduire les attaquants sur la voie de la moindre résistance avec un accès non autorisé et la
possibilité d'exploiter les comptes d'utilisateurs et les données sensibles.
Ce risque peut être atténué en mettant en œuvre une gestion sécurisée des informations
d’identification des techniques de chiffrement et des pratiques de sécurité des mots de passe
renforcées.
M2. Inadequate Supply Chain Security (Sécurité insuffisante de la chaîne
d'approvisionnement)
Une chaîne d'approvisionnement défaillante se caractérise par la présence de vulnérabilités
destinées à se propager via des composants et des bibliothèques tiers que les développeurs
utilisent lorsque cela est autorisé (en moins de temps) lors de la création d'applications mobiles.
Cela comprend l'utilisation de bibliothèques obsolètes et de codes tiers prêts à l'emploi mal
examinés, ainsi que la pratiques de codage non sécurisé à toutes les étapes du cycle de vie de l'App
Store mobile.

95
Pour résoudre le problème, vous devez tout revoir, contrôler toutes les pièces, y compris les pièces
tierces/open source, et effectuer des mises à jour régulières.

M3 : Authentification/autorisation non sécurisée

Une autre vulnérabilité courante du Top 10 des vulnérabilités mobiles de l'OWASP est la faiblesse
de l'authentification/autorisation dans les applications mobiles, qui peut permettre un accès non
autorisé à des fonctionnalités critiques et à des données sensibles. Cela signifie que les attaquants
peuvent contourner l'étape initiale de vérification des identités des utilisateurs (par exemple,
lorsque plusieurs personnes sont authentifiées sous une seule connexion).
Des politiques de mot de passe faibles, une gestion de session inappropriée, des contrôles d’accès
inappropriés et l’absence d’authentification multifacteur sont quelques exemples de problèmes
courants.
Les attaquants peuvent utiliser ces vulnérabilités pour contourner l'authentification, augmenter
leurs privilèges ou se faire passer pour des utilisateurs valides.
Les développeurs devraient contrer cela en appliquant une authentification forte, une gestion
sécurisée des sessions et des contrôles d’accès appropriés.
M4 : Validation insuffisante des entrées/sorties

96
L'absence de validation des entrées/sorties peut facilement entraîner des attaques par injection et
des risques de manipulation des données dans les applications mobiles. Cette vulnérabilité peut
être exploitée lorsque les applications ne nettoient pas et ne valident pas correctement les entrées
utilisateur ou ne parviennent tout simplement pas à générer une sortie avant de valider les
données. Ces vulnérabilités peuvent être exploitées pour exécuter du code arbitraire, vider le
contenu de la base de données ou ajouter une porte dérobée à l'application.

L'injection SQL, le cross-site scripting (XSS) et l'injection de commandes sont des exemples de
vecteurs d'attaque.
Pour atténuer ce risque, les développeurs doivent procéder à une validation et à un nettoyage
stricts des entrées avant de transmettre les entrées utilisateur dans une commande SQL ou
système. Lors de l'utilisation de SQL, des requêtes paramétrées doivent être utilisées. Le codage de
sortie doit être effectué pour fournir une réponse sûre aux utilisateurs.
M5 : Communication non sécurisée
Le manque de sécurité des communications dans les applications mobiles conduit à l'interception
des communications pendant la transmission, ce qui peut entraîner des interférences
malveillantes. Une attaque de type « man-in-the-middle » peut exploiter cette vulnérabilité ou
attaquer quelqu'un qui écoute les communications réseau et les altère.

97
Certains des problèmes courants sont l'utilisation de protocoles non chiffrés, l'absence
d'implémentation SSL/TLS appropriée et l'absence de validation des certificats.
Les développeurs peuvent gérer ces risques en déployant des normes de cryptage solides, telles
que TLS 1.3 pour les données en transit et en appliquant l'épinglage des certificats tout en
établissant un lien de communication de confiance entre l'application et les serveurs principaux
pour protéger les informations sensibles transférées via des canaux sécurisés contre toute
interception ou altération de manière non authentifiée.

M6 – Manque de contrôle sur les données à caractère personnel

Les applications peuvent être vulnérables à de tels problèmes lorsqu’elles collectent des
informations personnelles telles que l’adresse de l’utilisateur, son âge ou les informations de sa
carte de crédit et que ces informations ne sont pas stockées de manière sécurisée.

Les développeurs doivent stocker toutes les informations personnelles sensibles avec un cryptage
fort et fournir des contrôles aux utilisateurs, garantissant ainsi que ces derniers peuvent contrôler
leur partage ou leur suppression.

98
M7 : Protections binaires insuffisantes
Les applications mobiles disposent de protections binaires faibles, ce qui les expose à divers types
de reverse ingénierie et de falsification de code. Cette menace s'applique aux codes d'application
compilés que les attaquants peuvent exploiter pour inspecter ou manipuler le comportement des
applications.

Les problèmes surviennent souvent en raison de l'absence d'obscurcissement du code, de

l'absence de protection anti-falsification et de contrôles d'intégrité très simples/basiques. Cette
vulnérabilité permet aux attaquants de comprendre comment l'application est programmée, de
voler des informations confidentielles (telles que des clés API) ou même d'exécuter du code
malveillant (dans certains cas).

Les développeurs peuvent remédier à ce risque en utilisant des techniques d'obscurcissement du

code pour empêcher les attaquants de procéder à une rétro-ingénierie.

M8 : Mauvaise configuration de la sécurité

Tout comme les erreurs de configuration de la sécurité des applications Web et cloud, les erreurs
de configuration de la sécurité mobile constituent également une menace courante et entraînent

99
des fuites de données. Cette vulnérabilité résulte généralement de configurations faibles ou par
défaut, d'options de configuration manquantes ou d'une mauvaise configuration lors du processus
de déploiement.
Pour cela, les développeurs doivent sécuriser la gestion de la configuration des processus
applicatifs et vérifier en permanence les paramètres des applications, en plus de respecter le
principe de moindre privilège. Ils doivent également garantir un état approprié et cohérent dans
différents environnements (développement, test, production).

M9 : Stockage de données non sécurisé

Une autre vulnérabilité majeure du Top 10 des vulnérabilités mobiles de l’OWASP est le stockage
non sécurisé des données dans les applications mobiles, car les pirates peuvent récupérer et
consulter les informations sensibles des utilisateurs stockées sur l’appareil. Les données au repos
sont stockées dans le système de fichiers ou les zones de stockage de l’application et sont
généralement mal sécurisées, ce qui les rend particulièrement vulnérables aux accès non
autorisés. Cela peut être dû au stockage de données sensibles dans des textes en clair, au choix
d’algorithmes de chiffrement inappropriés, etc.
Les développeurs doivent éviter de stocker des données en texte brut ou en stockage local qui
pourraient être utilisées pour suivre les utilisateurs ou les informations privées sur l'appareil. S'ils
stockent de telles données, ils doivent s’assurer qu'elles sont chiffrées et stockées à l'aide de
mécanismes de stockage de clés sécurisés (par exemple, Android Keystore ou iOS Keychain).

100
M10 : Cryptographie insuffisante
Une cryptographie inadéquate dans les applications mobiles est sujette à des attaques visant à
altérer la confidentialité et l'intégrité des données. Cela peut se produire lorsque les fonctions
cryptographiques ne sont pas utilisées correctement dans les applications ou lorsque des
algorithmes de cryptographie faibles ou obsolètes sont utilisés.

Par exemple, l'utilisation d'algorithmes de chiffrement obsolètes, de protocoles cryptographiques

défectueux et la génération de clés faibles avec des générateurs de nombres non sécurisés. Les
attaquants pourraient exploiter ces vulnérabilités pour déchiffrer des données, falsifier des
signatures et désactiver les contrôles de sécurité.
Pour atténuer ce risque, les développeurs doivent utiliser des algorithmes et des protocoles
cryptographiques standardisés puissants (par exemple, AES, RSA ou ECDSA), protéger les clés
secrètes lors de l'exécution via des contrôles de cryptographie, sécuriser les générateurs de
nombres aléatoires pour les opérations de génération de clés, etc. Maintenez une bibliothèque de
sécurité centralisée avec des versions à jour des bibliothèques signées cryptographiquement qui
traitent de toutes les vulnérabilités connues qui leur sont associées.

101
Bonnes pratiques pour la sécurité des applications mobiles

Il est très important de remédier aux 10 principales vulnérabilités de l'OWASP et aux menaces
émergentes supplémentaires en mettant en œuvre des contrôles de sécurité rigoureux pour les
applications mobiles. Les pratiques suivantes constituent la base de la création et de la
maintenance d'applications mobiles sécurisées :
 Codage sécurisé : appliquer les meilleures pratiques de sécurité spécifiques à la
plateforme et utiliser des outils d'analyse de code statique tels que CodeQL pour filtrer
les vulnérabilités dès les premières étapes de développement.
 Tests de sécurité réguliers : exécuter des tests de pénétration complets et des analyses
de vulnérabilité pendant le cycle de développement.
 Protéger les données et les communications sensibles : utiliser un chiffrement fort pour
les données au repos ou en transit. Utiliser une bonne gestion des clés et activer HTTPS
pour toutes les communications réseau.
 Utiliser une authentification et des contrôles d'accès forts : implémenter
l'authentification multifacteurs et la gestion des sessions et implémenter le principe
d'accès minimal pour toutes les opérations sensibles.
 Maintenir et mettre à jour les dépendances : rester au courant des mises à jour des
bibliothèques tierces et prioriser les bonnes versions dès que votre build détecte une
vulnérabilité dans l'un de vos composants.

102
 DEMARCHE DE SECURE CODING

➢ Le codage sécurisé est la pratique consistant à développer des logiciels résistants aux
vulnérabilités de sécurité en appliquant les meilleures pratiques, techniques et outils de
sécurité dès le début du développement
➢ Au lieu de penser uniquement à l’expérience utilisateur, le codage sécurisé aligne chaque
fonctionnalité sur les mesures de sécurité, dès le début du cycle de vie du développement
logiciel
➢ Par exemple, une application qui accepte toutes les données d’un client sans les nettoyer
peut être plus facile à implémenter, à utiliser et à gérer. Cependant, il ouvre un point d’entrée
pour les attaquants afin d’injecter du code malveillant
➢ Le codage sécurisé s’attaque rapidement aux vulnérabilités telles que les XSS et les fuites de
mémoire, ce qui renforce la résilience des logiciels et réduit les risques
➢ Les pratiques proactives de codage sécurisé permettent d’économiser du temps et de
l’argent en évitant les correctifs coûteux après la publication et en renforçant la confiance des
utilisateurs.

103
Les normes de OWASP, du NIST aident à créer des applications sécurisées et fiables
Quelques recommandations
1. Utiliser des langages et des outils modernes
2. Valider et nettoyer les données d’entrée et de sortie
3. Vérifier l’intégrité du code tiers
4. Appliquez un contrôle d’accès strict
5. Mettre en œuvre une gestion et une journalisation des erreurs appropriées
6. Automatisez les révisions de code
7. Appliquer des techniques d’obfuscation de code
[Link] la journalisation et la surveillance de la sécurité
[Link] la sécurité de la chaîne d’approvisionnement logicielle.

DevOps Security

104
105
Le DevOps dans son essence est une approche de développement d’application qui a pour but
d’unifier les:
➢ équipe développement d’applications
➢ Equipe des opérations
➢ Equipe Assurance Qualité
Le DevOps fait référence à l’intégration et à la collaboration entre ces différentes équipes.
Le modèle DevOps repose sur une culture de la collaboration qui s'accorde bien avec les méthodes
de travail agiles.

DevOps Security
DevOps Security ou DevSecOps est l’intégration de la sécurité dans la méthodologie DevOps.
DevOps Security doit inclure les composants suivants :
 Planifier la sécurité
 Forte collaboration entre développeurs, les equipes des operations et les spécialistes
de la securite
 Engagement des développeurs
 Développer en utilisant les techniques et les frameworks securises

106
 Utiliser des solutions automatisees de tests

107