Support Sécurité Des Applications WEB

Sécurité des
applications WEB
Professeur :
Dr Ahmed Youssef KHLIL
1
Terrain foyer Rocade Fann Bel Air, BP 10 000 Dakar Liberté – SENEGAL - Tel: +221 33 869 03 00 - FAX : + 221 33 824 68 90
esmt@esmt.sn - www.esmt.sn
TABLE DES MATIERES
Chapitre 1 : La sécurité du web.............................................................................................. 5

I.1.1 : Création et évolution du web ............................................................................ 5
I.1.1.1 : Création du web ................................................................................................. 5
I.1.1.1.1 : W3C ............................................................................................................. 6
I.1.1.1.1.1 : Mission .................................................................................................. 6
I.1.1.2 : Evolution du web ............................................................................................... 7
I.1.1.2.1 : Fondement du web ....................................................................................... 9
I.1.1.2.1.1 : HTML .................................................................................................... 9
I.1.1.2.1.2 : HTTP ................................................................................................... 10
I.1.1.2.1.3 : URI ...................................................................................................... 13
I.1.2 : Architecture Web ............................................................................................ 15
I.1.2.1 : Architecture client-serveur ou à deux niveaux ................................................. 15
I.1.2.2 : Architecture à trois niveaux ............................................................................. 15
I.1.3 : Le protocole HTTPS et SSL/TLS ................................................................... 16
I.1.4 : Cyber sécurité ................................................................................................. 17
I.1.4.1 : Objectif ............................................................................................................. 17
I.1.4.1.1 : Triade CIA ................................................................................................. 18
I.1.4.2 : Le cyberespace ................................................................................................. 19
I.1.4.3 : Les menaces du cyberespace ............................................................................ 19
I.1.4.4 : La Cyberattaques .............................................................................................. 20
I.1.4.4.1 : Types de cyberattaques .............................................................................. 20
I.1.4.4.1.1 : DDOS .................................................................................................. 21
I.1.4.4.1.3 : Hameçonnage ...................................................................................... 23
Chapitre 2 : Etat de l’art sur les vulnérabilités web et mobile ............................................. 24
I.2.1 : Vulnérabilité des applications web et mobile ................................................. 24
I.2.1.1 : Application web ............................................................................................... 24
I.2.1.1.1 : Vulnérabilité sur les applications web ....................................................... 24
I.2.1.1.1.1 : Injection ............................................................................................... 25
I.2.1.1.1.2 : Authentification brisée ........................................................................ 26
I.2.1.1.1.3 : Exposition des données sensibles ........................................................ 26
2
I.2.1.2 : Applications mobile ......................................................................................... 27
I.2.1.2.1 : Vulnérabilités des applications mobiles ..................................................... 27
I.2.1.2.1.1 : Exploit Payload ................................................................................... 28
I.2.1.2.1.2 : Stockage des données non sécurisé ..................................................... 28
I.2.1.2.1.3 : Communication non sécurisée ............................................................. 29
I.2.2 : Sécurité et protection des données personnelles des applications web et mobile
29
I.2.2.1 : CDP .................................................................................................................. 29
I.2.2.1.1 : Le droit des consommateurs....................................................................... 30
I.2.2.1.1.1 : Droit à l’information [17] .................................................................... 30
I.2.2.1.1.2 : Droit d’accès [17] ................................................................................ 30
I.2.2.1.1.3 : Droit d’opposition ............................................................................... 31
I.2.2.1.1.4 : Droit de rectification et suppression [17] ............................................ 31
I.2.2.1.2 : Niveau de contrôle ..................................................................................... 32
I.2.2.2 : OWASP ............................................................................................................ 32
I.2.2.2.1 : Les principes de l’OWASP ........................................................................ 32
Chapitre 3 : Cas d’utilisation................................................................................................ 34
I.3.1 : Architecture de travail .................................................................................... 34
I.3.1.1 : Environnement de travail ................................................................................. 35
I.3.1.1.1 : Critère de choix .......................................................................................... 35
I.3.1.1.2 : Serveur d’hébergement .............................................................................. 36
I.3.1.1.3 : Hôtes clients ............................................................................................... 37
I.3.1.1.4 : Application web ......................................................................................... 37
I.3.1.1.5 : Application mobile ..................................................................................... 37
I.3.1.1.6 : Outils de travaux ........................................................................................ 38
I.3.1.1.6.1 : Outils de test de vulnérabilités ............................................................ 38
Chapitre 4 : Attaque et recommandation ............................................................................. 39
I.4.1 : Exploit des vulnérabilités ............................................................................... 39
I.4.1.1.1 : Injection...................................................................................................... 39
I.4.1.1.1.1 : SQLI .................................................................................................... 39
I.4.1.1.1.2 : Injection de code.................................................................................. 41
I.4.1.1.2 : Exposition des données sensible ................................................................ 46
I.4.1.1.3 : Authentification brisée ............................................................................... 47
3
I.4.1.2 : Application mobile ........................................................................................... 48
I.4.1.2.1 : Stockage des données non sécurisé ............................................................ 48
I.4.1.2.2 : Communication non sécurisée ................................................................... 49
I.4.2 : Recommandations .......................................................................................... 52
I.4.2.1.1 : Injection...................................................................................................... 52
I.4.2.1.1.1 : SQLi .................................................................................................... 52
I.4.2.1.1.2 : Injection de code.................................................................................. 54
I.4.2.1.2 : Exposition des données sensible ................................................................ 55
I.4.2.1.3 : Authentification brisée ............................................................................... 56
I.4.2.2 : Application Mobile .......................................................................................... 58
I.4.2.2.1 : Stockage des données non sécurisé ............................................................ 58
I.4.2.2.2 : Communication non sécurisée ................................................................... 58
Chapitre 5 : WAF (Web Application Firewall) ........................................................................ 59
I.5.1. Définition .................................................................................................................... 59
I.5.2. Caractéristiques du WAF ............................................................................................ 59
I.5.3. Filtrage Applicatif ....................................................................................................... 60
I.5.3.1. Comment protéger un site web avec un firewall applicatif ou WAF ? ................ 60
I.5.3.2. Filtrage WAF............................................................................................................ 61
I.5.4. Les Types de WAF ...................................................................................................... 61
I.5.5. Enjeux et perspectives ................................................................................................. 61
I.5.5.1. Enjeux ................................................................................................................... 61
I.5.5.2. Perspectives .......................................................................................................... 62
Conclusion................................................................................................................................ 63
Bibliographie ............................................................................................................................ 64
Webographie ............................................................................................................................ 65
Annexes .................................................................................................................................... 67
4
Chapitre 1 : La sécurité du web
I.1.1 : Création et évolution du web

Le web très souvent confondu avec le réseau des réseaux internet est un service
d’internet composé de trois technologies : le HTML, l’URI et le HTTP.
Grace au HTML il permet de relier les données avec des hyperliens et de créer des
documents hypertextuels. Au moyen de l’URI, permet l’identification des ressources afin de
pouvoir mieux interagir avec elles et grâce au HTTP permet la transmission des documents
hypertextuels. C’est donc l’assemblage de ces technologies qui donne l’existence du service
web que nous connaissons actuellement.
I.1.1.1 : Création du web

Créer dans les années 1990, le web est un service qui permet de consulter et naviguer
entre des pages à travers le lien HyperText. Aussi appelé Word Wide Web, le web est avant
tout une initiative de recherche d’information hypermédia de grande envergure qui vise à
donner un accès universel à un vaste univers de documents.
Tout commence dans les années 1980, Sir Timothy John Berners-Lee en ce temps
ingénieur du CERN (Organisation européenne pour la recherche nucléaire), remarque la
difficulté auquel tout le monde est confronté au partage de l’information. Bien que chaque
ordinateur soit connecté au réseau internet, le partage d’information demeurait encore un
problème car il n’y avait en ce temps aucun service reconnut permettant de donner accès à une
information universelle de n’importe où. Les ingénieures du CERN se déplaçaient d’un
ordinateur à un autre pour le partage de l’information. A cette époque il y avait différentes
informations et différents ordinateurs, cela ne facilitait pas l’interopérabilité[8].
C’est alors que Tim-Berners Lee songe à résoudre ce problème, il veut permettre aux
ingénieures du CERN une possibilité d’accéder de collaborer de n’importe où. En 1989, il
expose sa vision dans un document intitulé : « gestion de l’information : une proposition », mais
sa proposition ne sera pas acceptée par son patron Mike Sandall il la juge vague mais
passionnant. En 1990 Tim-Berners Lee commence à écrire les trois technologies qui sont le
fondement du web (HTML, URI et HTTP) et fait de nouveau une proposition du projet
5
reformulé avec les encouragements de la direction du CN et du CEP. RC. Mais cette fois sa
demande sera acceptée.
Dans cette demande Tim Berners-Lee relate les avantages de l’hypertexte et présente
le projet en deux phases. La première phase consacrée au développement d’un navigateur
simple pour les postes de travail des utilisateurs et la seconde pour étendre le domaine
d’application en permettant aux utilisateurs d’ajouter des nouveaux documents. En Novembre
1990, nais le prototype initial de World Wide Web développé sur le NeXT. Le 26 février 1991,
se fera la présentation du projet au groupe ECP. Puis en mars 1991 la publication du navigateur
en mode ligne mais seulement à un public limité. Mais le 6 aout 1991 Tim-Berners Lee adresse
un message à Usenet c’est alors que le Word Wide Web est officiellement reconnu par ce
message public.
Tim-Berners Lee ne s’arrêtera pas là, car pour lui n’importe qui devrais utiliser de
n’importe où le web sont payer aucun frais ni avoir à demander la permission à qui que ce soit.
C’est alors qu’il plaide pour que CERN rende le code disponible sans redevance et cela pour
toujours. Cette décision sera alors annoncée en avril 1993, cela va changer le monde. En 2003
les sociétés développant de nouvelles normes web se sont engagées à appliquer une politique
en matière de droit d’auteur.
I.1.1.1.1 : W3C
L’objectif de Tim-Berners Lee dans le projet web, était d’offrir un espace
d’information universelle accessible à tout le monde sans aucune contrainte de distance. Pour
cela, chaque navigateur devrait pouvoir interagir entre eux à travers le web. C’est donc ainsi
que Tim lance en 1994 le Consortium Word Wide Web (W3C) afin de standardiser le web. On
retient son siège social à Cambridge l'État du Massachusetts, aux États-Unis. Le but de ce projet
est d’améliorer la technologie web à sa plus haute performance. Par ailleurs permettre à chaque
développeur de navigateur web de concevoir des navigateurs basés sur un standard afin que
chaque navigateur parvienne à interpréter les technologies web sans aucune difficulté.
Aujourd’hui le W3C se définit comme une communauté internationale au sein de laquelle les
organismes membres, un personnel à temps plein et le public travaille ensemble à l’élaboration
de normes.
I.1.1.1.1.1 : Mission
Dirigé par l'inventeur et directeur du Web, Tim Berners-Lee, et le PDG, Jeffrey Jaffe,
le W3C a pour mission de permettre au Web de réaliser tout son potentiel.
6
Pour atteindre cet objectif, le W3C s’appuie sur ces valeurs :
 Le web pour tous : La valeur sociale du web est de permettre la communication
humaine, le commerce, et le partage des connaissances. Un des premiers objectifs du
W3C est de délivrer ces bénéfices à toute personne, quel que soit son matériel, son
logiciel, son infrastructure réseau, sa langue maternelle, sa culture, sa situation
géographique, ses capacités physiques ou mentales [9].
 Le web partout : étendre l’accessibilité du web dans diffèrent terminaux (téléphone
mobile, télévision connecté, assistance vocal, application domestique),
 La vision : élargir la participation des utilisateurs, le partage des connaissances, dans
un objectif de construction d’un haut niveau de confiance à l’échelle mondiale [9].
I.1.1.2 : Evolution du web

Depuis les années 1990, le web à subit d’énorme amélioration afin de renforcer sa
qualité d’utilisation et de service. Cette succession d’amélioration a permis d’aboutir à sa
version actuelle telle que nous la connaissons, le WEB 3.0. Cela est le fruit des efforts fournit
par la communauté Open Web qui participe à la définition des technologies web comme HTML,
CCS et WebGL.
La première version de web, le WEB 1.0, aussi appelé le web traditionnel ou web en
lecture seul, apparut dans les années 1990 – 2000. L’utilisateur ne se limitait seulement à la
lecture des informations fournis par les producteurs de contenue. Aucune possibilité pour
l’utilisateur de communiquer des informations au producteur de contenu, ce qui s’apparente des
sites web statique. Les technologies utilisées dans le WEB 1.0 sont : HTML.
Ensuite le WEB 2.0 est apparu dans les années 2000-2010 (continu de nos jours), on
ne parle plus de web lecture mais plutôt de web lecture et écriture car l’utilisateur ou
consommateur peut être producteur de contenue et partager son contenue entre sites. Le WEB
2.0 est aussi connus sur le nom de web social car il est construit autour des utilisateurs, le
producteur de contenue doit simplement créer un moyen de les activer et de les impliquer.
Quelques applications créées avec le WEB 2.0 : Facebook, YouTube, Flickr, Twitter.
Enfin le WEB 3.0 aussi appelé le web lecture-écriture-exécution dans les années 2010
et au-dessus (jusqu’à notre ère actuelle). Dans le WEB 3.0 l’intelligence artificiel et
l’apprentissage automatique interviennent, les ordinateurs peuvent interpréter les informations
comme des êtres humains. Elles aident par exemple à générer et distribuer de manière
7
intelligente un contenu utile adapté à un besoin particulier d’un utilisateur car elles sont la
possibilité de :
 Comprendre le sens derrière l’information,
 Apprendre ce qui nous intéresse,
 Aider à trouver ce que nous voulons,
 Reconnaître des personnes, des lieux, des événements, des sociétés, des produits, des
films, etc.
 Comprendre les relations entre les choses.
Par ailleurs on parle déjà du WEB 4.0 plus connu sous le nom d’internet des objets
L’objectif est d’intégrer étroitement dispositif physique dans un réseau qui peut agir de manière
autonome, c’est-à-dire sans aucune intervention humaine. Les dispositifs concernés peuvent
être des maisons, véhicules, réfrigérateurs et tout autre dispositif jugé nécessaire à intégrer une
intelligence artificielle, tout cela pour faciliter la vie quotidienne.
WEB 1.0 WEB 2.0 WEB 3.0 WEB 4.0

Site web Sites web OS (système opérationnel)
Architecture Cloud
statique dynamiques et Cloud
Evolution vers des standards
Language HTTP, HTML. XML et RSS RDF, OWL, SWRL. ouverts,
vers un langage universel
Infobésité : trop de
contenu de qualité
très inégale.
Accessibilité :
Peu Danger
technologie ne Sécurité des sources et accès
d’interaction d'envahissement
permet pas encore aux données,
Obstacle avec les par
une vraie Danger d’un contrôle sur la vie
utilisateurs, un web
portabilité. privée et perte de liberté.
lent et lourd. omniprésent.
Manque de
personnalisation : il
est difficile de sortir
du lot
Tableau 1 : Comparaison de l’évolution du web

Le tableau ci-dessus fait une comparaison des diffèrent WEB.
8
I.1.1.2.1 : Fondement du web
Pour que le web aboutisse à sa phase finale, il fallait essentiellement combiner des
technologies qui permettent à la fois de récupérer le contenue, de l’afficher et de le référencer.
C’est donc ainsi qu’a été créer le langage HyperText (HTML), le protocole de transfert des
données Hypertext (HTTP) et l’identifiant de ressource uniforme (URI). Ce sont là les
fondements du web, les technologies qui composent le web.
I.1.1.2.1.1 : HTML
Le HTML (HyperText Markup Langage) aussi appelle langage de balisage, est un standard
et langage utilité pour créer des pages web. L’intérêt de cette technologie dans le web, est de
permettre la gestion des documents hypertextuels. Le HTML a permis de créer des documents
hypertextuels et associer des hyperliens sur ces documents afin de permettre la navigation entre
ces documents.
Sir Timothy Tim Berners-Lee a créé le langage de balisage HTML à partir du SGMLguid
(qui était le format de documentation standard utilisé en interne au CERN), après sa création,
le HTML a subi d’énorme correction partons du HTML 1.0 à HTML 5 (le standard actuelle).
Le HTML 1.0 publié en 1993 dans le but de partager des informations lisible et accessible
via le navigateur web. Mais très peu de développeur était impliqué dans la création, les pages
était complexe à concevoir et le résultat n’était pas satisfaisant. Ce qui a conduit à la création
du HTML 2.0.
La publication du HTML 2.0 en 1995 qui est venue complémenter le HTML 1.0. Comme
son précèdent, le HTML 2.0 n’a pas connu de succès lui non plus. Par ailleurs, un problème se
posait toujours au niveau des navigateurs car chaque navigateur voulait développer ses propres
balises adaptées à certaine page. Le développement individuel de balises à entrainer un
problème d’incompatibilité. Il fallait alors un standard. Car lorsqu’un client tentait de consulter
une page avec un navigateur ne prenant pas en charge les balises de cette page, cela causait
problème. HTML 3.0 a alors été lancé, il inclut de nouvelles fonctionnalités HTML améliorées,
donnant aux webmasters des caractéristiques plus puissantes dans la conception de pages Web.
Mais ces puissantes fonctionnalités du nouveau code HTML ont ralenti le navigateur.
Ensuite le HTML 4 qui après a été mis à jour HTML 4.1, est lancé et est largement utilisé.
Il était une version à succès de HTML avant HTML 5.0. HTML 4.1 a été le standard de HTML
depuis 1997 les navigateurs pouvait alors avoir des mêmes balises. Le W3C dans le but
d’apporter la meilleure performance et le plein potentiel de ses technologies a lancé le
9
XHTML1.0
XHTML 1.0 lancé en 2000 a lui aussi connu un grand succès, adopté à cause de l’inter
portabilité du XML a été meilleur au HTML 4.1 contrairement au HTML 4.1, XHTML affichait
le résultat à peu près pareil dans tous les navigateurs.
Enfin HTML 5 publié en 2014 par le W3C et retouché en 2016 qui a donné naissance au
HTML5.1 a connu un grand succès, c’est le HTML qui est utilisé à notre ère pour les
applications, jeux et sites web beaucoup plus performant.
I.1.1.2.1.2 : HTTP
La création des documents hypertextuels étant faite, il fallait alors ajouter au web un
mécanisme permettant d’échanger entre le client (navigateur) et le serveur (serveur web) des
données. C’est alors que le HTTP (Hypertext Transfert Protocol) a trouvé son importance.
Comme son nom l’indique, le HTTP est le protocole de transfert de fichier HTML. Dans son
mécanisme de fonctionnement, deux acteurs sont mis en évidence, le client web et le serveur.
Le client communique avec le serveur au moyen du navigateur qui a été développé pour
comprendre et communiquer sur le protocole HTTP. Le client web échange avec le serveur web
(aussi appelé serveur http) des données, la communication est dite requête-réponse. Le client
envoie au serveur une requête et le serveur envoie à son tour au client une réponse après avoir
traité la requête.
Ci-dessous une illustration pour mieux appréhender.
Figure 1 : Illustration requête et réponse HTTP

Dans cette illustration trois étapes se faisant.
10
1. Première étape : Le client envoie au serveur web une requête. Cette requête à pour méthode
d’envoie GET et pointe la ressource index.jsp en utilisant le protocole HTTP 1.1,
2. Deuxième étape : Le serveur fait un traitement de la requête reçu par le client avant de
pouvoir lui envoyer une réponse,
3. Troisième étape : Le serveur envoie une réponse au client après analyse de sa requête.
L’image indique le protocole HTTP utilisé par le serveur qui est HTTP 1.1, le code du
message 200 (correspond à un message de succès de la requête du client et le statut du
message OK.
Les éléments qui composent les messages HTTP peuvent varier selon la nature de la
requête client-serveur, comme cela est indiqué dans l’image.
a. Requête HTTP
Une requête HTTP est un ensemble de ligne envoyé au serveur web ou serveur HTTP
par le navigateur. Généralement dans le but de solliciter une ressource (page web, image etc.),
les éléments qui composent une requête HTTP sont : la méthode, l’URI, la version HTTP, un
champ d’en-tête, une ligne vide, et le corps de la requête. Ci-dessous un exemple de requête
HTT
Figure 2 : Format d’une requête HTTP

La méthode dans la requête HTTP indique le traitement à effectuer à la ressource, la
méthode GET n’est pas la seule méthode utilisée dans l’envoie d’une requête HTTP car il en
existe plusieurs autres.
 La méthode GET : La méthode GET demande une représentation de la
ressource spécifiée. Les requêtes GET doivent uniquement être utilisées afin
de récupérer des données [10],
11
 La méthode HEAD : La méthode HEAD demande une réponse identique à une
requête GET pour laquelle on aura omis le corps de la réponse (on a
uniquement l'en-tête) [10],
 La méthode POST : La méthode POST est utilisée pour envoyer une entité vers
la ressource indiquée. Cela entraîne généralement un changement d'état ou des
effets de bord sur le serveur [10],
 La méthode PUT : remplace toutes les représentations actuelles de la
ressource visée par le contenu de la requête3,
 La méthode DELETE : supprime la ressource indiquée3,
 La méthode CONNECT : établit un tunnel vers le serveur identifié par la
ressource cible,
 La méthode OPTION : utilisée pour décrire les options de communications
avec la ressource visée,
 La méthode TRACE : réalise un message de test aller/retour en suivant le
chemin de la ressource visée,
 La méthode PATCH : utilisée pour appliquer des modifications partielles à
une ressource[10].
b. Réponse HTTP
Une réponse HTTP peut se définir comme un ensemble de ligne envoyé par un serveur
à un client ayant émis une requête. Dans une réponse http on y trouve : la version HHTP, le
status, le commentaire du status, le type de contenu (généralement MIME), le champ d’en-tête
et sa valeur, une ligne vide et le document (en générale un document HyperText). Mais cela
n’est que le format d’écriture d’une réponse, il n’est pas rare de voir des réponses HTTP, ne
comprenant pas toutes les informations précisées dans le format de base d’écriture mais en
générale la version du protocole, le status et le commentaire status figurent toujours dans une
réponse HTTP.
12
Figure 3 : Format d’une réponse HTTP
Le statut est un code renvoyé au client par le serveur pour présenter le résultat de sa
requête. Ce code est un nombre qui varie selon la nature de la réponse du serveur, il est utile
pour le client afin de spécifier si ça requête a été effectuer au non et la cause. Ci-dessous les
code status et leurs significations.
 100 - 199 S’agit d’une information,
 200 - 299 Succès de la requête lient,
 300 - 399 Redirection de la requête client,
 400 - 499 Requête client incomplète,
 500 - 599 Erreur serveur.
I.1.1.2.1.3 : URI
L’URI (Uniform Resource Identifier) est une séquence de caractères identifiant une
ressource logique ou physique [11]. Il existe deux types d’URI, les identifiants de ressources
uniforme aussi connut sur le nom de URL (Uniform Resource Identifiers) et les noms de
ressource uniforme URN (Uniform Resource Names). L’importance d’URI dans la composition
du web est de pouvoir identifier les ressources afin de faciliter l’interaction.
c. URL
Uniform Resource Locator en français localisateur de ressource uniforme identifie une
ressource sur le web. Elle indique l’emplacement et le protocole utilisé pour accéder à cette
ressource. La syntaxe d’écriture d’une URL est faite de la façon suivante :
 Nom du schéma,
 Deux points et deux barres obliques,
13
 Emplacement du serveur,
 Le port (facultatif) et l'emplacement de la ressource sur le serveur,
 Identifiant de fragment (optionnel).
L’emplacement du serveur est communément le nom de domaine ou l’adresse IP de
mise en ligne du serveur.
Exemple d’une URL : http://www.groupeisi.com/index.jsp
Dans cette URL le protocole ou nom de schéma pour accéder à la ressource est HTTP
et l’emplacement du serveur www.groupeisi.com la ressource est index.jsp et l’emplacement
de la ressource est http://www.groupeisi.com/index.jsp.
d. URN
Uniform Resource Names en français nom de ressource uniforme est une ressource
internet avec un nom statique, reste accessible ou valide même si ses données sont déplacées
vers un autre emplacement. La différence qui existe entre une URL et un URN est que : l’URL
identifie une ressource en se basant sur son emplacement actuel et un URN identifie une
ressource par un nom, pas besoin de connaitre l’emplacement de la ressource et en cas de
déplacement de la ressource, l’URN reste valide.
La syntaxe d’écriture d’une URN est tel que : <URN> ::= "urn:" <NID> ":"
<NSS>
Tous les URN s’écrivant avec la même syntaxe.
Exemple de URN : urn:ietf:rfc:2648 qui correspond à The IETF's RFC 2648.
14
I.1.2 : Architecture Web
L’architecture web, regroupe les différents éléments qui composent le web, elle peut
être définie comme la structure conceptuelle du web. Il existe deux types d’architecture web,
le premier qui inclut le modèle client-serveur ou modèle à deux niveaux et le second connut sur
au nom de modèle à trois niveaux ou architecture à trois niveaux.
I.1.2.1 : Architecture client-serveur ou à deux niveaux

L’architecture client-serveur ou architecture à deux niveaux est la première
architecture du web. Dans cette architecture, seul deux éléments sont présents, le client
(navigateur web) et le serveur web. Elle permet de concevoir de sites ou applications web
statique.
Figure 4 : Architecture client-serveur

Le scénario est tel que :
1. Le client (navigateur) émet une requête HTTP au serveur, la requête comprend l’adresse de
la ressource dans le serveur et l’action à effectuer (consultation d’une page par exemple),
2. Le serveur reçoit la requête du client et lui retourne la ressource demandée après avoir traité
sa demande,
3. Le client (navigateur) reçoit le contenu sous forme de balise et l’interprète.
I.1.2.2 : Architecture à trois niveaux

L’architecture à trois niveaux compte à lui inclut trois éléments, le client, le serveur
web ou serveur HTTP et le serveur d’application. Différemment de l’architecture à deux
niveaux qui ne comprend pas le serveur d’application, l’intérêt du serveur d’application est de
15
pouvoir interagir avec des services et la base de données. Cela permet au développeur de
concevoir des applications dynamiques. L’architecture se présente telle que :
Figure 5 : Architecture à trois niveaux

Le scénario est tel que :
1. Le client (navigateur) émet une requête au serveur,
2. Le serveur reçoit la requête du client et l’envoie au serveur d’application,
3. Le serveur d’application reçoit les instructions à effectuer et échange avec la base de
données au langage SQL,
4. Une fois que le serveur d’application reçoit les informations de la base de données, il le
transfert au serveur sous forme de balises,
5. Le serveur renvoie alors le contenue HTML au client.
I.1.3 : Le protocole HTTPS et SSL/TLS

Afin de combler et de garantir une confidentialité, intégrité et disponibilité au sein du
protocole de transfert HyperText dans le web, le protocole HTTPS à connut le jour. En effet, le
protocole HTTP ne permet pas une confidentialité des échanges, toutes les informations en
transit peuvent être lue en clair.
Le protocole HTTPS, protocole de transfert HyperText sécurisé est le protocole qui permet
de faire des échanges Hypertext sécurisé, c’est-à-dire chiffré. Il fournit des mécanismes de
communication sécurisés entre client-serveur HTTP. La couche de sécurité ajoutée dans le
protocole HTTP pour chiffrer les informations échangées entre deux entités est soit le SSL ou
le TLS.
SSL (Secure Sockets Layer) est une technologie pour maintenir une connexion Internet
sécurisée et protéger toutes les données sensibles qui sont envoyées entre deux systèmes,
16
empêchant les tiers de lire et de modifier les informations transférées, y compris les détails
personnels potentiels [12]. TLS est une amélioration de SSL il effectue la même tache.
Afin de chiffrer les communications, SSL/TLS utilise des algorithmes de chiffrement
symétrique (AES, RC4) et asymétrique (RSA, DSA) [13].
Pour une application web, elle permet de chiffrer les données échangées entre le navigateur
du client et le serveur web afin de garantir la confidentialité, l’intégrité et la disponibilité des
données. Le mécanisme et effectué de la manière suivante :
 Le navigateur envoie au serveur une demande pour établir une connexion TLS,
 Le serveur envoie au client son certificat qui contient sa clé publique, ses
informations et une signature numérique,
 Le navigateur vérifie l’authenticité du certificat auprès de l’autorité de certificat qui
a signé le certificat,
 Le navigateur génère une clé de sessions qu’il chiffre avec la clé publique contenue
dans le certificat avant de la transmettre au serveur,
 Le serveur déchiffre à l’aide sa clé privée la clé de session du navigateur avant de
pouvoir s’échanger les données avec elle.
I.1.4 : Cyber sécurité

La cybersécurité désigne l'ensemble des technologies, processus et pratiques conçues
pour protéger l’utilisation du cyberespace contre les cyberattaques. Elle consiste à protéger les
données de l’extérieure et les ressources sur internet.
I.1.4.1 : Objectif
L’objectif de la cybersécurité est de protéger les données contre les menaces
extérieures, protéger l’information contre les utilisateurs non autorisé afin d’éviter une
altération ou une suppression de cette information.
Pour se faire, la cybersécurité doit assurer que l’information demeure toujours dans le
cyberespace disponible, afin que les ressources demandées soient accessibles. En plus de cela
l’information doit être authentique, c’est dire ne pas avoir subi une altération ou modification
par une entité non prévus à cet effet. Enfin l’information destiné à être confidentielle doit être
mis confidentielle.
La Triade CIA a cependant été créé à cet effet, dans l’objectif d’assurer les 3 aspects
fondamentaux e la sécurité.
17
I.1.4.1.1 : Triade CIA
Figure 6 : Triade CIA

La Triade CIA rien à avoir avec le service de renseignement américain CIA, la triade
CIA (confidentiality, integrity, and availability) en français Confidentialité, Intégrité et
Disponibilité, constituent la pierre angulaire de l’infrastructure de sécurité de toute entreprise.
La violation de l’un des éléments de ce triangle revenait à compromettre la sécurité. En effet
pour une entreprise, « Chaque composant est essentiel à la sécurité globale, la défaillance d'un
composant entraînant un compromis potentiel du système »1
La confidentialité car les données destinées à être confidentiel ou secret doit être
maintenue confidentielle. Pour cela l’accès aux données doit être restreint, seules les entités
destinées à accéder aux données doivent y accéder. Dans le cadre d’une banque par exemple,
un client quelconque n’a pas connaissance du solde des autres clients de cette banque.
L’intégrité car les données ne doivent pas faire l’objet d’une falsification ou altération,
elles doivent elle maintenue authentique. Pour cela les données en cours d’utilisation doivent
être protégées. L’information à l’envoie doit être la même à la réception. Dans le cas d’un envoi
de courrier électronique par exemple, le fichier envoie par le l’émetteur doit être le même reçu
par le récepteur. Si le fichier d’envoi est différent au fichier de réception, on peut déduire qu’il
y a une atteinte à l’intégrité sur ce fichier.
La disponibilité car les données ou ressources doivent être accessible en cas de besoin.
Pour cela une continuité des services doit être maintenue et l’équipement qui héberge les
services doit éviter tout déni de service. Dans le cas d’un serveur disposant de petite
1
James Graham, Ryan Olson, Rick Howard. 2010. Cyber Security Essentials. Etats Unis d'Amérique, 1p.
18
performance, hébergent une application web, au cours de l’utilisation le serveur surchargé de
requêtes ne parvient plus à traiter les demandes du client à défaut de ses performances et rend
l’application web indisponible.
I.1.4.2 : Le cyberespace
La définition apportée par Google est que le cyberespace est un espace de
communication créé par l'interconnexion mondiale des ordinateurs (Internet) ; espace, milieu
dans lequel naviguent les internautes. Nous pouvons considérer le cyberespace comme l’espace
dans lequel sont échangé des données.
I.1.4.3 : Les menaces du cyberespace

Les menaces du cyberespace représentant les personnes qui sont susceptibles de nuire
à la sécurité du cyberespace. Il s’agit des personnes qui commettent volontairement des actions
illégales bien qu’ils n’ont pas tous les mêmes motivations. Pour la liste des menaces du
cyberespace nous avons fait référence à la liste établit par le géant de la sécurité Fortinet sur les
menaces du cyberespace dans le contenue de formation NS1 module 1 [14].
 L’exploreur : Personne qui mène des cyberattaques sans causer de dégât. Il
s’agit d’une attaque passive, l’explorateur est motivé par sa curiosité et l’envie
de se prouver à lui-même.
 Hacktiviste : considérer comme des personne ou groupe de personne qui
commettent des cyberattaques dans le but de répondre leurs idéologies. En
d’autres termes un hacktiviste est une personne qui utilise le piratage pour
provoquer un changement politique et social. Il n’est pas motivé par le désir de
commettre des actions malveillantes, mais au contraire de rendre justicier bien
que ces actions puissent aller à l’encontre de la loi ou peuvent faire preuve
d’une désobéissance civile. Exemple : Anonymous.
 Cyberterroriste : Comme le nom l’indique, cyber terroriste est une
convergence de cyberespace et terroriste. Fait référence personne qui
commettent des actions terroristes dans le cyberespace. Cela peut s’agir d’une
action illégale et aux menaces d'attaques contre les ordinateurs, les réseaux et
les informations qui y sont stockées lorsqu'elles sont utilisées pour intimider
ou contraindre un gouvernement ou son peuple dans la poursuite d'objectifs
politiques ou sociaux.
19
 Cybercriminel : Les cybercriminels sont des individus ou des équipes de
personnes qui utilisent la technologie pour commettre des activités
malveillantes sur des systèmes ou des réseaux numériques dans le but de
dérober des informations confidentielles de l'entreprise ou des données
personnelles et de générer des bénéfices.
 Cyber guerrier : aussi connut au nom de cyber warrior, est un expert en
informatique engagé dans l'infiltration ou le sabotage de systèmes
d'information ou dans la défense de systèmes d'information contre des attaques
extérieures, généralement à des fins stratégiques ou militaires.
I.1.4.4 : La Cyberattaques
Une cyberattaque peut être défini comme un exploit d’une vulnérabilité d’un service dans le
cyberespace. Une cyberattaque est un acte malveillant puni par la loi car elle porte atteinte à la
confidentialité, disponibilité et intégrité d’autrui. La personne qui effectue une cyberattaque est
appelé cybercriminel.
Les conséquences causées par les cyberattaques entrainant de grand dégât selon la nature de
l’attaque passif ou active. Pour distinguer une attaque passive d’une attaque active, nous avons
élaboré le tableau ci-dessous :
Attaque active Attaque passive
Une attaque active tente de modifier L’attaque passive tente de lire ou d’utiliser les
Définition les ressources du système ou informations du système mais n’influence pas les
d’affecter leur fonctionnement. ressources du système.
Système Cause des dommages au système. Aucun dommage
Information Modifie l'information Ne modifie pas l'information
Triade CIA Affecte l'intégrité et la disponibilité Affecte la confidentialité
Tableau 2 : Comparaison entre attaque passif et attaque active
I.1.4.4.1 : Types de cyberattaques

Il existe plusieurs types de cyberattaque, mais chacune de ces cyberattaques visent à
atteindre l’un des 3 composant de la triade CIA c’est dire la disponibilité, la confidentialité ou
l’intégrité. Nous en présentons dans ce travail 3 cyberattaques connut il s’agit.
20
 Attaque de déni de service DDOS,
 Attaque MitM ou homme du milieu,
 Attaque spear phising ou hameçonnage,
I.1.4.4.1.1 : DDOS
Une attaque de type DDOS, est une attaque qui consiste à portée atteinte à la disponibilité
d’un service. Comme son nom indique déni de service distribué, elle effectue des attaques de
type DOS mais de façons distribuées. Pour se faire, l’attaquant utilise d’autre périphérique
appelé zombi qui effectuerons à sa place des attaque DOS, le but étant de submerge les
ressources d'un système afin qu'il ne puisse plus répondre aux demandes de service. Ci-dessous
une illustration d’attaque DOS et DDOS.
 Cas d’une attaque DOS
Figure 7 : Illustration d’une attaque de type DOS

Dans cette illustration d’attaque de type DOS, l’attaquant envoie au serveur des requêtes afin
de saturer ses ressources, de ce fait il ne pourra plus répondre à la demande du client
(navigateur). Mais ce type d’attaque est inefficace avec les serveurs actuels.
 Cas d’une attaque DDOS
21
Figure 8 : Illustration d’une attaque de type DOS
Dans le cas d’une attaque DDOS, l’attaquant passe par le bai des hôtes affectés par son
programme malveillant pour effectuer son attaque. Le réseau qui constitué les hôtes affectés
par l’attaquant est appelé botnet et les hôtes de ce réseau sont appelé zombi. Contrairement à
une simple attaque de type DOS, une attaque DDOS peux facilement entrainer un déni de
service surtout si le nombre de zombi est élevé.
I.1.4.4.1.2 : MitM
MitM est l’abréviation de Man in the middle en français l’homme du milieu. Ce type
d’attaque consiste à s’insérer entre la communication d’un client avec un serveur. Comme le
montre l’illustration ci-dessous :
Figure 9 : Illustration d’une attaque de type Homme du milieu
22
Dans ce type d’attaque, l’attaquant intercepte la communication entre le client et le serveur,
il peut lire les informations échangées ou les modifier à sa guise.
I.1.4.4.1.3 : Hameçonnage
Une attaque de type hameçonnage est une attaque phishing ciblé, à la différence d’une
attaque de phishing qui consiste à envoie un mail qui semble provenir d’une source viable dans
le but d’obtenir des informations de sa victime ou encore de la pousser à effectuer une action,
une attaque par hameçonnage est beaucoup plus précise que cela. Tout comme une attaque de
phishing, le spear phishing ou hameçonnage elle combine l'ingénierie sociale et la ruse
technique.
Elle est plus laborieuse, elle est dite attaque ciblée. Dans cette attaque, l’attaquant prend la
peine de connaitre sa cible afin de produire des messages clair et pertinent. Cela peut être une
usurpation de courrier électronique ou d’identité le but étant de faire croire à la victime qu’elle
connait l’émetteur du courrier électronique. Le courrier électronique ne demeure pas le seul
moyen par lequel passe les attaquant afin d’effectuer les attaques de type hameçonnage.
L’attaquant peut aussi effectuer un clonage de site web pour attirer ses victimes afin d’obtenir
ses PII (information personnel identifiable).
Ci-dessous un tableau présentant les attaques énumérées précédemment et leurs impacts dans
les éléments de la triade CIA.
TRIDADE CIA
Attaques Disponibilité Confidentialité Intégrité Dommages
Rend un service
DDOS Affecté
indisponible
Vol d’information,
usurpation d’identité,
MitM Affecté Affecté Affecté
modification ou
suppression d’information
Spear
Affecté Vol d’information
Phising
Tableau 3 : Impact de cyberattaques dans la triade CIA
23
Chapitre 2 : Etat de l’art sur les vulnérabilités web et mobile
I.2.1 : Vulnérabilité des applications web et mobile
I.2.1.1 : Application web

Une application web est un programme informatique utilisable depuis un navigateur web.
Elle est destinée à effectuer une tâche définie. Aujourd’hui le marché des applications web
accroît considérablement à cause de la flexibilité, l’optimisation et le gain de temps qu’offrent
les applications web aux utilisateurs.
Flexible car elle ne nécessitant aucune installation, elles sont utilisables depuis un navigateur
web et aucun problème de compatibilité de système d’exploitation ne se pose.
Les applications web sont très optimales que cela soit en cout de production ou en
maintenance, elle utilise peu d’espace mémoire et demande moins de traitements du processeur.
Les applications web apportent un gain de temps qu’il s’agisse du déploiement ou de la mise
en œuvre, le code peut être modifié à tout moment et mis à jour.
Il existe plusieurs types d’application web on peut citer par-là : les applications E-commerce,
E-sport, Webmail et autres.
I.2.1.1.1 : Vulnérabilité sur les applications web

Les applications web sont aujourd’hui omniprésentes dans notre quotidien. Elles sont
utilisées pour les divers services qu’elles offrent et la possibilité de pouvoir interagir à distance.
Pour les entreprises, cela est une opportunité d’étendre leur marché. Car elles peuvent
désormais fournir des services qui seront accessible au consommateur depuis leurs ordinateurs
ou leurs smartphones.
Mais l’accessibilité des applications web de partout et à tout le monde, offre la possibilité à
tous de pouvoir interagir avec elle et les exposent à toute tentative d’exploit. Les exploits sur
les applications web sont divers et chacun d’entre eux consiste à tirer profil d’une vulnérabilité.
L’OWASP classe chaque année le top 10 risques les plus critiques pour la sécurité des
applications web. C’est en référence à ce classement que nous avons fait le choix des
vulnérabilités des applications web à présenter dans ce document.
 Vulnérabilité Injection,
 Vulnérabilité par authentification brisée,
 Vulnérabilité d’exposition des données sensibles.
24
I.2.1.1.1.1 : Injection
Une injection de code se produit lorsqu'un attaquant envoie des données non valides à
l'application Web avec l'intention de lui faire faire quelque chose de différent de celui pour
lequel l'application a été conçue [15].
Les exploits de vulnérabilité d’injection sont appelés attaques par injection, elles sont
classées parmi les attaques les plus dangereuses. Elles peuvent entrainer un vol d’informations,
une perte de données, un déni de service ou une prise de contrôle complète du système. Elle
consiste à exploiter une entrée dans un programme afin d’injecter ou insérer un code malveillant
qui sera interprété comme une commande ou une requête et modifiera le déroulement normal
de l’exécution du programme.
Catégorie ou type de code peuvent effectuer une attaque de type injection :
 Injection SQL : Consiste à modifier le code SQL attendu par le programme en
insérant un code SQL malicieux afin de changer le déroulement normal du
programme. Exemple : La commande ci-dessous est une commande prévue par le
programme, il s’agit d’une commande avec des instructions statique et une valeur
dynamique. select title, text from news where id=$id. La commande
suivante est une commande modifiée par l’attaquant, dans cette commande
l’attaquant n’a connaissance que de la table new et des champs tilte, text. Il insère
une valeur statique avec une expression qui retournera une valeur vraie. Cela
provoquera ainsi le même résultat que la première commande. select title, text
from news where id=10 or 1=1.
 Inclusion de fichier : attaques par inclusion sont des attaques qui exploitent des
vulnérabilités PHP en injectant une expression dans l’url afin de permettre son
exécution à distance. L’injection de ce code peut s’agir soit d’un lien vers un code
malveillant ou d’un accès vers le répertoire local du serveur web ou en dehors de son
répertoire. Dans le cas de l’exécution d’un code malveillant vers une autre source
cela est appelée RFI (Remote file inclusion) en français, inclusion de fichier à
distance un exemple de cette attaque. Insertion du code
https://monsite/file=code_malveillant. Dans le cas d’une inclusion de
fichier local ou LFI (Local File Include)
https://monsite/file=../../../../etc/passwd.
25
 Injection de code : Consiste à insérer un code (Hypertext, Script) dans une entré
(champ de texte).
 Injection d’en-tête : Ce type d’attaque permet de modifier l’en-tête d’une requête
HTTP.
I.2.1.1.1.2 : Authentification brisée

Une vulnérabilité d'authentification brisée ou endommagée peut permettre à un
attaquant d'utiliser des supports manuels ou automatiques pour tenter de maîtriser un compte
d’utilisateur ou même pire pour en avoir le contrôle total sur le système [16]. Elle consiste à
exploiter l’accès à un compte ou la connexion à ce compte. Les sites et applications web qui
contiennent cette vulnérabilité sont très courants sur le net. L’OWASP affirme que c’est le
problème que rencontrent presque tous les CSM (Content Management System) car ils offrent
tous par défaut un accès mondial au panneau d’administration.
Types de vulnérabilités : Les vulnérabilités d'authentification brisées peuvent prendre
de nombreuses formes. Selon OWASP, une application Web contient une vulnérabilité
d’authentification cassée si elle :
 Autorise les attaques automatisées telles que le bourrage de données
d'identification, dans le cas où l'attaquant dispose d'une liste de noms
d'utilisateur et de mots de passe valide,
 Autorise la force brute ou d'autres attaques automatisées,
 Utilise des mots de passes par défaut, faible et connut comme « 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 les « réponses
basées sur les connaissances », qui ne peuvent pas être sécurisés,
 Utilise des mots de passe en clair, chiffrement ou hachage faible.
 Expose les identifiants de session dans l'URL (par exemple, la réécriture
d'URL).
I.2.1.1.1.3 : Exposition des données sensibles

L'exposition de données sensibles est l'une des vulnérabilités les plus répandues. Il
s'agit de données PII (informations personnellement identifiables) volées qui auraient dû être
protégées. Celles-ci sont communément appelées violations de données.
26
L’information personnelle identifiable ou PII est une information qui peut directement
identifier une personne. Il s’agir de :
 Mots de passe,
 Numéro de carte de crédit,
 Informations d'identification (nom, prénom, âges etc.),
 Numéros de sécurité sociale,
 Informations relatives à la santé,
 Autres informations personnelles.
I.2.1.2 : Applications mobile

Une application mobile ou encore une App mobile, est un programme développé pour
les appareils mobile (smartphone, tablette). Très souvent destiné à effectuer un service, tout
comme les web applications, elle existe sur tout type de catégorie qu’il s’agisse d’application
d’utilitaire, de la productivité, de la navigation, divertissement, sport et autres.
Les applications mobiles, contrairement aux applications web ne sont pas développées
avec la même technologie. En effet les applications mobiles peuvent quelques fois différer selon
le système d’exploitation, bien qu’il existe des cadres de développement d’applications mobile
multiplateforme le rendu de chaque application diffère selon son SE.
Tout comme les applications web, les applications mobiles ne sont pas épargnées des
cyberattaques. Selon l’OWASP, elles sont d’ailleurs les plus ciblé, car elle compte un nombre
de consommateur important.
I.2.1.2.1 : Vulnérabilités des applications mobiles

Les applications mobiles sont constamment dans notre quotidien, elles nous
simplifiant et facilitent les tâches. Elles rendent par exemple possible l’envoie d’un courrier en
ligne dans un temps réduit et de partout. De plus avec l’avancée technologique, elles permettent
aujourd’hui, d’interagir avec des objets connectés, des transactions financières et autres. Mais
tout comme les applications web, elles présentent des vulnérabilités. En effet une application
développée sans la prise en compte des mesures et des bonnes pratiques de sécurité, peut
présenter des vulnérabilités et ainsi exposé ses utilisateurs aux cyberattaques.
Nous présentons ci-après les 3 vulnérabilités mobiles en référence au top 10 à
vulnérabilité mobile de l’OWASP2017.
27
Ces vulnérabilités sont :
 Vulnérabilité de charge utile ou Payload,
 Vulnérabilité dû au stockage de données non sécurisé,
 Vulnérabilité dû à la communication non sécurisée.
I.2.1.2.1.1 : Exploit Payload

Une charge utile ou payload fait référence au composant d'un virus informatique qui exécute
une activité malveillante. Elle consiste dans le cas d’une application mobile a injecté une partie
du code malveillant dans l’application, le but étant d’effectuer des exploits dans le mobile dans
lequel est installé l’application.
Une l’injection de code malveillant dans le but d’effectuer un payload sur une application
mobile, offre la possibilité à l’attaquant de mener plusieurs types d’exploit tel que :
 L’accès aux fichiers multimédias,
 L’accès à la messagerie mais aussi aux appels mobiles,
 La possibilité d’effectuer des messages et des appels.
I.2.1.2.1.2 : Stockage des données non sécurisé

La vulnérabilité basée sur le stockage des données non sécurisé est lié au fait de stocker
des données dans la base de données sans l’implémentés d’une sécurité. Les types de données
s’agit de :
 Bases de données SQL,
 Les fichiers journaux,
 Stockages de données XML ou fichiers manifestes.
Le vol des données non sécurisées peut avoir les conséquences commerciales suivantes
:
 Vol d'identité,
 Violation de la vie privée,
 Fraude,
 Dommages de réputation,
 Perte matérielle.
28
I.2.1.2.1.3 : Communication non sécurisée
La vulnérabilité liée à la communication non sécurisée est dû à l’insuffisance de
sécurité dans la communication entre le téléphone mobile et un autre périphérique (ordinateur,
téléphone). Qu’il s’agisse d’une communication TCP / IP, Wi-Fi, Bluetooth / Bluetooth-LE,
NFC, audio, infrarouge, GSM, 3G, SMS et autre, les données échangées doivent être sécurisé
et leurs confidentialité et authenticité ne doivent pas subir de modification.
Les risques liés à ce genre de vulnérabilité sont :
 Vol d’information,
 Alternation des données.
I.2.2 : Sécurité et protection des données personnelles des applications web

et mobile
Par ailleurs, il existe des acteurs qui contribuent énormément à la sécurité des applications
web et mobile mais aussi à la protection des données personnelles des utilisateurs de ces
applications. Dans ce document nous présentons deux de ces acteurs, il s’agit du CDP du
Sénégal et de l’OWASP.
Le CDP du Sénégal contribue énormément à la protection des données personnelles des
utilisateurs en imposant des directives à suivre et à respecter à toute entité qui effectue des
traitements des données à caractère personnel.
L’OWASP est un organisme à but non lucratif constitué de plusieurs personnes dont des
experts de la sécurité qui publie des documents gratuits sur les bonnes pratiques à suivre pour
améliorer la sécurité des applications web et mobile.
I.2.2.1 : CDP
Le CDP (Commission de Protection de Données personnel se définit comme une AAI
(Autorité Administrative Indépendante) qui a pour but d’assurer la protection des données à
caractère personnel des citoyens. On pourrait le considérer comme le gardien des données à
caractère personnel des citoyens.
La mission du CPD est de s’assurer de la protection des données à caractère personnel
qui peuvent faire l’objet d’un traitement numérique. Pour se faire, toutes personne qui effectue
des traitements des données à caractère personnel doivent impérativement se déclarer au sein
de ce comité afin d’exercer leurs activités conformément à la loi. Le but étant de permettre à
29
tout citoyen ou consommateur d’exercer leur droit à l’information, l’accès, l’opposition,
rectification et la suppression.
I.2.2.1.1 : Le droit des consommateurs
I.2.2.1.1.1 : Droit à l’information [17]

Chacun a un droit de regard sur vos données personnelles. Lorsque des données à caractère
personnel sont collectées directement auprès de la personne concernée, le responsable du
traitement doit fournir à celle-ci, au plus tard, lors de la collecte et quels que soient les moyens
et supports employés, les informations suivantes :
1. Son identité et, le cas échéant, celle de son représentant ;
2. La ou les finalités du traitement auquel les données sont destinées ;
3. Les catégories de données concernées ;
4. Le ou les destinataires ou les catégories de destinataires auxquels les données sont
susceptibles d’être communiquées ;
5. Le fait de savoir si la réponse aux questions est obligatoire ou facultative ainsi que
les conséquences éventuelles d’un défaut de réponse ;
6. Le fait de pouvoir demander à ne plus figurer sur le fichier ;
7. L’existence d’un droit d’accès aux données la concernant et de rectification de ces
données ;
8. La durée de conservation des données ;
9. Le cas échéant, l’éventualité de transferts de données à caractère personnel à
destination de l’étranger.
Lorsque les données à caractère personnel ne sont pas collectées auprès de la personne
concernée, les informations visées ci-dessus sont transmises à ladite personne au moment de
l’enregistrement des données ou, si leur communication est prévue, au plus tard lors de la
première communication.
I.2.2.1.1.2 : Droit d’accès [17]

Chacun a le droit de savoir si ses données personnelles font l’objet d’un traitement. Toute
personne physique justifiant de son identité a le droit de demander, par écrit, quel que soit le
support, au responsable d'un traitement des données à caractère personnel, de lui fournir :
1. Les informations permettant de connaître et de contester le traitement ;
30
2. La confirmation que des données à caractère personnel la concernant font ou ne font
pas l'objet de ce traitement ;
3. La communication, sous une forme accessible, des données à caractère personnel qui
la concernent ainsi que de toute information disponible quant à l'origine de celles-ci
;
4. Des informations relatives aux finalités du traitement, aux catégories de données à
caractère personnel traitées et aux destinataires ou aux catégories de destinataires
auxquels les données sont communiquées ;
5. Le cas échéant, des informations relatives aux transferts de données à caractère
personnel envisagés à destination d’un pays tiers.
Le droit d'accès d’un patient est exercé par le patient lui-même ou par l'intermédiaire d'un
médecin qu'il désigne. En cas de décès du patient, son conjoint non séparé de corps et ses
enfants, s'il s'agit d'un mineur, ses père et mère, peuvent l’exercer, par l'intermédiaire d'un
médecin qu'ils désignent.
Avertissement :
 Toute demande abusive sera jugée comme irrecevable, soit par le responsable du
traitement, soit par la Commission des données personnelles.
 Le responsable du traitement peut subordonner la délivrance d’une des données
personnelles au paiement d'une somme qui ne peut excéder le coût de la reproduction.
I.2.2.1.1.3 : Droit d’opposition

Toute personne physique ou consommateurs à le droit de s’opposer pour un motif légitime
au traitement de ses données à caractère personnel.
Dans cadre d’une application web et mobile, tout utilisateur à le droit de s’opposer au
traitement de leurs données à caractère personnel cela peut s’agir du nom, prénom, date de
naissance ou mail. Elles disposent du droit à être informé avant même de la publication de leurs
données à caractère personnel et peuvent décider ou non de leurs publications.
Mais ce traitement ne s’applique pas lorsque le traitement répond à une obligation légale.
I.2.2.1.1.4 : Droit de rectification et suppression [17]

Toute personne physique justifiant de son identité peut exiger du responsable d'un traitement
que soient, selon les cas, rectifiées, complétées, mises à jour, verrouillées ou supprimées les
31
données à caractère personnel la concernant, qui sont inexactes, incomplètes, équivoques,
périmées, ou dont la collecte, l'utilisation, la communication ou la conservation est interdite.
Si les données ont été transmises à un tiers, le responsable du traitement doit accomplir les
diligences utiles afin de lui notifier les opérations à effet.
I.2.2.1.2 : Niveau de contrôle

Le niveau de contrôle est un aspect qui est admis afin de veuillez à l’application et le respect
de la loi. Il est divisé en deux parties, la première qui vérifie le formulaire de l’instance, la
seconde destinée au contrôle qui est fait soit surplace ou en ligne.
Toute personne ou responsable qui s’absente aux obligations de la loi peut payer une amande
allant de 1 à 100 millions.
I.2.2.2 : OWASP
Le projet de sécurité des applications Web ouvertes est une organisation caritative mondiale
à but non lucratif dons le but est d’améliorer la sécurité des logiciels. Le directeur exclusif
actuel de l’OWASP est Mike McCamon. L’OWASP rend la sécurité des logiciels accessible à
tous afin de permettre aux entreprise et particulier d’améliorer la qualité de sécurité de leur
logiciel, il publie ainsi des logiciels et des documentations pour renforcer la sécurité des
applications.
Les documents publiés par l’OWASP en matière de sécurité sont disponibles sur une licence
logicielle gratuite et ouverte.
I.2.2.2.1 : Les principes de l’OWASP

 Gratuit et ouvert,
 Régi par un consensus approximatif et un code en cours d'exécution,
 Respectez un code d'éthique,
 Sans but lucratif,
 Pas motivé par des intérêts commerciaux,
 Approche fondée sur le risque.
Il compte beaucoup de projet varié dans plusieurs technologies, dans ce travail nous on
présentant l’un de ces projet qui est OWASP Security Shepherd.
32
Le projet OWASP Security Shepherd est une plate-forme de formation à la sécurité des
applications Web et mobiles. Security Shepherd a été conçu pour favoriser et améliorer la
sensibilisation à la sécurité d'un ensemble démographique de compétences variées. L'objectif
de ce projet est d'amener les novices ou les ingénieurs expérimentés AppSec à affiner leurs
compétences en tests de pénétration au statut d'expert en sécurité. [18]
Le projet OWASP Security Shepherd offre aussi bien que pour les novices et les
professionnels de la sécurité un cadre dans lequel ils pourront exercer des pentest dans un
environnement qui présente les mêmes conditions que la réalité. Aucune simulation n’est faite
et les vulnérabilisées sont basée sur le classement TOP 10 OWASP. Le but du projet OWASP
Security Shepherd n’est pas de formé des cybercriminels mais plutôt de les offrir les moyens
nécessaires pour participer à la sécurité des applications web et mobile.il fournit :
 Les outils pédagogiques pour la sécurité de toutes les applications [18],
 Une formation sur le pentest d'applications Web,
 Une formation sur le pentest d'application mobile,
 Un terrain de jeu sécurisé pour pratiquer les techniques AppSec,
 Des exemples de risques de sécurité réels.
33
Chapitre 3 : Cas d’utilisation
I.3.1 : Architecture de travail

L’architecture de travail représente tous les éléments utilisés pour la réalisation des cas pratiques
de ce travail. Ci-dessous l’architecture.
Pour réaliser ce travail, nous avons utilisé une architecture basée sur une pratique BYOD (Bring
Your Own Device). En environnement de production, ce type de pratique consiste à permettre aux
employés d’une entreprise d’emmener leurs appareils mobiles privés ou personnel (laptop, tablette,
smartphone) en entreprise. Dans notre travail, les appareilles physique utiliser dans notre
environnement de travail sont tous des appareils personnels.
Comme illustre l’image, notre architecture de travail est composée de quatre éléments. Un
ordinateur et un téléphone mobile pour interagir avec l’application web et l’application mobile, un
serveur web pour héberger l’application et un routeur pour l’interconnexion des périphériques.
34
 Le serveur d’hébergement : Héberge l’application web, il se compose d’un serveur
web et d’un SGBD (Système de gestion de base de données).
 Un router : utilisé pour l’interconnexion des équipements.
 Un hôte (ordinateur) : l’ordinateur dans l’architecture a été utilisé afin d’interagir avec
l’application et effectuer des exploits des vulnérabilités qui celle-ci présente.
 Téléphone mobile : Le téléphone mobile dans notre architecture à permit l’utilisation
de l’application web mobile pour la réalisation des cas pratique.
I.3.1.1 : Environnement de travail

Au cours de cette phase de cas pratique, nous avons utilisé plusieurs technologies qui ont
constitué notre environnement de travail afin de réaliser ce travail. Ces programmes ont permis
aussi bien à la réalisation des cas pratique d’application web que mobile.
I.3.1.1.1 : Critère de choix

Pour le choix des outils ou technologies (SE et logiciel) nous nous sommes basés sur des
solutions qui répondent aux critères suivants :
 Stable,
 Classé parmi les meilleurs,
 Libre d’accès,
 Possèdent une grande communauté,
 Possèdent une documentation bien détaillée.
La stabilité à constituer un critère de choix pour nous afin d’éviter de rencontrer divers
problèmes qui pourraient être irrésolvable, ainsi ralentir la réalisation de ce travail dans le temps
qui nous est impartie.
Nous avons choisi pour la réalisation de ce travail des solutions reconnut comme faisant partir
des meilleurs afin d’étendre les possibilités d’utilisation et fournir un travail de qualité. Nous
estimons que les solutions classées parmi les meilleurs ont été soumis à des tests d’utilisation et
sollicité pour leurs efficacités.
L’utilisation des logiciels libre d’accès, autrement dit des logiciels que tout le monde peut s’en
procurer est dans l’objectif de montrer que les outils qui peuvent être utilisé à des fins malveillantes
et bienveillantes sont à la portée de tout le monde.
35
Les solutions possédant une grande communauté constituant un grand avantage en cas de
problèmes rencontré au cours d’utilisation, mais aussi dans la documentation à cause du nombre
élevé de la communauté. Nous avons inséré ce critère de choix dans le choix des technologies qui
ont servi à la réalisation de ce travail afin de pouvoir interagir avec la communauté en cas de
problème d’utilisation ou d’incompréhension.
La documentation détaillée à constituer un critère de choix dans notre travail afin de nous
familiariser plus rapidement avec les solutions qui sont pour nous nouvelles.
I.3.1.1.2 : Serveur d’hébergement

Le serveur d’hébergement héberge l’application web qui à servit dans les cas pratiques des
vulnérabilités d’application web et mobile. Elle est constituée d’un serveur web et d’un SGBD. A
défaut d’insuffisance nous avons effectué l’intégralité de ces travaux en local.
L’hébergement en local a été effectué à l’aide du logiciel et environnement de
développement UwAmp. UwAmp est un environnement de travail qui est composé d’un serveur
web Apache, un système de gestion de base de données et du langage script PHP. La version du
serveur web, du SGBD et de PHP varient en fonction de la version d’UwAmp.
Dans notre cas pratique, nous utilisons la version UwAmp 3.1.0 avec pour version PHP
7.2.7, server web Apache 2.0 et le SGBD MySQL 5.7.11. Nous avons arbitrairement changé la
version de PHP pour une version plus récente dans le but d’exploiter le plein potentiel de PHP.
Pour se faire, nous avons installé la version UwAmp 3.1.0 dans une machine disposant d’un SE
Windows 7. Les caractéristiques de cette machine sont telles que, elle dispose d’une ram de 8Go,
un processeur i-core 3 avec 2,5 GH. UwAmp a été installé avec une version de MYSQL 5.7.11 et
Apache 2.8.18 comme illustré dans le tableau ci-dessous.
CARACTERISTIQUE DE L’HEBERGEMENT WEB
SE Windows 7
RAM 8G
ROM 300Go
UwAmp
HTTPD Apache 2.8.18
Technologie
SGBD MYSQL 5.7.11
PHP 7.2.7
Tableau 4 : Caractéristique de l’hébergement web
36
Nous avons choisi UwAmp à cause de sa portabilité et simplicité d’utilisation. Grace à sa
portabilité il nous a cependant été possible d’exécuter UwAmp dans diffèrent système sans avoir à
l’installer.
Nous avons porté notre choix au système d’exploitation Windows 7 pour installer UwAmp à
cause de sa stabilité avec le logiciel UwAmp.
I.3.1.1.3 : Hôtes clients

On note dans l’architecture deux type de client qui interagissant avec le serveur web. Le premier,
est un ordinateur et le second un téléphone mobile.
Avec l’ordinateur dans le schéma nous avons pu tester les vulnérabilisées d’application web en
interagissant au moyen d’un navigateur avec l’application.
Au moyen du téléphone mobile, nous avons pu tester les vulnérabilisées d’application mobile.
Pour se faire, nous avons installé au sein d’un téléphone mobile une application afin t’interagir
avec le serveur web.
I.3.1.1.4 : Application web

L’application web a été développe afin d’effectuer les cas pratiques des attaques sur
l’application web. Au cours de ce travail, nous avons développés une application qui simule le
paiement en ligne des factures via une carte VISA. Nous avons développé cette application avec
les mêmes caractéristiques qu’une application web mis en milieu de production seulement elle
n’inclut pas le mécanisme de paiement. Cette application respecte :
 Le format de base HTML définit par la W3C,
 Le modèle de développement MVC,
 Gestionnaire des dépendances libre avec Composer.
Développé avec les langages de programmation tel que : HTML 5, CSS3, JavaScript 1.3,
JSON, et PHP 7.2.7, elle est constituée.
I.3.1.1.5 : Application mobile

Afin de réaliser les cas pratique sur l’application mobile, nous avons conçu une application
mobile adaptée à nos besoins c’est-à-dire réalisés pour les types d’attaque mobile présentée dans
ce document.
37
Cette application a été réalisée avec la technologie react-native. Nous avons choisi cette solution
car elle répond à nos critères de choix, aussi à cause de sa flexibilité et inter portabilité.
En effet elle permet à la fois de concevoir des applications avec les mêmes technologies utilisées
pour le développement des applications web (JavaScript, JSON). Cela nous a été d’une grande aide
en gain de temps.
 Inter portable car elle permet de concevoir à la fois des applications pour le système
d’exploitation mobile IOS et Android.
I.3.1.1.6 : Outils de travaux
I.3.1.1.6.1 : Outils de test de vulnérabilités

Les outils de test de vulnérabilité qui ont servis dans les cas pratiques ont été choisis selon
nos critères de choix de technologies.
 OWASP ZAP : Est un outil crée par la communauté OWAP, il permet d’évaluer
le niveau de criticité de vulnérabilité d’application web. OZ (OWASP ZAP) est
une solution efficace pour l’audit technique des applications web, il est très
souvent utilisé par les cabinets d’audit ici au Sénégal. Au cours de ce travail il nous
a permis d’effectuer de détecter et effectuer des attaques par injections SQL.
 OWASP XENOTIX : Est un outil ou environnement de travail avancé conçut
pour la détection et l’exploitation des vulnérabilités XSS. Cet outil nous a permis
de réaliser le cas pratique portant sur l’injection de code.
 Sqlmap : Est un outil d’injection SQL automatisé et reprise de base de données.
Au cours de ce travail, nous l’avons sollicité dans le cas pratique de l’exposition
des données sensibles.
 Cai&Abel : est l’outil que nous avons utilisé au cours de notre travail pour casser
un mot de passé haché avec une attaque par dictionnaire dans le cas pratique
d’authentification brisée.
 Wireshark : Est l’outil permettant de faire la capture des paquets au sein d’un
réseau. Nous l’avons utilisé au cours de ce travail pour effectuer une capture des
données envoyé par l’application mobile au serveur web dans le cas pratique d’une
communication non sécurisé.
38
Chapitre 4 : Attaque et recommandation
I.4.1 : Exploit des vulnérabilités
I.4.1.1.1 : Injection
I.4.1.1.1.1 : SQLI
SQLI ou SQL injection est un exploit qui vise à faire une injection sur un code SQL. C’est-à-
dire insérer une expression qui modifiera l’exécution normale d’un code SQL.
Un exploit de type injection SQL s’effectue sur tout type d’entrée qui interagit avec la base de
données, cela peut-être un formulaire de connexion, un paramètre de requête ou autre.
a. Description du cas pratique
Figure 10 : Scan des vulnérabilités SQLi au sein de l’application

L’image ci-dessus présente le résultat du scan de vulnérabilités de type SQL injection dans
l’application, il présente une attaque pouvant être effectué.
39
Dans ce cas pratique, l’attaquant effectue une injection SQL dans le formulaire de connexion de
l’application afin de s’authentifier. L’expression renseigné a été fournit par l’outil OWASP ZAP.
Figure 11 : Cas pratique attaque SQLi

L’attaquant parvient à accéder au compte qu’il souhaite en renseignant le login suivit de
l’expression SQL, bien que l’application utilise une fonction de hachage MD5 pour hacher les mots
de passes.
40
Figure 12 : Connexion après attaque de type SQLi
L’attaquant parvient à ce connecter grâce à son expression permettant d’effectuer une SQL
injection.
I.4.1.1.1.2 : Injection de code

Une attaque par injection de code peut être effectué dans n’importe qu’elle entré de texte ne
disposant pas d’une certaine mesure de sécurité.

Dans le cas pratique ci-dessous l’attaquant injecte dans le champ texte, un code JavaScript
malveillant. Le but étant de permettre à l’attaquant d’avoir un contrôle de tous les navigateurs des
utilisateurs qui consulteront cette page.
Ci-dessous un scenario du cas pratique.
41
http://www.site.com/page.php
1 2
Attaquant Utilisateur
Figure 13 : Scenario du cas pratique injection du code

Ce scenario permet d’expliciter le cas pratique concernant l’attaque par injection de code.
1. L’attaquant insère un code malveillant au sein d’une page (le code est en réalité inséré
dans une base de données)
2. Lorsque l’utilisateur consultera cette page, ce code malveillant s’exécutera au sein de
son navigateur.
3. Grace au code de malveillant, l’attaquant peut désormais interagir avec le navigateur des
autres utilisateurs.
Figure 14 : Cas d’une attaque par injection de code

42
L’attaquant dans l’image ci-dessus insère le script malveillant (fournit par l’outil d’exploit XXS
Xenotix) dans un commentaire qu’il tente de faire passer pour un commentaire normal.
Figure 15 : Publication de commentaire par l’attaquant

Le script publié par l’attaquant n’est pas visible dans la page, seul son message. Le script est
considéré par le navigateur comme script faisant partir de la page, il est exécuté à chaque
consultation de la page.
Dans l’image ci-dessous, l’attaquant effectue un exploit de type phishing en redirigeant les
utilisateurs qui consulteront la page, dans une page d’authentification facebook afin de capturer les
informations qui renseigneront (login, password).
43
Figure 16 : Attaque de type phishing avec Xenotix
Cette image montre l’utilisation de l’exploit phishing avec l’outil Xenotix.
Figure 17 : Vue utilisateur avant injection de code

L’image ci-dessus montre la vue utilisateur avant l’exploit de l’attaquant.
44
Figure 18 : Vue utilisateur après injection de code
Dans cette vue, l’utilisateur est redirigé vers une fausse page ‘authentification facebook, cela est
causé par l’exploit de l’attaquant. Les informations renseignées par l’utilisateur seront envoyées à
l’attaquant.
45
Figure 19 : Rendu de l’exploit par injection de code
Les informations d’authentification renseigné par l’utilisateur son envoyé à l’attaquant, comme le
montre l’image ci-dessus.
I.4.1.1.2 : Exposition des données sensible

La vulnérabilité d’exposition des données sensible consiste à exposé les données d’un utilisateur
tel que son mail, son mot de passe ou encore sa date de naissance.

Dans ce cas pratique, l’attaquant effectue la même attaque SQLi précédente ; mais cette fois de
manière différente afin de ressortir les informations relatives à la base de données
Figure 20 : SQLi avec l’outil Sqlmap

L’image ci-dessus montre une instruction sqlmap permettant d’effectuer une injection SQL avec
la méthode POST exploitant les vulnérabilités rencontrées dans le login et mot de passe au cours
du cas pratique de l’injection de type SQL.
sqlmap -u "http://192.168.1.19/site/index.php" –data
"mail=jkljklj&password=kjlkjlkj&send=Connexion" -p "mail,password" --method POST -D base
-T user --flush --dump
46
Figure 21 : Illustration d’une exposition de données sensibles
L’image montre les informations contenues dans la base de données, il s’agit des données
personnelles des utilisateurs en clair. On peut remarquer dans cette image, le courriel, le login, le
rôles (privilège) de chaque utilisateur mais également le mot de passe de chaque utilisateur haché
avec la fonction de hachage MD5.
I.4.1.1.3 : Authentification brisée

Une attaque par authentification brisé consiste à avoir le contrôle d’un compte en utilisant des
mécanismes manuels ou automatiques. Cela peut s’agir des attaques par force brute dans le cas
d’un mécanisme automatisé. Cela pourrait aussi s’agir d’une attaque par identification par défaut
(mot de passe et login admin ou Root).

Dans ce cas pratique, l’attaquant effectue une attaque par force brute sur un mot de passe haché
avec la fonction de hachage MD5 afin d’obtenir un mot de passe en clair.
Le mot de passe utilisé dans ce cas corespend au mot de passe de l’admi.
Figure 22 : Cas d’une attaque par authentification brisé
47
L’attaquant effectue une attaque par force brute du mot de passe haché de l’administrateur et
obtient ainsi le mot de passe en clair.
I.4.1.2 : Application mobile
I.4.1.2.1 : Stockage des données non sécurisé

Les applications mobiles présentant des vulnérabilités de stockage non sécurisé sont celle qui
autorise un stockage de données en clair ou encore avec une fonction, algorithme de chiffrement
faible. Ces informations à caractères personnel stockées en clair peuvent entrainer un vol d’identité,
violation de vie privé ou encore un dommage de réputation.

L’utilisateur effectue un enregistrement dans la base de données à travers l’application mobile.
Pour se faire, il entre dans l’application un login, un courriel et un mot de passe.
Figure 23 : Enregistrement d’un utilisateur dans la base de données

48
Dans cette image un utilisateur effectue un enregistrement de compte dans l’application mobile.
Figure 24 : Utilisateur enregistré dans l’application mobile

Cette image montre les informations de l’utilisateur qui a été enregistré dans la base de données
au moyen de l’application mobile. Le mot de passe est haché avec une fonction de hachage MD5
et peut à tout moment être vue en clair compte tenu de l’inefficacité de MD5.
I.4.1.2.2 : Communication non sécurisée

L’utilisateur de l’application mobile échange des informations avec le serveur au moyen de son
application. Les informations échangées entre le client et le serveur passant par le réseau. La
communication non sécurisée est lorsque l’information échangée entre client-serveur ne disposant
d’aucune mesure de sécurité, c’est-à-dire lorsque les informations peuvent être lue en clair.

Ce cas pratique consiste à intercepter une communication entre l’application web et le serveur
web dont le but de voir les informations échangées.
Ci-dessous une image pour illustrer l’environnement dans du cas pratique.
49
Figure 25 : Interception d’une communication non sécurisée
Dans cette image montre un attaquant interceptant une communication non sécurisée entre un
téléphone mobile est le serveur. L’homme du milieu (l’attaquant dans l’image) peut voir
l’intégralité du trafic échangé, si les données échangées ne sont pas chiffrées, il les verra en clair,
ce qui est le cas dans l’image ci-dessous
50
Figure 26 : Données envoyées au serveur web par l’application mobile
L’image ci-dessus est une capture du Stream HTTP de l’outil wireshark. Elle présente les
données envoyées par l’application mobile au serveur web. On peut constater dans cette image les
informations échangées sont lisible en clair, la communication entre le téléphone mobile au moyen
de l’application et le serveur web n’est pas chiffrée.
51
I.4.2 : Recommandations
Cette section est consacrée aux recommandations à prendre en compte pour renforcer la
sécurité contre les types d’exploits illustré ci-dessus dans l’exploit des vulnérabilités sur les
applications web et mobile.
Les recommandations préconisées dans ce document ont été tirées de : les
recommandations faites par l’OWASP pour la sécurité des applications web et mobile, des bonnes
pratiques adoptées par des développeurs professionnels et les bonnes pratiques adoptées par des
experts du domaines.

Dans ce cadre nous abordons les bonnes pratiques à prendre en compte afin d’éviter d’être
vulnérable aux exploits sur les applications web. Les recommandations faites dans ce document
ont été élaborées en fonction des vulnérabilités traité dans ce dernier.
I.4.2.1.1 : Injection
I.4.2.1.1.1 : SQLi
Afin d’éviter les attaques de type SQL injection présenté dans notre cas pratique, il est essentiel
de préserver l’authenticité des requêtes SQL envoyé au SGBD (Système de gestion de base de
données). Pour cela nous recommandons :
 L’utilisation des Déclaration préparées,
 Restreindre les droits de l’utilisateur de la base de données de l’application.
a. Utilisation des déclarations préparées

L’avantage d’utilisation d’une requête préparé est qu’elle exécute une requête SQL dans un
espace stocké dans le moteur de base de données avant de pouvoir l’exécuter dans l’application. Si
la requête parvient à être exécutée avec succès, elle pourra alors être utilisée dans la base de
données, au cas contraire la requête SQL sera remplacée par une valeur vide et aucune requête ne
sera envoyée au SGBD de l’application pour une interaction avec la base de données.
Dans le cas où une personne malicieuse venait à effectuer une attaque par injection SQL, la
valeur de la requête sera remplacée par une valeur vide.
52
Ci-dessous un tableau présentant les fonctions utilisées afin d’effectuer des requêtes préparées
selon les langages et technologies JEE, NET, PHP, SQLite
UTILISATION DE PREPARE STATEMENT
LANGAGE TECHNOLOGIE FUNCTION
JEE Variable de liaison PreparedStatement ()
SqlCommand(),
NET Variable de liaison
OleDbCommand ()
Prepare(),
PHP PDO
BindParam ()
SQLite Variable de liaison sqlite3_prepare ()
Tableau 5 : Tableau de fonction prepare statement

Le tableau ci-dessus présente la déclaration des requetés préparé en fonction des langages de
programmation.
Figure 27 : Fonction PHP d’authentification d’utilisateur avec Prepare statement
53
Après avoir adopté l’utilisation des requêtes préparée avec la fonction PHP prepare () nous
avons constaté que le même scan effectué par OWASP ZAP ne présente plus de vulnérabilité.
Figure 28 : Résultat du scan de l’application avec l’utilisation des requêtes préparé

L’image ci-dessus montre un scan de vulnérabilité SQL injection effectué sur l’application web.
Aucune vulnérabilité SQL n’est cependant détectée.
b. Restreindre les droits de l’utilisateur de la base de données de

l’application
La restriction des droits de l’utilisateur de la base de données est très primordiale, elle permet
de restreindre certain droit aux utilisateurs afin qu’ils ne puissent plus accéder à une ou plusieurs
ressources. Dans le cas où un utilisateur malveillant venait à interagir avec les processus stockés
pour commettre une attaque, certaine ressource ne lui serrant pas accessible, cela limitera
considérablement le risque que la sécurité de sa base de données soit compromise ou encore que
l’attaquant dispose de peu de droit s’il venait à compromettre la sécurité de la base de données.
I.4.2.1.1.2 : Injection de code

Une attaque par injection de code, comme son nom l’indique consiste à injecter du code dans
une page dans le but de provoquer des actions. L’objectif de cette attaque est de pouvoir placé dans
54
une page web un code qui à chaque consultation de cette page, sera lue comme code faisant partir
de la page et va en conséquence être exécuté. Pour se prémunir de ce genre d’attaque, nous
recommandons donc :
 Ne jamais insérer de données non fiables sauf dans les emplacements autorisés [19],
 Convertir les caractères spéciaux par leurs codages d’entité HTML.
a. Ne jamais insérer des données non fiables

L’insertion des données non fiable est toute insertion des données qui dans la page web et qui
peuvent en conséquence être visible par le client. Cela peut s’agir : d’un script JavaScript, d’un
nom d’attribut HTML, un commentaire HTML ou encore d’un CSS qui peut ressortir des
informations essentielles pour faciliter une attaque par injection de code.
b. Conversion des caractères spéciaux

Une fois le code injecté, lors du chargement de la page web par le navigateur, les caractères
spéciaux sont par défaut considérés comme code source faisant partir de la page et sont en
conséquence interprété par le navigateur. Des personnes mal intentionnées peuvent insérer des
scripts à des mauvaises fins pour provoquer des actions. La conversion des caractères spéciaux
avant l’insertion dans la base de données ou avant l’affichage de ces caractères au rendu permettra
ainsi au navigateur de distingué le code source de la page des caractères spéciaux qui seront
affichés.
Pour PHP, la fonction htmlspecialchars() est une excellente solution pour la conversion des
caractères spéciaux par leurs valeur HTML.
I.4.2.1.2 : Exposition des données sensible

Les données sensibles ne s’agissent pas nécessairement des données qui peuvent aider à
compromettre la sécurité d’une application web comme un mot de passe, d’après OWASP il s’agit
au contraire de toutes données jugé sensibles [20].
La chose primordiale à faire est de déterminer le besoin de protection des données en transit ou
au repos. C’est-à-dire déterminé les données qui seront échangées ainsi que la manière dont ils
seront échangés au sein de l’application et ceux qui ne le seront pas, car certaines données relèvent
des lois (par exemple PCI DSS pour la protection des données financières).
55
Les recommandations faites pour éviter toute exposition des données sensibles faites par
l’OWASP sont :
 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. [20]
 Appliquer les contrôles selon la classification. [20]
 Ne stockez pas inutilement des données sensibles. Jetez-le dès que possible ou utilisez la
tokenisation conforme à la norme PCI DSS ou même la troncature. Les données non
conservées ne peuvent pas être volées.
 Assurez-vous de chiffrer toutes les données sensibles au repos.
 S'assurer que des algorithmes, des protocoles et des clés standards à jour et solides sont en
place ; utiliser une bonne gestion des clés.
 Chiffrer toutes les données en transit avec des protocoles sécurisés tels que TLS avec des
chiffrements Perfect Forward Secrecy (PFS), une hiérarchisation de chiffrement par le
serveur et des paramètres sécurisés. Appliquez le chiffrement à l'aide de directives telles
que HTTP Strict Transport Security ( HSTS ).
 Désactivez la mise en cache pour les réponses contenant des données sensibles.
 Stockez les mots de passe en utilisant de fortes fonctions de hachage adaptatives avec un
facteur de travail (facteur de retard), comme Argon2 , scrypt , bcrypt ou PBKDF2.
 Vérifiez indépendamment l'efficacité de la configuration et des paramètres.
I.4.2.1.3 : Authentification brisée

Une attaque dans le but de briser une authentification peux s’effectué de plusieurs manières
possibles. Dans le cas pratique que nous avons abordé, il s’agit de déchiffrer un mot de passe haché
avec la fonction de hachage MD5. Dans certain autre cas il peut s’agir d’une authentification à un
compte avec des accès par défaut (exemple : admin, admin). Afin d’éviter ce genre d’attaque, nous
recommandons :
 Ne pas utiliser le mot de passe par defaut,
 Utiliser des mots de passes complexes,
 Haché les mots de passe avec une fonction de hachage robuste,
56
 Effectuer une authentification forte.
a. Utiliser des mots de passes complexes

Afin de renforcer la sécurité des utilisateurs de l’application, l’application web doit encourager
l’utilisation de mots de passe complexe. Un mot de passe complexe se définit comme mot de passe
qui :
 Comporte au minimum 8 caractères,
 Ne contient aucun nom d’utilisateur, de famille ou d’entreprise,
 Combine des lettres minuscules, majuscules, des chiffres, des caractères spéciaux et/ou
nationaux comme les lettres accentuées,
D’autres recommandations sur les mots de passe à prendre en compte sont aussi, le changement
de passe régulier et ne pas utiliser le même mot de passe dans d’autre plateforme.
b. Haché les mots de passe avec une fonction de hachage robuste

Les mots de passe haché et enregistrer dans la base de données avec laquelle communique
l’application web doivent être haché avec un algorithme de hachage robuste afin d’éviter qu’il ne
soit cassé au cas où un utilisateur de la base de données venait à les consulter.
c. Effectuer une authentification forte

L’authentification forte est un procédé qui requiert la concaténation d’au moins deux facteurs
d’authentification. Pour une application web, elle apporte une autre couche de sécurité à son
mécanisme d’authentification.
L’application doit solliciter un tel procéder pour renforcer d’avantage sa sécurité mais aussi pour
permettre à ses utilisateurs de réduire le risque d’une connexion à leurs issus.
Par ailleurs, nous recommandons aussi l’utilisation des API de sécurité des applications telles
que Google pour l’authentification des utilisateurs de l’application avec leur compte Google
(Gmail), le protocole OAuth 2.0 est une excellente solution pour un tel procédé. Pour une
application web, elle permettra de faire l’authentification des utilisateurs de cette application à
partir de leurs comptes Gmail.
57
I.4.2.2 : Application Mobile
I.4.2.2.1 : Stockage des données non sécurisé

Les données non sécurisées stocké dans une base de données peuvent entrainer plusieurs dégâts.
Des données à caractère personnel et sensible tel que le numéro de carte bancaire, numéro de
téléphone, mot de passe et autre, peuvent nuire la confidentialité des utilisateurs de l’application et
à la crédibilité de l’application elle-même si elle venait à être stocké en clair.
Les recommandations que nous faisons donc pour éviter une vulnérabilité de stockage de
donnée non sécurisé est de :
 Utiliser une fonction de hachage pour hacher les données,
 Chiffrer les données stockées dans la base de données,
a. Utiliser une fonction de hachage robuste pour hacher les données

L’utilisation de fonction de hachage robuste pour vérifier l’intégrité d’une information tel que
mot de passe doit être adopté pour renforcer la sécurité des informations stocké dans la base de
données dans le cas où une tierce accéda à la base de données.
b. Chiffrer les données stockées dans la base de données

Les données en cours de traitement ou au repos dans la base de données doivent être chiffré afin
de garantir leurs confidentialités. Si ces données venaient à être volées ou intercepté dans le réseau,
ces données ne seraient pas affichées en clair.
I.4.2.2.2 : Communication non sécurisée

Les communications non sécurisées sont exposées en clair dans le réseau. Dans le cas où un
tiers venait à sniffer le réseau, il verrait en clair l’intégralité des échanges entre l’application et le
serveur web. Afin donc d’éviter un tel risque il est conseillé de chiffrer la communication pour que
les données interceptées ne soient pas lisibles.
 Utiliser le Protocole HHTPS
a. Utiliser le protocole HTTPS

L’utilité du protocole HTTPS est de permettre le chiffrement de la communication dans le but
de garantir la confidentialité et l’intégrité des échanges.
58
Chapitre 5 : WAF (Web Application Firewall)
I.5.1. Définition
Un WAF ou pare-feu applicatif web aide à protéger les applications web en filtrant et en surveillant
le trafic HTTP entre une application web et Internet. Il est installé en série, en amont du serveur
web et analyse le traffic avec avant qu’il atteigne l’application web et protège généralement les
applications web des attaques notamment de type cross-site forgery, cross-site scripting (XSS),
d’inclusion de fichier et d’injection SQL. Un WAF est une protection du protocole de la couche 7
(dans le modèle OSI) et n’est pas conçu pour défendre contre tous les types d’attaques. Cette
méthode d’atténuation des attaques fait généralement partie d’une suite d’outils qui forment une
défense holistique contre une variété de vecteurs d’attaque.
Un WAF suit un ensemble de règles souvent appelé politiques. Ces politiques visent à se protéger
des vulnérabilités dans l’application en filtrant le trafic malveillant. La valeur d’un WAF provient
en partie de la rapidité et de la facilité avec laquelle la modification de politique peut être appliquée,
permettant une réponse plus rapide aux différents vecteurs d’attaque. Lors d’une attaque DDoS, le
mécanisme de rate limiting peut être rapidement activé en modifiant les politiques du WAF.
Suivant sa technologie, un WAF pourra utiliser différents moyens de détection : regex, blacklisting,
whitelisting, signatures, etc.
I.5.2. Caractéristiques du WAF
Un WAF peut être mis en place de trois façons différentes, chacune ayant ses propres avantages et
inconvénients :
59
 Un WAF basé sur le réseau est généralement matériel. Installés au niveau local, les WAF
basés sur le réseau réduisent la latence mais représentent l’option la plus coûteuse. Ils
nécessitent de l’espace et la maintenance des équipements physiques.
 Un WAF basé sur l’hôte peut être entièrement intégré dans le logiciel d’une application.
Cette solution est moins coûteuse qu’un WAF basé sur le réseau et offre plus de possibilités
de personnalisation. L’inconvénient d’un WAF basé sur l’hôte est la consommation des
ressources du serveur local, la complexité de la mise en œuvre et les coûts de maintenance.
Ces composants nécessitent généralement du temps d’ingénierie et peuvent s’avérer
coûteux.
 Les WAF basés sur le cloud offrent une alternative abordable et très facile à mettre en
œuvre ; généralement, ils proposent une installation clé en main aussi simple qu’un
changement de DNS pour rediriger le trafic. Les WAF basés sur le cloud ont également un
coût initial minimal, car les utilisateurs paient tous les mois ou tous les ans pour la sécurité
en tant que service. Les WAF basés sur le cloud peuvent également offrir une solution
continuellement mise à jour pour se protéger contre les menaces les plus récentes sans
aucun travail ni coût supplémentaire pour l’utilisateur. L’inconvénient d’un WAF basé sur
le cloud tient au fait que les utilisateurs transfèrent la responsabilité à un tiers, par
conséquent, certaines de ses fonctionnalités peuvent constituer une zone noire pour eux.
I.5.3. Filtrage Applicatif

I.5.3.1. Comment protéger un site web avec un firewall applicatif ou WAF ?
La protection d’un site ou application web est devenue absolument indispensable pour trois raisons
majeures :
 La fréquence et le caractère systématique des attaques qui n’épargnent aucun site,

 La richesse fonctionnelle toujours plus grande des sites qui stockent beaucoup
d’informations sur les internautes,
 La pression du marché pour un web sécurisé comme en témoigne l’affichage durci par
Google des sites non protégés par un certificat SSL,
Un Web Application Firewall WAF, soit un firewall applicatif, est une solution qui apporte de
nombreux outils complémentaire à un firewall réseau pour sécuriser un site web:
 Un filtrage applicatif pour sécuriser votre site contre les attaques applicatives comme
les injections SQL, le cross site scripting et de nombreuses autres attaques répertoriées
 Un load balancing et de l’offloading SSL pour améliorer la performance et les temps de
réponse de votre site.
On parle également d’UTM, « Unified threat management », quand on combine le WAF avec
les fonctions suivantes :
 Un firewall réseau très complet pour sécuriser le serveur qui héberge le site
 Une prévention DDOS et IPS pour bloquer le trafic illégitime
60
I.5.3.2. Filtrage WAF
Par rapport à un firewall réseau, le pare-feu applicatif ajoute un niveau supplémentaire de sécurité
en bloquant en amont les requêtes illégitimes non traitées par les fonctions de filtrage réseau.
Déployez en quelques clics sur vos sites web les règles de protection contre les comportements
illégitimes sans avoir vous-même à en être un expert :
 Bloquer le trafic de sources avec une mauvaise réputation,

 Injections SQL,
 Cross site scripting ou XSS
 Bloquer des types de comportement considérés comme des attaques, chaque fournisseur
met à jour une liste très complètes des attaques avancées répertoriées
 Analyse de comportement utilisateur, par laquelle le WAF va « répertorier » des profils de
comportement et écarter ceux jugés comme dangereux,
 Application de « liste noire » ou « liste blanche », par exemple pour n’autoriser l’accès à
une page qu’à un utilisateur qui s’est déjà identifié et dispose d’un cookie,
 Analyse préliminaire d’un fichier envoyé sur l’application web, afin de filtrer les fichiers
jugés malveillants avant même qu’ils soient chargés sur les serveurs applicatifs
Ce trafic et ces requêtes sont bloqués en amont de vos serveurs web qui sont ainsi véritablement
protégés.
Le WAF permet ainsi de compléter les sécurités de l’applicatif sans avoir à intervenir sur le code.
De même, il est souvent plus simple et rapide de mettre à jour les règles du WAF que de maintenir
et de tenir parfaitement à jour ses composants applicatifs.
I.5.4. Les Types de WAF

D’un point de vue configuration, un WAF pourra opérer suivant deux modes : logging ou blocking.
Dans le mode logging, les requêtes suspectes seront enregistrées, mais pas bloquées. Ce type de
configuration est généralement adopté lors de l’installation d’un WAF, pour éviter dans un premier
temps les “faux positifs” et donc éviter de bloquer du traffic légitime.
Dans le mode blocking, les attaques détectées sont bloquées, et le traffic dangereux ne parvient
pas à l’application web.
I.5.5. Enjeux et perspectives
I.5.5.1. Enjeux
Pour un site présentant un trafic déjà substantiel, avec une marque et une visibilité forte, a fortiori
pour site e-commerce, le WAF devient rapidement indispensable. Bien souvent l’écart pour passer
sur un UTM n’est pas très élevé et apporte un complément de protection sur une seule solution
intégrée.
alfa-safety préconise souvent à nos clients pour des sites de plus de 100.000 visites/mois la solution
SG-UTM de Sophos qui est un standard du marché et propose un WAF/UTM de milieu de gamme
très performant tout en restant abordable et simple à configurer. Si l’on prend en compte l’ensemble
61
des rôles assurés, cette solution tout en un est bien plus compétitive que la combinaison de
différents services ajoutés au fil du temps, sans compter la simplicité d’une interface centralisée et
les pertes en temps et en chiffre d’affaires évitées lors des gestion d’incident.
I.5.5.2. Perspectives
Les web application firewalls et les filtres ajoutent une forte couche de sécurité aux applications
web. Mais malgré cela, des entreprises continuent à se faire pirater. Ces défenses sont donc une
couche supplémentaire que l’on vient ajouter à la sécurité mais sur laquelle on ne peut pas
entièrement se reposer. Les WAF et les filtres s’apparentent à des filets de sécurité.
Filtres et WAF ont chacun des failles qui permettent de les contourner, afin d’attaquer des
applications vulnérables. La meilleure protection consiste donc à assurer la qualité du code de ses
applications, en considérant l’utilisation de filtres et de pare-feu applicatifs comme un complément.
62
Conclusion
En Résumé, notre travail intitulé attaques et contre-mesures sur les applications web et mobile
a consisté à présenter les vulnérabilisées des applications web et mobile et leurs mesures de
préventions. Dans l’intérêt de répondre à notre problématique, celle de combler le besoin de
sécurité des applications web et mobile, nous nous sommes fixés pour objectif, d’abord de faire
une étude des vulnérabilités rencontré sur les applications web et mobile, ensuite faire une étude
sur les mesures de préventions contre ces vulnérabilités. Enfin faire des recommandations des
bonnes pratiques à adopter pour ne pas être exposé à ses ces derniers-ci.
L’efficacité des recommandations faite dans ce document a pu être vérifiée avec des outils
attestés par des experts de la sécurité des applications web et mobile tel qu’OWASP. Nous avons
effectué des tests d’analyse de vulnérabilités avant la mise en vigueur des recommandations et
après la mise en vigueur des recommandations. Nous avons ainsi pu apprécieriez la pertinence et
l’efficacité des recommandations faites.
Au cours de ce travail nous avons faits face à des difficultés, mais ces difficultés nous ont permis
de nous surpassés et atteindre nos objectifs.
Toutefois le risque zéro n’existe pas, les technologies évoluent avec le temps, les solutions de
sécurité qui auparavant jugé efficace perdent leurs efficacités dans le temps. La sécurité demeure
un perpétuel challenge, « Dans un environnement qui change, il n'y a pas de plus grand risque que
de rester immobile ».
63
Bibliographie
1. Joseph Gabay, David Gabay, UML2 analyse et conception, DUNOD Edition, 16 avril
2008.
2. Christophe Aubry, HTML5 et CSS3, Eni Edition, 2012.
3. Luke Welling, PHP et MySQL, PERSON Edition, 2009.
4. Nicolas Froidure, JavaScripts Le Guide Complet, micro application édition, 2013.
5. Craig Hunt TCP/IP Network Administration, O’REILLY edition, 2002.
6. James Graham Cyber Security Essentials, CRC PRESS Edition, 2010.
7. Justin Clarke SQLInjection attacks and defense, Elsevier Edition, 2008
64
Webographie
8. CERN, l'historique du projet WWW, [En ligne],
http://info.cern.ch/hypertext/WWW/History.html (page consultée le 4 aout 2019)
9. W3C, la mission du W3C, [En ligne], https://www.w3c.fr/a-propos-du-w3c-france/la-
mission-du-w3c/ (page consultée le 23 septembre 2019)
10. MOZILLA, méthode de requête, [En ligne],
https://developer.mozilla.org/fr/docs/Web/HTTP/M%C3%A9thode (page consultée le
23 septembre 2019 11h 03)
11. Watis, URI, [En ligne], https://whatis.techtarget.com/definition/URI-Uniform-
Resource-Identifier (page consulté le 21 septembre 2019 à 10h)
12. WEBSECURITY, Qu4est ce qu’u certificat SSL, [En ligne],
https://www.websecurity.digicert.com/security-topics/what-is-ssl-tls-https (page
consulté le 30 septembre 2019 à 20h)
13. IETF, SLL Protocole, [En ligne], https://tools.ietf.org/html/rfc5246 (page consulté le
30 septembre 2019 à 20h)
14. FORTINET, The Theat Landscape, [En ligne],
https://training.fortinet.com/local/staticpage/view.php?page=library_the-threat-
landscape (page consulté le 5 septembre 2019 à 09h)
15. OWASP, Injection, [En ligne], https://www.owasp.org/index.php/Injection_Theory
(page consulté le 4 octobre 2019 à 10h)
16. OWASP, Top 10 vulnerability web, [En ligne],
https://info.sucuri.net/hubfs/images/owasp-ebook-2019/sucuri-ebook-OWASP-top-
10.pdf (page consulté le 6 octobre 2019 à 21h)
17. CDP, Comprendre vos droits, [En ligne], https://www.cdp.sn/content/comprendre-vos-
droits (page consulté le 29 septembre 2019 à 07h)
18. OWASP, Les principes, [En ligne],
https://www.owasp.org/index.php/OWASP_Security_Shepherd (page consulté le 29
septembre 2019 à 11h)
19. OWASP, Aide-mémoire sur la prévention des scripts intersites [En ligne]
https://www2.owasp.org/www-project-cheat
65
sheets/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html (page
consultée le 12 janvier 2020 à 08h 15)
20. Exposition des données sensibles [En ligne] https://owasp.org/www-project-top-
ten/OWASP_Top_Ten_2017/Top_10-2017_A3-Sensitive_Data_Exposure (page
consultée le 13 janvier 2020 à 10h 30)
21. http://info.cern.ch/hypertext/WWW/History.html le 4 aout 2019 à 19h,
22. https://webfoundation.org/about/vision/history-of-the-web le 4 aout 2019 à 19h,
23. https://bencherifcheikh.wordpress.com/2012/08/04/le-protocole-http/ 15 septembre
2019 à 20h,
24. https://whatis.techtarget.com/definition/URI-Uniform-Resource-Identifier 21
septembre 2019 à 10h,
25. https://www.w3c.fr/a-propos-du-w3c-france/la-mission-du-w3c/ 4 aout 2019 à 19h,
26. https://www.w3c.fr/a-propos-du-w3c-france/la-mission-du-w3c/ 23 septembre 2019 à
10h, https://developer.mozilla.org/fr/docs/Web/HTTP/M%C3%A9thode 23 septembre
2019 à 11h,
27. http://blog.sienerinformatique.com/quest-ce-quune-attaque-par-injection/ 5 septembre
2019 à 20h,
28. https://www.lemondeinformatique.fr/actualites/lire-30-milliards-d-appareils-connectes-
en-2020-53540.html 15 septembre 2019 à 10h,
29. https://training.fortinet.com/local/staticpage/view.php?page=library_the-threat-
landscape 5 septembre 2019 à 9h,
30. https://www.owasp.org/index.php/Injection_Theory 4 octobre 2019 à 10h 20
31. https://info.sucuri.net/hubfs/images/owasp-ebook-2019/sucuri-ebook-OWASP-top-
10.pdf 6 octobre 2019 à 21h,
32. https://www.juniperresearch.com/press/press-releases/digital-banking-users-to-reach-
2-billion 30 octobre 2019 à 15h,
66
Annexes
Réalisation et cas pratique et recommandation pour les applications web et
mobile
Dans ce cadre d’annexe que nous avons consacré consacrés à la présentation des cas pratiques
de manières détaillés, nous présentons quelques cas pratiques présenté dans le document.
1- L’outil OWASP ZAP
Navigateur Application
OWASP ZAP fait également office de proxy, car il se place entre le navigateur et l’application
avec laquelle il interagi. Il peut ainsi de se fait envoyer des requêtes ou les récrire.
Grace à cet outil, nous avons effectués des scans de vulnérabilité sur l’applications web. L’outil
propose 2 types scan, le scan manuel et automatique. Dans notre cas, étant donné que nous scannons
une vulnérabilité bien spécifique, nous avons opté pour un scan manuel.
67
Dans l’image ci-dessus, nous renseignons l’adresse du site à scanné. 192.168.1.18 qui est
l’adresse du serveur qui héberge l’application web puis /site/index.php qui est le répertoire ainsi
que le fichier index du site web.
L’image suivante montre le résultat après lancement dans le navigateur.
68
A cette étape nous avons lancé une indexation sur le site afin de ressortir son contenue, comme
montre l’image suivante.
Après avoir fait une indexation du répertoire du site web, nous avons effectué une analyse
passive avec Spider Ajax.
69
Spider Ajax effectue ainsi une attaque passive sur l’application, les informations collectées après
l’attaque passif aideront à l’analyse actif.
Au cours de l’analyse nous avons effectué une analyse typiquement SQL injection.
Les résultats présentent des vulnérabilités SQL avec l’attaque possible.
70
L’image ci-dessus montre la fonction PHP d’authentification utilisé dans l’applications, nous
pouvons constater que la connexion est faite avec l’objet PDO mais n’utilise aucune requête
préparée. Nous avons donc ajouté la fonction PHP permettant d’effectuer les requêtes préparées
comme illustré dans l’image ci-dessous.
71
Après avoir utilisé la fonction prépare nous avons de nouveau effectué le scan et constaté que
l’outil de scan OWASP ne présentait plus la vulnérabilité SQLi rencontré.
Nous pouvons constater dans l’image ci-dessus qu’après utilisation des requêtes préparées, le
scan de présente aucune vulnérabilité d’injection SQL.
2- L’outil Sqlmap
Afin d’effectué une injection SQL de manière automatisé, nous avons opté pour l’outil Sqlmap.
La librairie python est un outil efficace pour les attaques d’injection SQL, elle dispose de plusieurs
expressions selon la base de données à injecté, le but étant de remonter au listage complet des bases
de données. S’agissant d’une librairie python, il nous a donc fallu installer python dans la machine
attaquante. Nous avons ainsi installé une version Compatible (version 2.6, 2.7 et 3.x) a Sqlmap, la
version installée est Python 3.7.8.
Ci-dessous l’instruction utilisé par ans Sqlmap pour ressortir la base de données
sqlmap -u "http://192.168.1.19/site/index.php" --data

"mail=jkljklj&password=kjlkjlkj&send=Connexion" -p "mail,password" --method POST --dbs
72
Cette instruction permet d’envoyer une requête avec la méthode POST. Trois paramètres de
requête son envoyé au cours de cette instruction, il s’agit de mail, password et connexion. En
effet ces paramètres sont attendus par le formulaire afin de procéder à une authentification des
utilisateurs. L’instruction « --data » est la syntaxe qui précède l’ajout des données envoyé et « -
p » pour l’ajout des paramètres a injecté tout à la fin de la requête se trouve la synthaxe « --dbs »
elle permet de lister les bases de données.
Cette instruction Sqlmap effectue l’exploit de la vulnérabilité rencontré dans le formulaire
d’authentification.
Après l’exécution de l’instruction, Sqlmap nous pouvons constater que l’instruction sqlmap a
bien listé les bases de données. A présent que la base de données est connue faut alors lister les
tables qu’il contient. Pour cela la même instruction est exécutée en ajoutant le nom de la base de
données et les valeurs à lister (les tables).
Ci-dessus une instruction permettant de lister les tables de la base de données base.
73
Après l’exécution de l’instruction nous pouvons constater que 2 tables (user et commentaire) ont
bien été listées. Il reste alors une dernière étape, lister les utilisateurs
Ci-dessus l’instruction sqlmap permettant de lister des utilisateurs.

Après l’exécution de cette instruction, les utilisateurs de cette table ont bien été listé comme le
montre l’image ci-après.
74

Support Sécurité Des Applications WEB

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Support Sécurité Des Applications WEB

Transféré par

Droits d'auteur :

Formats disponibles

Sécurité des

Chapitre 1 : La sécurité du web.............................................................................................. 5

I.1.1 : Création et évolution du web

I.1.1.1 : Création du web

I.1.1.2 : Evolution du web

WEB 1.0 WEB 2.0 WEB 3.0 WEB 4.0

Tableau 1 : Comparaison de l’évolution du web

Figure 1 : Illustration requête et réponse HTTP

Figure 2 : Format d’une requête HTTP

I.1.2.1 : Architecture client-serveur ou à deux niveaux

Figure 4 : Architecture client-serveur

I.1.2.2 : Architecture à trois niveaux

Figure 5 : Architecture à trois niveaux

I.1.3 : Le protocole HTTPS et SSL/TLS

I.1.4 : Cyber sécurité

Figure 6 : Triade CIA

I.1.4.3 : Les menaces du cyberespace

Système Cause des dommages au système. Aucun dommage

Information Modifie l'information Ne modifie pas l'information

Triade CIA Affecte l'intégrité et la disponibilité Affecte la confidentialité

Tableau 2 : Comparaison entre attaque passif et attaque active

I.1.4.4.1 : Types de cyberattaques

Figure 7 : Illustration d’une attaque de type DOS

Figure 9 : Illustration d’une attaque de type Homme du milieu

Tableau 3 : Impact de cyberattaques dans la triade CIA

I.2.1 : Vulnérabilité des applications web et mobile

I.2.1.1 : Application web

I.2.1.1.1 : Vulnérabilité sur les applications web

I.2.1.1.1.2 : Authentification brisée

I.2.1.1.1.3 : Exposition des données sensibles

I.2.1.2 : Applications mobile

I.2.1.2.1 : Vulnérabilités des applications mobiles

I.2.1.2.1.1 : Exploit Payload

I.2.1.2.1.2 : Stockage des données non sécurisé

I.2.2 : Sécurité et protection des données personnelles des applications web

I.2.2.1.1 : Le droit des consommateurs

I.2.2.1.1.1 : Droit à l’information [17]

I.2.2.1.1.2 : Droit d’accès [17]

I.2.2.1.1.3 : Droit d’opposition

I.2.2.1.1.4 : Droit de rectification et suppression [17]

I.2.2.1.2 : Niveau de contrôle

I.2.2.2.1 : Les principes de l’OWASP

I.3.1 : Architecture de travail

I.3.1.1 : Environnement de travail

I.3.1.1.1 : Critère de choix

I.3.1.1.2 : Serveur d’hébergement

I.3.1.1.3 : Hôtes clients

I.3.1.1.4 : Application web

I.3.1.1.5 : Application mobile

I.3.1.1.6 : Outils de travaux

I.3.1.1.6.1 : Outils de test de vulnérabilités

I.4.1 : Exploit des vulnérabilités

I.4.1.1 : Application web

a. Description du cas pratique

Figure 10 : Scan des vulnérabilités SQLi au sein de l’application

Figure 11 : Cas pratique attaque SQLi

I.4.1.1.1.2 : Injection de code

a. Description du cas pratique

Figure 13 : Scenario du cas pratique injection du code

Figure 14 : Cas d’une attaque par injection de code

Figure 15 : Publication de commentaire par l’attaquant

Figure 17 : Vue utilisateur avant injection de code

I.4.1.1.2 : Exposition des données sensible

a. Description du cas pratique