République du Cameroun Republic of Cameroon
**** ****
Université de Maroua The University of Maroua
**** ****
École Nationale Supérieur National Advanced School
Polytechnique de Maroua of Engineering of Maroua
**** ****
Département Department of Computer
d’Informatique et des Science and
Télécommunications Telecommunications
**** ****
CYCLE: GÉNIE LOGICIEL IC5
UE : GLO 519
SÉCURITÉ DES APPLICATIONS
EXPOSÉ
THÈME : SÉCURITÉ APPLICATIVE
Rédigé et présenté par
SIMEU KENMOUE YANN BONARCHI
20C0542EP
Supervisé par
Dr BOUDJOU Hortense
ANNÉE ACADEMIQUE 2022 - 2023
Table de matière
INTRODUCTION ................................................................................................................................................. 1
I- QU’EST CE QUE LA SÉCURITÉ APPLICATIVE ?............................................................................. 2
1- POURQUOI LA SÉCURITÉ APPLICATIVE ....................................................................................................... 2
2- QU’EST-CE QUE L’OWASP TOP 10 ? ....................................................................................................... 3
II- COMMENT RENDRE LA SÉCURITÉ DES APPLICATIONS TRANSPARENTES ........................ 9
1- ÉTAPE 1: DÉVELOPPEZ EN PENSANT À LA SÉCURITÉ .................................................................................. 9
2- ÉTAPE 2: TESTEZ TÔT, SOUVENT ET RAPIDEMENT ................................................................................... 10
3- ÉTAPE 3: TIREZ PARTI DES INTÉGRATIONS POUR CRÉER UNE APPLICATION SÉCURISÉE ........................... 11
4- ÉTAPE 4: AUTOMATISATION DE LA SECURITE DANS LE CADRE DU PROCESSUS DE DEVELOPEMENT ET DE
TEST 11
5- ÉTAPE 5: SURVEILLEZ ET PROTEGEZ UNE FOIS LA VERSION PUBLIEE ....................................................... 12
CONCLUSION .................................................................................................................................................... 13
RÉFÉRENCES BIBLIOGRAPHIQUES .......................................................................................................... 14
INTRODUCTION
Au cours des dernières années, les logiciels sont passés d'une fonction de support des
entreprises à un centre d'innovation, devenant le différenciateur concurrentiel essentiel pour la
plupart des entreprises. Avec ce changement dans le rôle des logiciels, les entreprises
augmentent aujourd'hui considérablement le nombre d'applications et la fréquence des
versions, sans se préoccuper des exigences non fonctionnelles. De plus, les applications
modernes deviennent de plus en plus complexes en raison du besoin de vitesse et, par
conséquent, la dépendance des développeurs à la réutilisation du code ainsi qu'aux composants
open source et commerciaux a considérablement augmenté. Cela a d'énormes implications sur
les équipes de sécurité pour trouver et gérer les vulnérabilités. En conséquence, certaines des
failles de sécurité notables de ces dernières années étaient dues à des vulnérabilités dans des
composants de code tiers. En plus de tous les défis créés par un nombre accru d'applications,
une complexité croissante et des versions plus rapides, des réglementations telles que le RGPD
(Règlement Général sur la Protection des Données) sont devenues la norme. Tout cela signifie
que la sécurité doit être un élément essentiel du cycle de vie des logiciels.
1
I- Qu’est ce que la sécurité applicative ?
La sécurité applicative concerne les processus, outils et pratiques visant à protéger les
applications contre les menaces tout au long de leur cycle de vie. Les cybercriminels sont
organisés, spécialisés et motivés pour identifier et exploiter les vulnérabilités des applications
d'entreprise afin de voler des données, des éléments de propriété intellectuelle et des
informations sensibles. La sécurité des applications peut aider les entreprises à protéger toutes
sortes d'applications (qu'elles soient de bureau, sur navigateur Web, sur appareils mobiles ou
sous forme de micro-services) utilisées par les parties prenantes, internes et externes, ou les
clients, les partenaires commerciaux et les employés [1]. La sécurité vise généralement cinq
principaux objectifs [2]:
¨ L’intégrité: garantir que les données sont bien celles que l’on croit être
¨ La disponibilité: maintenir le bon fonctionnement du système d’information
¨ La confidentialité: rendre l’information inintelligible à d’autres personnes que les
seuls acteurs d’une transaction
¨ La non répudiation: garantir qu’une transaction ne peut être niée
¨ L’authentification: assurer que seules les personnes autorisées aient accès aux
ressources.
1- Pourquoi la sécurité applicative
Comme l'ont démontré de multiples études, la majorité des effractions réussies ciblent des
vulnérabilités exploitables résidant dans la couche d'application, ce qui indique qu'il est
nécessaire pour les services informatiques des entreprises de se montrer particulièrement
vigilants au niveau de la sécurité des applications. Pire encore, le nombre et la complexité des
applications ne font qu'augmenter. Il y a dix ans, le défi lié à la sécurité logicielle consistait à
protéger les applications de bureau et les sites Web statiques qui étaient relativement simples
et faciles à visualiser et à protéger. Aujourd'hui, la chaîne d'approvisionnement logicielle est
bien plus compliquée, si l'on tient compte du développement externalisé, du nombre
d'applications héritées, associé au développement en interne qui s'appuie sur des composants
tiers, open source et commerciaux prêts à l'emploi.
2
Les entreprises ont besoin de solutions de sécurité qui couvrent l'ensemble de leurs
applications, qu'elles soient internes ou qu'il s'agisse d'applis externes populaires que les clients
installent sur leur téléphone portable. Ces solutions doivent couvrir l'ensemble des étapes du
développement et proposer des tests après la mise en service d'une application afin de détecter
les problèmes potentiels. Les solutions de sécurité applicative doivent être en mesure de tester
les applications Web à la recherche de vulnérabilités potentielles et exploitables, avoir la
possibilité d'analyser le code, contribuer à gérer les processus de gestion de la sécurité et du
développement en coordonnant les efforts et en favorisant la collaboration entre les différentes
parties prenantes. Les solutions doivent en outre offrir des tests de sécurité des applications qui
soient simples à utiliser et à déployer.
2- Qu’est-ce que l’OWASP TOP 10 ?
L'Open Web Application Security Project (OWASP) est une fondation à but non lucratif dédiée
à l'amélioration de la sécurité des logiciels. Il fonctionne selon un modèle de « communauté
ouverte », ce qui signifie que tout le monde peut participer et contribuer aux discussions en
ligne, aux projets et plus encore liés à l'OWASP [3]. Pour tout, des outils et vidéos en ligne aux
3
forums et événements, l'OWASP veille à ce que ses offres restent gratuites et facilement
accessibles via son site Web.
Le Top 10 de l'OWASP fournit des classements et des conseils de correction pour les 10 risques
de sécurité des applications Web les plus critiques. Tirant parti des vastes connaissances et de
l'expérience des contributeurs de la communauté ouverte de l'OWASP, le rapport est basé sur
un consensus parmi les experts en sécurité du monde entier. Les risques sont classés en fonction
de la fréquence des failles de sécurité découvertes, de la gravité des vulnérabilités découvertes
et de l'ampleur de leurs impacts potentiels. L'objectif du rapport est d'offrir aux développeurs
et aux professionnels de la sécurité des applications Web un aperçu des risques de sécurité les
plus répandus afin qu'ils puissent intégrer les conclusions et les recommandations du rapport
dans leurs propres pratiques de sécurité, minimisant ainsi la présence de risques connus dans
leurs applications.
L'OWASP maintient sa liste des 10 meilleurs depuis 2003, la mettant à jour tous les deux ou
trois ans en fonction des avancées et des changements du marché AppSec. L'importance de la
liste réside dans les informations exploitables qu'elle fournit en servant de liste de contrôle et
de norme de développement d'applications Web internes pour bon nombre des plus grandes
organisations du monde. Les auditeurs considèrent souvent le fait qu'une organisation ne
respecte pas le Top 10 de l'OWASP comme une indication qu'elle ne respecte peut-être pas
d'autres normes de conformité. À l'inverse, l'intégration du Top 10 dans le cycle de vie du
développement logiciel démontre l'engagement global d'une organisation envers les meilleures
pratiques de l'industrie pour un développement sécurisé.
Les 10 principaux risques de sécurité des applications Web (Top 10 2021) sont [4] :
¨ Broken Access Control (Contrôle d’accès corrompu)
Correspond à une mauvaise gestion de l’authentification et de la session, que les attaquants
peuvent exploiter pour récupérer mots de passe, clés, jetons de session, ou pour usurper
l'identité d'un autre utilisateur.
Exemple : Violation du principe du moindre privilège ou refus par défaut, où l'accès ne doit
être accordé qu'à des capacités, des rôles ou des utilisateurs particuliers, mais est accessible à
tous.
Contre-mesure :
- Sauf pour les ressources publiques, refuser par défaut
4
- Consigner les échecs de contrôle d'accès, alerter les administrateurs le cas échéant (par
exemple, échecs répétés).
¨ Cryptographic Failures (Échecs cryptographiques)
Il s’agit de toute défaillance responsable de l'exposition de données sensibles et critiques à une
entité non autorisée peut être considérée comme une défaillance cryptographique.
Exemple : Les mots de passe, les numéros de carte de crédit, les dossiers médicaux, les
informations personnelles et les secrets commerciaux
Contre-mesure :
- Classer les données traitées, stockées ou transmises par une application. Identifiez les
données sensibles selon les lois sur la confidentialité, les exigences réglementaires ou
les besoins de l'entreprise.
¨ Injection
Correspond à l'injection de code dans les applications web (injection SQL, ou dans l'interface
système...). Les attaquants cherchent à entrer des données de façon à ce qu'elles soient
interprétées comme une commande, leur permettant ainsi d'effectuer des actions non désirées.
Contre-mesure :
- L'option préférée consiste à utiliser une API sécurisée, qui évite d'utiliser entièrement
l'interpréteur, fournit une interface paramétrée ou migre vers des outils de mappage
relationnel objet (ORM).
- Utilisez LIMIT et d'autres contrôles SQL dans les requêtes pour empêcher la
divulgation massive d'enregistrements en cas d'injection SQL.
¨ Insecure Design (Conception non sécurisée)
La conception non sécurisée est le manque de contrôles de sécurité intégrés dans l'application
tout au long du cycle de développement. Cela peut avoir des conséquences de sécurité étendues
et profondes, car l'application elle-même n'est pas conçue dans un souci de sécurité.
Contre-mesure :
- Établir et utiliser un cycle de vie de développement sécurisé
5
- Utilisez la modélisation des menaces pour l'authentification critique, le contrôle
d'accès, la logique métier
¨ Security Misconfiguration (Mauvaise configuration de la sécurité)
Correspond aux failles de configuration liées aux serveurs Web, applications, base de
données ou framework.
Contre-mesure :
- Une architecture d'application segmentée fournit une séparation efficace et sécurisée
entre les composants, avec la segmentation, la conteneurisation ou les groupes de
sécurité cloud (Access Control List).
- Un processus automatisé pour vérifier l'efficacité des configurations et des paramètres
dans tous les environnements.
¨ Vulnerable and Outdated Components (Composants vunérables et obselètes)
Cela inclut les composants que vous utilisez directement ainsi que les dépendances imbriquées.
Si le logiciel est vulnérable, non pris en charge ou obsolète. Cela inclut le système
d'exploitation, le serveur Web/d'applications, le système de gestion de base de données
(SGBD), les applications, les API et tous les composants, les environnements d'exécution et
les bibliothèques.
Contre-mesure :
- Supprimez les dépendances inutilisées, les fonctionnalités inutiles, les composants, les
fichiers et la documentation.
- N'obtenez des composants que de sources officielles via des liens sécurisés. Préférez
les packages signés pour réduire le risque d'inclure un composant malveillant modifié
¨ Identification and Authentification Failures (Échecs d’identification et
d’authentification)
Les échecs d'identification et d'authentification sont des vulnérabilités liées aux schémas
d'authentification des applications. De telles défaillances peuvent entraîner des violations de
données graves et dommageables.
6
Exemple :
- Permet la force brute ou d'autres attaques automatisées.
- Autorise les mots de passe par défaut, faibles ou bien connus, tels que "Mot de passe1"
ou "admin/admin".
Contre-mesure :
- Dans la mesure du possible, mettez en œuvre une authentification multifacteur pour
empêcher le bourrage d'informations d'identification automatisé, la force brute et les
attaques de réutilisation d'informations d'identification volées.
- N'expédiez pas ou ne déployez pas avec des informations d'identification par défaut, en
particulier pour les utilisateurs administrateurs.
¨ Sofware and Data Integrity Failures (Échecs de l’intégrité du logiciel et des données)
Les défaillances d'intégrité des logiciels et des données concernent le code et l'infrastructure
qui ne protègent pas contre les violations d'intégrité.
Exemple : Une application s'appuie sur des plugins, des bibliothèques ou des modules
provenant de sources, de référentiels et de réseaux de diffusion de contenu (CDN) non fiables.
Contre-mesure :
- Utilisez des signatures numériques ou des mécanismes similaires pour vérifier que le
logiciel ou les données proviennent de la source attendue et n'ont pas été modifiés.
- Assurez-vous que les bibliothèques et les dépendances, telles que npm ou Maven,
consomment des référentiels approuvés.
¨ Security Logging and Monitoring Failures (Échecs de la journalisation et de la
surveillance de la sécurité)
Il s’agit du fait de ne pas enregistrer, surveiller ou signaler suffisamment les événements de
sécurité, tels que les tentatives de connexion, cela rend les comportements suspects difficiles à
détecter et augmente considérablement la probabilité qu'un attaquant puisse exploiter avec
succès votre application.
Contre-mesure :
7
- Assurez-vous que tous les échecs de connexion, de contrôle d'accès et de validation des
entrées côté serveur peuvent être consignés avec un contexte utilisateur suffisant pour
identifier les comptes suspects ou malveillants et conservés pendant suffisamment de
temps pour permettre une analyse médico-légale différée.
- Assurez-vous que les données du journal sont correctement codées pour empêcher les
injections ou les attaques sur les systèmes de journalisation ou de surveillance.
¨ Server-Side Request Forgery (SSRF) (Contre façon des requêtes côté serveur)
Les failles SSRF se produisent chaque fois qu'une application Web récupère une ressource
distante sans valider l'URL fournie par l'utilisateur. Il permet à un attaquant de contraindre
l'application à envoyer une requête spécialement conçue vers une destination inattendue, même
lorsqu'elle est protégée par un pare-feu, un VPN ou un autre type de liste de contrôle d'accès
(ACL) réseau.
Contre-mesure :
- Assainir et valider toutes les données d'entrée fournies par le client
- Appliquer le schéma, le port et la destination de l'URL avec une liste d'autorisation
positive
8
II- Comment rendre la sécurité des applications transparentes
Le succès avec la sécurité des applications demande du temps et des efforts, mais le plus grand
obstacle à surmonter est le changement de culture nécessaire pour inclure la sécurité tout au
long du cycle de vie du développement logiciel. Il est important d'éliminer les frictions entre
les équipes de sécurité et les développeurs. Selon ISO 27034 (Guide ISO sur la sécurité
applicative ), la sécurité applicative ne couvre pas seulement la portion logicielle [2]. Elle
couvre également tous les contrôles et mesures de sécurité impliqués dans le cycle de vie de
l’application : De la conception à la terminaison de l’application. Au-delà du changement de
culture nécessaire, voici quelques étapes importantes pour réussir votre transition vers la
sécurité transparente des applications [5] :
1- Étape 1: Développez en pensant à la sécurité
Il est indispensable de donner aux développeurs les moyens d'assumer la responsabilité de leur
propre code. En trouvant et en corrigeant les défauts de sécurité pendant le processus de codage,
les développeurs peuvent éliminer les vulnérabilités de sécurité potentielles avant qu'elles
n'atteignent les tests et la production, ce qui permet à l'organisation d'économiser du temps et
de l'argent. Ce changement de mentalité nécessite de former les développeurs à coder en
gardant à l'esprit la sécurité et de les armer des bons outils pour obtenir des commentaires en
9
temps réel sur leur code. De cette façon, les responsables de développement apportent la
perspective de la sécurité dès le début du cycle de vie du développement en plus des aspects
fonctionnels et de qualité traditionnels.
2- Étape 2: Testez tôt, souvent et rapidement
Au cours du cycle de vie du développement logiciel, il existe plusieurs approches à suivre afin
de maintenir la vitesse nécessaire pour suivre les versions d'aujourd'hui. Ces approches sont
testées tôt, souvent et rapidement.
Les tests statiques de sécurité des applications (SAST) analysent les fichiers source des
applications, identifient avec précision l'origine des problèmes et facilitent la correction des
failles sous-jacentes.
Les tests dynamiques de sécurité des applications (DAST) simulent des attaques contrôlées sur
une application ou un service Web en cours d'exécution afin d'identifier les vulnérabilités
exploitables dans un environnement en production.
Les tests interactif de sécurité des applications (IAST) sont une forme de test de sécurité des
applications qui combine des tests dynamiques de sécurité des applications (DAST) et des
commentaires d'exécution de l'application testée au fur et à mesure de l'exécution des tests.
Avantages
- Identifier et éliminer les vulnérabilités dans le code sources
- Examen des résultats des analyses statiques en temps réel avec accès aux
recommandations, navigation dans les lignes de code pour identifier plus
rapidement les vulnérabilités et les audits collaboratifs.
SAST
- Pleinement intégré à l'environnement de développeur natif (IDE)
10
- Fournit un point de vue complet sur la sécurité applicative en se concentrant
sur ce qui est exploitable et en couvrant tous les composants (serveur, code
personnalisé, open source, services)
- Fournit un point de vue complet sur la sécurité applicative en se concentrant
sur ce qui est exploitable et en couvrant tous les composants (serveur, code
personnalisé, open source, services)
DAST - Teste les applications fonctionnelles, de sorte que contrairement au SAST,
il n'est pas soumis à des contraintes de langage et permet d'identifier les
problèmes liés à l'exécution et à l'environnement
3- Étape 3: Tirez parti des intégrations pour créer une application sécurisée
Pour rendre la sécurité des applications transparente, il est essentiel de tirer parti des
intégrations avec vos outils actuels tout au long du cycle de vie du développement logiciel.
Avec des options d'automatisation pour les analyses statiques et dynamiques et des intégrations
disponibles aux outils de développement les plus populaires tels que Visual Studio, Eclipse et
Jenkins, les équipes de développement gagnent du temps et réduisent les frictions. Les
intégrations avec des systèmes de gestion des défauts tels que JIRA ou BugZilla améliorent la
gestion et la résolution des problèmes de sécurité et garantissent qu'ils peuvent être traités en
même temps que l'organisation gère les problèmes fonctionnels.
4- Étape 4: Automatisation de la sécurité dans le cadre du processus de dévelopement et
de test
Pour la sécurité des applications, l'automatisation peut être utilisée avec les tests de sécurité
afin de maintenir la même qualité à une vitesse plus élevée. En automatisant les tests de
sécurité, vous pouvez créer et exécuter des tests de sécurité automatisés comme vous le feriez
avec des tests unitaires ou des tests d'intégration.
Grâce à l'analyse statique ou dynamique automatisée, vous pouvez identifier efficacement les
vulnérabilités de sécurité dans le code source, minimisant ainsi la nature fastidieuse des
évaluations de sécurité. L'analyse automatisée du code réduit non seulement les temps de
11
révision du code, d'évaluation de la sécurité et de test, mais entraîne également une réduction
des coûts de correction en trouvant les vulnérabilités plus tôt.
5- Étape 5: Surveillez et protégez une fois la version publiée
La première étape de toute initiative de sécurité des applications consiste à comprendre où se
situe votre exposition aux risques, en particulier dans les environnements de production qui
pourraient déjà être vulnérables. Bien que la gestion de la sécurité dans le cadre du processus
de développement soit une excellente approche, il est également essentiel de protéger les
applications existantes en production. Il est désormais impératif de surveiller et de protéger en
permanence les environnements de production contre les risques de sécurité des applications.
12
CONCLUSION
En somme, nous pouvons dire que la sécurité applicative, intégrée tout au long du cycle de vie
du développement logiciel, crée des risques mesurablement réduits et des processus contrôlés,
ce qui se traduit finalement par des coûts réduits, un délai de mise sur le marché amélioré et un
effort optimisé. Aujourd'hui, chaque entreprise utilise des données et de nombreuses
entreprises interagissent désormais avec leurs clients et partenaires via des applications Web et
mobiles. Sécuriser le nombre croissant d'applications nécessaires au fonctionnement de
l'entreprise tout en respectant les délais de publication et les budgets de développement n'est
réalisable que lorsque la sécurité des applications fait partie du processus de développement
logiciel. Le déplacement de la sécurité des applications vers la gauche est un concept qui intègre
les tests de sécurité dans les premières étapes du développement pour améliorer l'efficacité et
minimiser les efforts et les coûts pour les équipes de développement et de sécurité.
13
Références Bibliographiques
[1] "Qu'est-ce que la sécurité applicative ?," [Online]. Available:
https://www.microfocus.com/fr-fr/what-is/application-security.
[2] H. Dr Boudjou, "Sécurité des applications," Maroua, 2022.
[3] "Top 10 OWASP 2021," Synopsys, [Online]. Available:
https://www.synopsys.com/glossary/what-is-owasp-top-10.html.
[4] "OWASP Top Ten," [Online]. Available: https://owasp.org/www-project-top-ten/.
[5] "Seamless Application Security: Security at the Speed of DevOps," [Online]. Available:
https://www.microfocus.com/media/white-
paper/seamless_application_security_security_at_the_speed_of_devops_wp.pdf.
14
