Securisation des web services soap contre les attaques par injection

Mémoire de fin d’études
Pour l’obtention du diplôme d’Ingénieur d’Etat en Informatique
Option : Systèmes Informatiques (SIQ)
Thème
Sécurisation des Web Services SOAP contre les attaques
par injection par la méthode Khi-2 (χ²)
Réalisé par : Proposé et encadré par :
- Mr. SMAHI Zakaria
- Mr. AMROUCHE Hakim
Soutenu le : 16/09/2014
Devant le Jury composé de :
 Mr. CHALLAL.Y (Président)
 Mr. KHELOUAT.B (Assesseur1)
 Mr. DELLYS. H (Assesseur2)
 Mr. AMROUCHE. H (Assesseur3)
Promotion: 2013 - 2014

Dédicaces
À ceux qui ont sacrifié une partie de leur vie pour me voir grandir et
réussir, ceux qui m’ont toujours soutenu et encouragé, A vous ma chère
maman et mon chère papa, que dieu vous garde.
À la mémoire de mes grands-parents, et à ma grande mère et mon
grand père, que dieu les garde.
À mes deux adorables frères, Abdeldjalil et Salaheddine.
À mon PC « El-Nino » ;)
À mes amis d’enfance Ayoub, Saddam, Nadir et les autres.
À mes amis les plus proches Nasro, Lyes, Islem, Aziz, Warda et Selma.
À mes amis les « Others » Assem, islem mennouchi et Abdelhadi.
À mes amis de la cité BOURAOUI Amar El-Hachemi, Krimo, Hamza,
Tarek et les autres.
À mes amis du club scientifique CSE avec qui j’ai passé les moments
les plus heureux de mon cursus à l’ESI, chacun par son nom.
À mes enseignants du primaire, jusqu’à l’université.
À tous ceux que ce papier n’a pas pu contenir.
Zakaria
i

Remerciements
Au terme de ce travail je tiens tout d’abord à remercier Allah le tout
puissant de m’avoir donné la foi, la volonté et la persévérance pour
l’aboutissement de ce modeste travail.
Je présente mes sincères remerciements à mon encadreur Mr AM-ROUCHE
Hakim qui m’a soutenu et encadré durant toutes les étapes
de ce projet de fin d’étude, je le remercie infiniment pour sa disponi-bilité,
sa patience, sa rigueur scientifique, et ses remarques et conseils
pertinents.
Je remercie aussi, l’ensemble des enseignants Mr. GUERROUT, Mr.
ARIES et Mr. BENCHERIF de l’ESI et Mr. BENDJIMA et Mr. BE-NAHMED
de l’université de Bechar et Mr. BOUTEFARA de l’université
de Jijel pour leur aide, leurs conseils et leurs remarques.
Je remercie les membres de la grande communauté de l’open source
et la sécurité informatique Mr. Djamil SLIMANI (aka Chevrosky), Mr.
Islem MENNOUCHI et Mr. Assem CHELLI pour leurs aides techniques
et documentaires.
Je tiens à remercier également l’ensemble des ingénieurs et doctor-ant
de l’ESI : Mr.DAIFALLAH, Melle. BOUHAFS, Mr. HAMIDI, Mr.
BENMAMMERI et Mr. DJEBLI pour leurs feedbacks.
Je remercie les membres de jury pour avoir accepté de participer à
évaluer ce projet.
Enfin, mes sincères remerciements à tous ceux qui, de près ou de loin,
ont contribué par leurs conseils et leurs encouragements à l’édification
de ce mémoire.
iii

Résumé
Les Web Services sont des applications basées sur XML qui fournissent une
infrastructure pour décrire (WSDL), découvrir (UDDI) et invoquer (SOAP) des
services. Malheureusement, une plateforme basée sur les web services est confrontée
à un certains nombre d’attaques dues à l’utilisation du XML comme format pour
les messages de communication SOAP.
Ces attaques sont généralement de type injection (d’où l’appellation attaques
par injection) et reposent sur le problème qu’il n’existe aucune séparation stricte
entre les instructions d’un programme et les données qu’un utilisateur y saisit. La
famille d’attaques par injection regroupe les injections SQL, les injections sur
les fichiers XML (injections XML, injections XPath et injections XQuery)
et les injections de commandes du système.
Pour fournir un mécanisme de sécurité plus efficace pour les plateformes basées
sur les web services, les pare-feu XML ont été récemment introduits comme une
extension pour les pare-feux conventionnels. Dans ce contexte nous allons concevoir
et réaliser un pare-feu XML, qui peut être utilisé pour sécuriser les web services
contre les attaques par injection. Notre firewall reçoit en entrée un message SOAP,
qui lui extrait ses différents n-grammes et les compare avec un model dejà créé
contenant des bons messages du web service (un vecteur moyen) en utilisant un
algorithme de calcul de similarité entre chaînes de caractères qui est la distance
Khi-2 (²) ; cette distance permet de décider si le message est bon ou malveillant.
Enfin, pour montrer l’efficacité de notre pare-feu, nous l’avons testé sur une
plateforme à base d’un web service permettant aux clients de s’authentifier et de
s’inscrire et ce pour pouvoir tester les différents types d’injections. Suite à une série
de tests ; nous montrerons comment une injection peut être détéctée efficacement
par notre pare-feu.
Mots clés : Web services, sécurité, SOAP, attaques à base XML , attaques par
injection, n-gramme, Khi-2.
v

Abstract
Web Services are XML-based applications that provide infrastructure for de-scribing
(WSDL), discovering (UDDI) and invoking (SOAP) services. Unfortu-nately,
web services based plateforms are faced to a number of attacks caused by
the use of XML as a the format of SOAP communication messages.
These attacks are usually injection-type (injection attacks), and they are based
on the problem that there is no strict separation between program instructions and
user inputs data. The injection attacks family includes SQL injections, XML
files injections (XML injections, XPath injections and XQuery injections)
and OS commands injections.
To provide more effective security mechanism for web services and their plat-forms,
XML firewalls have been recently introduced as an extension to conven-tional
firewalls. In this context we will design and implement an XML firewall,
which can be used to secure web services against injection attacks.
Our firewall receives a SOAP message, and extracts its different n-grams and
compares them with a previously created model from web service good messages
(a mean vector) using an algorithm for calculation of similarity between strings
which is the Khi-squared (²) distance; this distance allows to decide whether
the message is good or malicious.
Finally, to show the effectiveness of our firewall, we tested it on a web service
based plateform that allows clients to authenticate and subscribe, so we can test
different types of injections. Following a series of performed tests ; we show how
an injection attack can be detected effectively by our firewall.
Keywords: Web services, Security, SOAP, XML based-attacks, injection attacks,
n-gram, Khi-2.
vii

Table des matières
Dédicaces i
Remerciements iii
Résumé v
Abstract vii
Table des matières ix
Table des figures xv
Liste des tableaux xvii
Liste des algorithmes xix
Liste des abréviations xxi
Introduction Générale 1
Étude bibliographique 5
1 Les web services SOAP 7
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Définitions des Web Services . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Définition du W3C . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Définition de IBM . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Caractéristiques des Web services . . . . . . . . . . . . . . . . . . . 9
ix

TABLE DES MATIÈRES
1.4 Technologies des Web Services . . . . . . . . . . . . . . . . . . . . . 9
1.4.1 XML (eXtensibleMarkupLanguage) . . . . . . . . . . . . . . 10
1.4.1.1 Définition du W3C . . . . . . . . . . . . . . . . . 10
1.4.1.2 Autre définition . . . . . . . . . . . . . . . . . . . . 10
1.4.2 WSDL (Web Services Description Language) . . . . . . . . . 10
1.4.3 SOAP(Simple Object Access Protocol) . . . . . . . . . . . . 11
1.4.3.1 Messages SOAP du Coté Client . . . . . . . . . . . 12
1.4.3.2 Messages SOAP du Coté Serveur . . . . . . . . . . 12
1.4.3.3 Caratéristiques du protocole SOAP . . . . . . . . . 13
1.4.3.4 Structure d’un message SOAP . . . . . . . . . . . . 13
1.4.4 UDDI (Universal Description Discovery and Integration) . . 15
1.5 Fonctionnement des web services . . . . . . . . . . . . . . . . . . . 15
1.6 Avantages d’utilisation des web services . . . . . . . . . . . . . . . . 17
1.7 Inconvénients d’utilisation des web services . . . . . . . . . . . . . . 17
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Attaques par injection sur les web services 19
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Les vulnérabilités dans les Web Services . . . . . . . . . . . . . . . 19
2.3 Attaques à base XML sur les web services . . . . . . . . . . . . . . 20
2.4 Les attaques de déni de services XDOS . . . . . . . . . . . . . . . . 21
2.5 Les attaques par injection . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.1 Injection XML . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.1.1 Injection XML simple . . . . . . . . . . . . . . . . 23
2.5.1.2 Injection de code XML Malformé . . . . . . . . . . 24
2.5.1.3 Injection de balises XML automatiques . . . . . . . 25
2.5.1.4 Injection XML Persistante . . . . . . . . . . . . . 26
2.5.1.5 Injection XML dans les messages SOAP . . . . . . 27
2.5.2 Injection XPath . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.2.1 Injection XPath Simple . . . . . . . . . . . . . . . 29
2.5.2.2 Dumping d’un Document XML . . . . . . . . . . . 31
2.5.2.3 Blind XPath Injection . . . . . . . . . . . . . . . . 31
2.5.2.4 Injection XQuery . . . . . . . . . . . . . . . . . . . 31
2.5.2.5 Injection XPath dans les messages SOAP . . . . . 32
2.5.3 Injection SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5.3.1 Manipulation du SQL . . . . . . . . . . . . . . . . 33
2.5.3.2 Injection de Code . . . . . . . . . . . . . . . . . . . 34
2.5.3.3 Injection des appels de fonctions . . . . . . . . . . 35
2.5.3.4 Blind SQL Injection . . . . . . . . . . . . . . . . . 36
2.5.3.5 Injection SQL dans les messages SOAP . . . . . . . 37
x

TABLE DES MATIÈRES
2.5.4 Injection de commandes OS . . . . . . . . . . . . . . . . . . 39
2.5.4.1 Injection de commandes OS dans les messages SOAP 40
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3 Approches de sécurisation des web services 43
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Firewall XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1 Pare-feu (Firewall en anglais) . . . . . . . . . . . . . . . . . 43
3.2.2 Pare-feu XML . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Les approches de sécurisation des web services . . . . . . . . . . . . 44
3.3.1 Les expressions régulières . . . . . . . . . . . . . . . . . . . . 44
3.3.2 Test du Khi-2 2 . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.3 Les approches à base de signatures . . . . . . . . . . . . . . 48
3.3.3.1 Avantages : . . . . . . . . . . . . . . . . . . . . . . 48
3.3.3.2 Inconvénients : . . . . . . . . . . . . . . . . . . . . 48
3.3.4 Les approches probabilistes . . . . . . . . . . . . . . . . . . 48
3.3.4.1 Comparaison et calcul de similarité entre chaînes
de caractères . . . . . . . . . . . . . . . . . . . . . 49
3.3.4.2 Quelques travaux sur la détection des attaques par
injection . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.5 Synthèse des travaux . . . . . . . . . . . . . . . . . . . . . . 54
3.3.5.1 Les Approches par signature et les approches prob-abilistes
. . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.5.2 Les approches probabilistes . . . . . . . . . . . . . 54
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Conception 57
4 Conception 59
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2 Les attaques détectées par notre pare-feu . . . . . . . . . . . . . . . 59
4.3 Architecture globale de notre firewall . . . . . . . . . . . . . . . . . 60
4.4 Le noyeau d’administration . . . . . . . . . . . . . . . . . . . . . . 60
4.4.1 Création/Mise-à-jour d’un profil web service . . . . . . . . . 61
4.4.1.1 Création d’un profil web service . . . . . . . . . . . 61
4.4.1.2 Modification de profil du web service . . . . . . . 67
4.5 Le noyeau de protection . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5.1 Interception du message SOAP . . . . . . . . . . . . . . . . 67
4.5.2 Extraction des n-grammes et de la table de fréquences . . . 68
4.5.3 Calcul de la distance Khi-2 . . . . . . . . . . . . . . . . . . . 68
xi

TABLE DES MATIÈRES
4.6 Fichier de configuration . . . . . . . . . . . . . . . . . . . . . . . . 71
4.7 Journal des évènements (log) . . . . . . . . . . . . . . . . . . . . . . 71
4.7.1 Visualisation et suppression du journal . . . . . . . . . . . . 73
4.8 Algorithme de protection . . . . . . . . . . . . . . . . . . . . . . . 75
4.9 Etude de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.9.1 Les méthodes de notre service web . . . . . . . . . . . . . . 76
4.9.2 Ajout du web service « Users » . . . . . . . . . . . . . . . . 76
4.9.2.1 Profil du web service . . . . . . . . . . . . . . . . . 76
4.9.2.2 Extraction des méthodes . . . . . . . . . . . . . . 76
4.9.2.3 Récupération du log . . . . . . . . . . . . . . . . . 76
4.9.2.4 Extraction des n-grammes et génération du vecteur
moyen . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.9.3 Scénarios d’attaques . . . . . . . . . . . . . . . . . . . . . . 77
4.9.3.1 Injection SQL . . . . . . . . . . . . . . . . . . . . . 77
4.9.3.2 Injection XPath . . . . . . . . . . . . . . . . . . . . 77
4.9.3.3 Injection XML . . . . . . . . . . . . . . . . . . . . 78
4.9.3.4 Injection de commandes OS . . . . . . . . . . . . . 79
4.9.3.5 Tester une attaque . . . . . . . . . . . . . . . . . . 79
4.9.4 Scénario un bon message . . . . . . . . . . . . . . . . . . . . 80
4.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Réalisation et Tests 81
5 Réalisation 83
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2 Système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.3 Environnement de développement . . . . . . . . . . . . . . . . . . . 84
5.3.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3.2 CGI-BIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.3.3 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3.4 SoapUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3.5 La bibliothèque NetfilterQueue . . . . . . . . . . . . . . . . 87
5.4 La Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.4.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . 87
5.4.2 Architecture technique du firewall . . . . . . . . . . . . . . . 89
5.4.3 Noyeau de Protection . . . . . . . . . . . . . . . . . . . . . . 89
5.4.3.1 Interception . . . . . . . . . . . . . . . . . . . . . . 90
5.4.3.2 Vérification . . . . . . . . . . . . . . . . . . . . . . 92
5.4.4 Noyeau d’Administration . . . . . . . . . . . . . . . . . . . . 92
5.4.4.1 Interface Login Panneau d’administration . . . . . 93
xii

TABLE DES MATIÈRES
5.4.4.2 Interface globale du Panneau d’administration . . . 93
5.4.4.3 Interface Profils des web services . . . . . . . . . . 94
5.4.4.4 Interface de Configuration . . . . . . . . . . . . . . 95
5.4.4.5 Interface Journal des évènements . . . . . . . . . . 96
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6 Tests et Résultats 99
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.2 L’ensemble de données utilisées pour la construction du vecteur
moyen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.2.1 Mesures d’évaluations utilisées . . . . . . . . . . . . . . . . . 100
6.2.1.1 Matrice de confusion . . . . . . . . . . . . . . . . . 100
6.2.1.2 Courbe de ROC . . . . . . . . . . . . . . . . . . . 101
6.3 La configuration de la plateforme des tests . . . . . . . . . . . . . . 102
6.4 Résultats des expérimentations . . . . . . . . . . . . . . . . . . . . 102
6.4.1 Méthode Login . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.4.1.1 Test 1 : 1000 messages . . . . . . . . . . . . . . . . 103
6.4.1.2 Test 2 : 5000 messages . . . . . . . . . . . . . . . . 105
6.4.1.3 Test 3 : 10000 messages . . . . . . . . . . . . . . . 107
6.4.2 Méthode Subscribe . . . . . . . . . . . . . . . . . . . . . . . 109
6.4.2.1 Test 1 : 1000 messages . . . . . . . . . . . . . . . . 109
6.4.2.2 Test 2 : 5000 messages . . . . . . . . . . . . . . . . 111
6.4.2.3 Test 3 : 10000 messages . . . . . . . . . . . . . . . 113
6.5 Discussion et Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.5.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.5.1.1 Taille du vecteur moyen . . . . . . . . . . . . . . . 115
6.5.1.2 Temps moyen d’execution . . . . . . . . . . . . . . 115
6.5.1.3 Taux de faux positifs et faux négatifs . . . . . . . . 115
6.5.1.4 Courbe de ROC . . . . . . . . . . . . . . . . . . . 116
6.5.2 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Conclusion générale et perspectives 119
Bibliographie 121
xiii

TABLE DES MATIÈRES
Annexes 127
A Le langage XPath 129
A.1 La forme d’une expression XPath . . . . . . . . . . . . . . . . . . . 131
B Algorithme de distance de Levenshtein 133
C La commande IPTables/La Bibliothèque NetfilterQueue 137
C.1 La commande IPTables . . . . . . . . . . . . . . . . . . . . . . . . 137
C.1.1 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . 137
C.2 La Bibliothèque NetfilterQueue . . . . . . . . . . . . . . . . . . . . 138
C.2.1 Principaux objets et méthodes de la bibliothèque . . . . . . 139
D Les vecteurs d’attaques utilisées dans ce projet 141
D.1 Injection SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
D.2 Injection de commandes OS . . . . . . . . . . . . . . . . . . . . . . 142
D.3 Injection XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
D.4 Injection XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
xiv

Table des figures
1.4.1 Structure générale d’un fichier WSDL . . . . . . . . . . . . . . . . 11
1.4.2 Description du fonctionnement du protocole SOAP . . . . . . . . . 12
1.4.3 Structure du message SOAP . . . . . . . . . . . . . . . . . . . . . 14
1.4.4 Exemple d’un message SOAP . . . . . . . . . . . . . . . . . . . . . 14
1.5.1 Les principaux acteurs dans un web service . . . . . . . . . . . . . 16
2.3.1 Attaques à base XML . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Les attaques par injection . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2 Injection XML dans un message SOAP . . . . . . . . . . . . . . . 28
2.5.3 Réponse du serveur au message SOAP envoyé . . . . . . . . . . . . 28
2.5.4 Injection XPath dans un message SOAP . . . . . . . . . . . . . . . 32
2.5.5 Réponse du service web : lister tous les (username,password) . . . 33
2.5.6 Injection SQL dans un message SOAP . . . . . . . . . . . . . . . . 38
2.5.7 Réponse SOAP à l’injection SQL . . . . . . . . . . . . . . . . . . . 38
2.5.8 Injection Commandes dans un message SOAP . . . . . . . . . . . 40
2.5.9 Injection Commandes dans un message SOAP . . . . . . . . . . . 41
3.2.1 Système basé sur les web services protégé par un pare-feu XML . 44
3.3.1 Table de Khi-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.1 Architecure globale pare-feu XML . . . . . . . . . . . . . . . . . . 60
4.4.1 Profils des web services . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.2 Ajouter un web service . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4.3 mécanisme d’ajout d’un web service . . . . . . . . . . . . . . . . . 64
4.4.4 Parser du fichier WSDL . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.5 Acquisiteur de requêtes autorisées . . . . . . . . . . . . . . . . . . 65
4.4.6 Extraction des n-grammes et de tableau de fréquences des n-grammes 66
4.4.7 Vecteur moyen des fréquences de n-grammes . . . . . . . . . . . . 66
4.4.8 Processus de modification d’un profil web service . . . . . . . . . . 67
4.5.1 Schéma de décision de malveillance ou pas du message . . . . . . . 69
4.6.1 Structure du fichier de configuration . . . . . . . . . . . . . . . . . 71
xv

TABLE DES FIGURES
4.7.1 Structure d’un fichier journal . . . . . . . . . . . . . . . . . . . . . 72
4.7.2 Structure d’un fichier journal d’attaques . . . . . . . . . . . . . . . 72
4.7.3 Visualisation et suppression du journal . . . . . . . . . . . . . . . 73
4.7.4 Exemple d’un fichier Journal (log) . . . . . . . . . . . . . . . . . . 74
5.2.1 Système Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2.2 Logo de la distribution ubuntu . . . . . . . . . . . . . . . . . . . . 84
5.3.1 Langage Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.3.2 Principe de fonctionnement du CGI . . . . . . . . . . . . . . . . . 85
5.3.3 Twitter Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3.4 SoapUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.4.1 Diagramme de classes de la solution proposée . . . . . . . . . . . . 88
5.4.2 Architecture de notre firewall . . . . . . . . . . . . . . . . . . . . . 89
5.4.3 Injection SQL envoyée via l’outil SoapUI . . . . . . . . . . . . . . 90
5.4.4 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . 93
5.4.5 Interface globale du Panneau d’administration . . . . . . . . . . . 94
5.4.6 Interface des Profils des Web Services . . . . . . . . . . . . . . . . 95
5.4.7 Interface configuration du firewall . . . . . . . . . . . . . . . . . . 96
5.4.8 Journal des attaques détectées . . . . . . . . . . . . . . . . . . . . 97
6.3.1 Configuration du réseau LAN utilisée pour les tests . . . . . . . . 102
6.4.1 Graphe de variations de FP et FN cas 1000 messages . . . . . . . 104
6.4.2 Courbe de ROC pour la méthode login cas 1000 messages . . . . . 104
6.4.4 Courbe de ROC pour la méthode login cas 5000 messages . . . . . 106
6.4.6 Courbe de ROC pour la méthode login cas 10000 messages . . . . 108
6.4.8 Courbe de ROC pour la méthode subscribe cas 1000 messages . . 110
A.1 Le modèle XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
xvi

Liste des tableaux
2.1 Résultat d’analyse du fichier XML . . . . . . . . . . . . . . . . . . 27
2.2 Exemple d’injection de commande . . . . . . . . . . . . . . . . . . 40
3.1 Exemples expressions régulières . . . . . . . . . . . . . . . . . . . . 45
3.2 Signature de quelques attaques par inejction (cas injection SQL) . 48
3.3 1-grammes et bigrammes extraits de la chaîne par exemple . . . 51
4.1 Attaque Injection SQL . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2 Attaque Injection XPath . . . . . . . . . . . . . . . . . . . . . . . 78
4.3 Attaque Injection XML . . . . . . . . . . . . . . . . . . . . . . . . 78
4.4 Attaque Injection de commandes OS . . . . . . . . . . . . . . . . . 79
6.1 Les différentes tailles d’échantillons d’apprentissage utilisés . . . . 100
6.2 Exemple matrice de confusion . . . . . . . . . . . . . . . . . . . . 101
6.3 Taille et Temps Génération du Vecteur moyen cas 1000 messages . 103
6.4 Taux de F.Ps et F.Ns, T.M de détection cas 1000 messages . . . . 103
6.5 AUC méthode login cas 1000 messages . . . . . . . . . . . . . . . . 103
6.7 Taux de F.Ps et F.Ns cas 5000 messages . . . . . . . . . . . . . . . 105
6.8 AUC méthode login cas 5000 messages . . . . . . . . . . . . . . . . 105
6.9 Taille et Temps Génération du Vecteur moyen cas 10000 messages 107
6.10 Taux de F.Ps et F.Ns cas 10000 messages . . . . . . . . . . . . . . 107
6.11 AUC méthode login cas 10000 messages . . . . . . . . . . . . . . . 107
6.14 AUC méthode subscribe cas 1000 messages . . . . . . . . . . . . . 109
6.17 AUC méthode subscribe cas 5000 messages . . . . . . . . . . . . . 111
6.18 Taille et Temps Génération du Vecteur moyen cas 10000 messages 113
6.19 Taux de F.Ps et F.Ns cas 10000 messages . . . . . . . . . . . . . . 113
xvii

LISTE DES TABLEAUX
6.20 AUC méthode subscribe cas 10000 messages . . . . . . . . . . . . 113
D.1 Injections SQL les plus usuelles cas MySQL . . . . . . . . . . . . . 141
D.2 Injections de commandes OS cas Linux . . . . . . . . . . . . . . . 142
D.3 Injections XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
D.4 Injections XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
xviii

Liste des algorithmes
2.1 Script Perl vulnérable à l’injection XPath . . . . . . . . . . . . . . . 30
2.2 Code C vulnérable à l’injection de commandes . . . . . . . . . . . . 39
3.1 Distance de Khi-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2 Algorithme de LCS . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3 Formule de similarité de cosinus . . . . . . . . . . . . . . . . . . . . 50
3.4 Formule de Coefficient de Dice . . . . . . . . . . . . . . . . . . . . . 51
4.1 Distance de Khi-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2 Distance 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.3 Algorithme de protection . . . . . . . . . . . . . . . . . . . . . . . . 75
5.1 Code D’interception de messages SOAP . . . . . . . . . . . . . . . . 91
5.2 Code De vérification du message SOAP . . . . . . . . . . . . . . . . 92
B.1 Algorithme Distance de Levenshtein . . . . . . . . . . . . . . . . . . 134
C.1 Exemple d’utilisation de la bibliothèque NetfilterQueue . . . . . . . 139
xix

Liste des abréviations
API Application Programming Interface
AUC Area Under Curve
DNS Domain Name System
FW FireWall
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol over SSL
OASIS Organization for the Advancement of Structural
Information Standards
OS Operating System
OWASP Open Web Applications Security Project
ROC Receiver Operating Characteristic
SOAP Simple Object Access Protocol
SQL Structured Query Language
SSL Secure Socket Layer
SVM Support Vector Machine
UDDI Universal Description, Discovery and Integration
URI Uniform Resource Identifier
URL Uniform Resource Locator
XDOS XML Denial Of Service
XML eXtensible Markup Language
XPath XML Path
XQuery XML Query
W3C World Wide Web Consortium
WEBAPPSEC WEB APPlication SECurity consortium
WS Web Service
WSDL Web Service Description Language
WWW World Wide Web
xxi

Introduction Générale
Cadre général et objectifs
Un web service est un composant applicatif mis à la disposition d’autres systèmes
et applications sur un réseau, il dispose de méthodes qui peuvent être invoquées
à distance via des protocoles réseau standards (HTTP). La communication entre
les Web Services s’effectue grâce à l’utilisation du langage XML, et du protocole
SOAP.
Les web services sont vulnérables à un certain nombre d’attaques dites « attaques
à base XML » ou «XML-based attacks », ces attaques sont en général des attaques
de type injection. Nous nous intéréssons à ce type, car il a une forte relation avec
les données entrées par un client du web service et qui ; en général ; ne sont pas
validées et controlées avant être envoyées au web service. Ce type d’attaques ; et
à l’instar de touts attaque à base XML; n’est pas malheureusement traité par les
pare-feu existants, suite à leur inhabilité à inspecter les contenus XML.
Afin de remédier à ce problème, les firewalls XML sont introduits comme solution
et extension aux firewalls existants. Ils se chargent d’analyser les contenus XML
contenu dans les messages SOAP et de les filtrer.
L’objectif principal de notre travail est d’identifier les différentes attaques par
injection contre les web services pouvant être exécutées à travers les messages
SOAP, et de proposer un mécanisme de sécurité qui permettra de détecter ces
attaques.
Contributions
Notre solution consiste à utiliser un algorithme de calcul de similarité entre
chaînes de caractères (distance de Khi2) comme un mécanisme pour détécter les
attaques de type injection. cet algorithme compare un message entrant avec un
ensemble déjà construit auparavant (un dataset) dans une phase dite phase d’ap-prentissage.
Le résultat de comparaison sera une décision si le message est bon ou
1

Introduction Générale
malveillant.
A travers cette solution nous visons à créer un scénario d’une plateforme basée
sur un web service, ainsi que des scénarios d’attaques sur cette plateforme ; pour
enfin créer un model firewall XML pour sécuriser les web services contre les at-taques
par injection ; qui sera un middleware invisible pour les deux cotés de la
communication en web service (le web service lui-même et ses clients).
Organisation du mémoire
Ce document est composé de trois parties :
Etude bibliographique :
Cette partie porte sur une étude d’un état de l’art relatif à notre problématique,
à savoir, les différentes attaques auxquelles est confrontée une plateforme basée
sur les web services. Elle comporte trois chapitres :
– Chapitre 1 intitulé « Les web services SOAP » : qui présente la technolo-gie
de web services : les définitions données, les standards utilisés et leurs
architectures.
– Chapitre 2 intitulé «Attaques par injection sur les web services » : dans
ce chapitre nous abordons les attaques sur les web services et nous détaillons
les attaques de type injection et leurs impacts sur les web services.
– Chapitre 3 intitulé « Approches de sécurisation des web services » : nous
présentons ici les différents travaux effectués dans le domaine de sécurisation
des web services, nous essayons par la fin de les synthétiser et montrer leurs
points forts et leurs insuffisances.
Conception :
Cette partie contient un seul chapitre :
– Chapitre 4 intitulé « Conception » : qui portera sur l’étude conceptuelle et
la description de notre solution développée, ainsi que les différents modules de
son architecture, enfin nous présenterons une étude d’un cas réel sur laquelle
nous montrons le fonctionnement de notre solution et ce à travers des scénarios
de différents types d’attaques par injection.
Réalisation et tests :
Cette partie est consacrée aux détails techniques de notre solution et ses perfor-mances.
Elle comporte deux chapitres :
2

– Chapitre 5 intitulé « Réalisation » : on détaillera ici la mise en oeuvre de la
solution proposée dans la deuxième partie, en présentant les outils utilisés et
l’implémentation du firewall XML.
– Chapitre 6 intitulé « Tests et Résultats » : dans ce chapitre nous effectuons
une série de tests afin de montrer l’éfficacité de notre firewall, en l’éxecutant
dans un environnement réel contenant une plateforme à base de web service.
A travers une série de scénarios d’attaques et de non-attaques nous testons les
performances de cette solution, les résultats ainsi obtenus seront intérprété et
analysé et synthétisé à la fin pour en sortir avec une meilleure configuration
de ce pare-feu.
En fin, nous allons conclure ce travail par une conclusion générale, et les perspec-tives
envisagées et les possibilités d’extension de notre solution, et les éventuelles
améliorations.
3

Étude bibliographique
« Once you stop learning, you
start dying »
(Albert EINSTEIN)

Chapitre 1
Les web services SOAP
1.1 Introduction
Les Web services sont devenus de plus en plus populaires, non seulement dans
les réseaux intranet, mais aussi dans les communications inter-entreprises ; et ce
grâce à la manière dont ils définissent et traitent les données et les faire agir avec
d’autres applications.
Les web services sont des applications à base XML, mis à la disposition de
d’autres applications et systèmes sur un réseau. Ils sont des compléments aux
programmes et applications existantes développées à l’aide des langages tel que
C++, Java, Python . . . etc., qui assurent les communications des programmes entre
eux.
Alors c’est quoi un web service ? C’est quoi XML? Et comment les web services
communiquent avec les autres applications ?
1.2 Définitions des Web Services
Il existe plusieurs définitions des web services, cependant elles convergent toutes
vers le fait que les web services sont des programmes accessibles à distance, qui
peuvent être déployés sur n’importe quel plateforme, et peuvent être utilisés par
d’autres programmes y compris d’autres web services. Il s’agit d’une forme de tech-nologie
intergicielle (Middleware) qui s’appuie sur des standards, principalement
proposés par le World Wide Web Consortium (W3C), comme XML,WSDL.
1.2.1 Définition du W3C
« A Web service is a software system designed to support interop-erable
machine-to-machine interaction over a network. It has an in-
7

Chapitre 1 Les web services SOAP
terface described in a machine-processable format (specifically WSDL).
Other systems interact with the Web service in a manner prescribed by
its description using SOAP messages, typically conveyed using HTTP
with an XML serialization in conjunction with other Web-related stan-dards.
» [Booth, 2004].
Traduction :
Un Web service est un système logiciel conçu pour soutenir l’interaction in-teropérable
machine-à-machine.Il dispose d’une interface décrite dans un format
lisible en machine (en particulier WSDL).
Les systèmes interagissent avec un service web à travers la manière prescrite
par sa description en utilisant les messages SOAP, typiquement transmis via le
protocole HTTP avec une sérialisation XML en conjonction avec d’autres normes
liées au Web.
1.2.2 Définition de IBM
« A Web service is an interface that describes a collection of opera-tions
that are network accessibe through standardized XML messaging.
A Web service is described using a standard, formal XML notion, called
its service descrption. It covers all the details necessary to interact
with the service, including message formats (that detail the operations),
transport protocols and location. The interface hides the implementa-tion
details of the service, allowing it to be used independently of the
hardware or software platform on which it is implemented and also in-dependently
of the programming language in which it is written. This
allows and encourages Web Services-based applications to be loosely
coupled, Component-oriented, cross-tcehnology implementations. Web
Services fulfill a specific task or a set of tasks. They can be used alone
or with other Web Services to carry out a complex aggregation or a
business transaction »[Kreger, 2001].
Traduction :
UnWeb Service est une interface qui décrit une collection d’opérations accessibes
via réseau à travers une messagerie XML standardisée. Un Web Service est décrit
en utilisant une notion de la norme XML, formelle, appelée sa descrption de service.
Elle (i.e la description du service) couvre tous les détails nécessaires pour interagir
avec le service, y compris les formats de messages (qui détaillent les opérations),
les protocoles de transport et l’emplacement.
8

1.3 Caractéristiques des Web services
L’interface masque les détails du service, ce qui permet de l’utiliser indépendam-ment
de la plate-forme matérielle (hardware) ou logicielle (software) à laquelle il
est mis en oeuvre et également indépendamment du langage de programmation
dans lequel il est écrit ; ceci qui assure et encourage un faible couplement et des
implémentations inter-technologies.
Les web services remplissent une tâche spécifique ou une série de tâches. Ils
peuvent être utilisés seuls ou avec d’autres web services pour réaliser une agrégation
complexe ou une transaction commerciale.
Ces deux définitions mettent en valeur les points suivants :
– L’interface du web service, interprétable par d’autres machines, permettant
aux applications d’accéder d’une manière automatique au service.
– L’utilisation des protocoles et langages indépendants des plateformes de dé-ploiement
qui renforcent l’interopérabilité entre services.
– L’utilisation des normes actuelles du Web permettant la réalisation des inter-actions
faiblement couplées et favorisant aussi l’interopérabilité.
1.3 Caractéristiques des Web services
Les web services sont en générales caractérisées par ces caractéristiques [Hugo, 2002] :
– Interactions entre machines
– Accords dynamiques
– Pas de connaissance a priori des services avec lesquelles le programme est en
interaction.
– L’accessibilité via le réseau.
– Son interface, permet aux applications d’accéder d’une manière automatique
au service
1.4 Technologies des Web Services
Afin de rendre les web services interopérables, l’organisation WS-I a proposé de
définir les web services en introduisant des profils.L’un de ces profils est le WS-I
Basic qui est composé de quatre parties[Rabhi, 2012] :
– La description de l’interface du service web grâce au langage WSDL (Web
Services Description Language).
– La sérialisation des messages transmis via le protocole SOAP(Simple Object
Access Protocol).
– L’indexation des servicesWeb dans des registres UDDI (Universal Description,
DiscoveryIntegration).
9

– La sécurité des services Web, obtenue essentiellement grâce à des protocoles
d’authentification et de cryptage XML.
1.4.1 XML (eXtensibleMarkupLanguage)
1.4.1.1 Définition du W3C
« Extensible Markup Language (XML) is a simple, very flexible text
format derived from SGML (ISO 8879). Originally designed to meet
the challenges of large-scale electronic publishing, XML is also playing
an increasingly important role in the exchange of a wide variety of data
on the Web and elsewhere. » [Bray, 1998].
1.4.1.1.1 Traduction
Extensible Markup Language (XML) est un format texte simple, très souple
dérivé de SGML (ISO 8879). Initialement conçu pour répondre aux défis de l’édi-tion
électronique à grand échelle, XML joue également un rôle de plus en plus
important dans l’échange d’une grande variété de données sur le Web et ailleurs.
1.4.1.2 Autre définition
Les Web Services se fondent sur XML qui est un langage de bannières, permet-tant
d’écrire des contenus organisés de manière hiérarchique. Le principal intérêt
d’XML est que ce format de document permet de transmettre l’information, et
les métadonnées qui indiquent sa signification, et la structure de l’information à
échanger[Rabhi, 2012].
Ces deux définitions mettent en valeur les points suivants :
– XML est un langage de balisage dérivé du langage SGML.
– Sa syntaxe est extensible ce qui permet de définir des espaces de noms (names-paces)
; i.e des langages spécifiques avec leurs vocabulaires et grammaires.
– L’objectif initial du XML est de faciliter l’échange automatisé de contenus
complexes entre systèmes d’informations hétérogènes (interopérabilité) ; d’où
son utilisation dans les web services.
1.4.2 WSDL (Web Services Description Language)
WSDL fournit une description de l’interface des Web Services. Il permet de
décrire l’ensemble des opérations fournies par un Web Service. Les messages émis
sont consommés par ces opérations, sans se préoccuper de l’implantation de celles-ci[
Hassen, 2009].
10

le fichier WSDL est un fichier XML qui peut être divisé en deux parties, la
première partie « l’entête » qui est composée des définitions abstraites, et la seconde
partie qui se compose de descriptions concrètes [Chollet, 2009].
– Description abstraite : concerne l’interface du service, les opérations sup-portées,
ainsi les paramètres et les types de données.
– Description concrète : concerne l’accès au service (port, protocole spéci-fique
d’accès, etc.).
La figure suivante (figure 1.4.1) montre bien la structure d’un fichier WSDL :
Figure 1.4.1 : Structure générale d’un fichier WSDL
1.4.3 SOAP(Simple Object Access Protocol)
SOAP est construit comme étant un nouveau protocole pour les environnements
décentralisés et distribués. Il utilise le réseau internet et XML pour échanger les
informations entre les noeuds [Suda, 2003].
11

SOAP, développé par IBM et Microsoft, est une recommandation W3C qui le
définit comme étant un protocole de communication basé sur XML pour perme-ttre
aux applications de s’échanger des informations via HTTP. Il permet ainsi
l’accès aux services web et l’interopérabilité des applications à travers le web. Il
est portable et donc indépendant de tous système d’exploitation et du type d’or-dinateur.
Le message SOAP est échangé entre un client et un serveur.
1.4.3.1 Messages SOAP du Coté Client
Le client envoie des messages au serveur correspondant à des requetés SOAP-XML
enveloppés dans des requêtes HTTP. De même, les réponses du serveur sont
des réponses HTTP qui renferment des réponses SOAP-XML. Dans le processus
client, l’appel de service est converti en une requête SOAP qui est ensuite enveloppé
dans une HTTP.
1.4.3.2 Messages SOAP du Coté Serveur
C’est légèrement plus compliqué car il requiert un processus ‘listener’ correspon-dant
au processus serveur en attente de connexion cliente. Le ‘listener’ est souvent
implémenté à travers d’un servlet qui s’exécute et qui a comme tache l’extraction
du message XML-SOPA à partir de la requête HTTP, de le dé-sérialiser c’est à
dire de séparer le nom de la méthode et les paramètres fournis puis invoquer la
méthode du service en conséquence. Le résultat de la méthode est alors sérialisé,
encodé HTTP et renvoyé au demandeur.
La figure suivante (figure 1.4.2) montre le fonctionnement du protocole SOAP
[Michel, 2002].
Figure 1.4.2 : Description du fonctionnement du protocole SOAP
12

1.4.3.3 Caratéristiques du protocole SOAP
– SOAP repose sur le langage XML.
– C’est un protocole peu restrictif, qui laisse aux composants desWeb Services le
soin de définir comment ils formateront le contenu du message [Dominique, 2008].
– Le transport et le système d’opération sont indépendants, car il est construit
en utilisant le protocole http et le langage de balisage XML [Suda, 2003].
– SOAP est fondamentalement un modèle de communication One-way, qui as-sure
qu’un message cohérent est transféré de l’expéditeur au destinataire, y
compris potentiellement les noeuds intermédiaires, qui peuvent traiter une
partie, ou ajouter à l’unité de message.
1.4.3.4 Structure d’un message SOAP
SOAP définit un format pour l’envoi des messages. Les messages SOAP sont
structuré en un document XML et comporte 2 éléments obligatoires : Une en-veloppe
et un corps (une entête facultative).La structure d’un message SOAP est
la suivante [Rossberg, 2006] :
– SOAP Enveloppe : C’est l’élément racine du message SOAP, elle définit le
contexte du message, son destinataire et son contenu. Elle contient un élément
d’en-tête optionnel.
– SOAP Header : C’est un bloc optionnel qui contient des informations d’en-têtes
sur le message. SOAP Header donne des directives au destinataire, con-cernant
le traitement du message. Ces directives concernent généralement la
sécurité : déclaration d’assertions, déclaration de signature, déclaration de
chiffrement, information sur une clé cryptographique,. . . etc.
– SOAP Body : C’est l’élément contenant les données utiles à transmettre.
Chacune de ses entrées contient des informations applicatives que le desti-nataire
doit traiter. L’élément Body est également utilisé pour transmettre
un message d’erreur dans le cas où une erreur survient. Il doit absolument
être présent d’une manière unique dans chaque message, et être contenu dans
le bloc SOAP enveloppe.
– Des attachements optionnels, tel que le SOAP Fault : Ce bloc est la seule
structure définie par SOAP dans le bloc Body, et sa présence n’est pas obli-gatoire.
Il sert à reporter des erreurs lors du traitement du message, ou lors
de son transport. Il ne peut apparaître qu’une seul fois par message.
La figure suivante (figure 1.4.3) montre bien la structure du message SOAP [Rossberg, 2006] :
13

Figure 1.4.3 : Structure du message SOAP
Voici un exemple d’un message SOAP pour une méthode de login ou les paramètres
sont le nom d’utilsateur et le mot de passe.
Figure 1.4.4 : Exemple d’un message SOAP
14

1.5 Fonctionnement des web services
1.4.4 UDDI (Universal Description Discovery and Integration)
« UDDI est la spécification régissant l’information relative à la publi-cation,
la découverte et l’utilisation d’un Web Service. En d’autre terme
UDDI détermine comment nous devons présenter l’entreprise et le Web
Service quelle offre à la communauté afin de permettre à cette dernière
d’y avoir accès. D’où le concept UDDI est vu en deux aspects : l’en-registrement
de l’information, et la découverte de cette information.
En effet, UDDI est un annuaire (registre) web sous un format XML. »
[Michel, 2002].
UDDI est une spécification d’annuaire qui propose d’enregistrer et de rechercher
des fichiers de description desWeb Services, correspondant aux attentes d’un client
[Chollet, 2009].
Il se comporte comme le DNS, à la différence qu’il résout le nom de service au
lieu des noms de domaines. Il n’est pas affilié avec le W3C, mais il a été soumis
à l’organisme de normalisation OASIS pour l’examiner. Comme le registre UDDI
est un Web Service, il gagne tous les avantages du langage XML et du protocole
SOAP [Suda, 2003].
Il est comme un annuaire électronique qui fournit une classification, et un cata-logue
des Web Services, les fournisseurs de services peuvent enregistrer leurs ser-vices
dans le serveur UDDI, l’utilisateur d’un Web Service peut rechercher un Web
Service spécifique en utilisant le registre UDDI [Radhamani, 2007].
UDDI est un standard spécifié par OASIS (Organization for the Advancement of
Structured Information Standards), pour la publication et la découverte des
web services. UDDI est un annuaire de services basé sur XML qui permet
d’automatiser les communications entre les fournisseurs du service web et
clients.
1.5 Fonctionnement des web services
Les web services sont des technologies qui permettent à des applications de dia-loguer
via internet, par l’échange des messages fondés sur des standards web. Trois
acteurs principaux figurent dans l’utilisation d’un service web [Kreger, 2001] :
– Le fournisseur du service (provider).
– Le demandeur de service (requester).
– L’annuaire de service permettant la découverte du service web et son four-nisseur
(registry).
Le schéma suivant (figure 1.5.1) résume l’utilisation d’un service web et ses acteurs
principaux :
15

Figure 1.5.1 : Les principaux acteurs dans un web service
16

1.6 Avantages d’utilisation des web services
1.6 Avantages d’utilisation des web services
Les web services sont, de nos jours, utilisés à grand échelle et ce grâce aux
avantages qu’elles offrent :[Alkamari, 2008]
– Les web services réduisent le temps de mise en marché des services offerts par
les diverses entreprises.
– Les web services utilisent des normes et protocoles ouverts (SOAP, XML,
HTTP).
– Les protocoles et les formats de données sont offerts, le plus possible, en
format texte pour que la compréhension du fonctionnement des échanges soit
plus intuitive.
– Grâce au protocole HTTP, les web services peuvent fonctionner malgré les
pare-feu sans pour autant nécessiter des changements sur les critères de fil-trage.
– Grâce aux web services, les coûts sont réduits par l’automatisation interne et
externe des processus commerciaux.
1.7 Inconvénients d’utilisation des web services
Malgré les avantages offerts par les web services, elles ont plusieurs inconvénients,
qui sont en premier lieu des problèmes de sécurité, tels que :
– Leurs vulnérabilités facilitant le contournement des mesures de sécurité.
– L’absence des mécanismes d’identification, d’authentification et de chiffrage
dans la technologie SOAP, la technologie principale des web services.
– Les problèmes de fiabilité : Il est difficile de s’assurer de la fiabilité d’un
service car on ne peut garantir, que ses fournisseurs ainsi que les personnes
qui l’invoquent travaillent d’une façon fiable.
– Les problèmes de disponibilité : Les web services peuvent bien satisfaire un
ou plusieurs besoins du client [Alkamari, 2008].
1.8 Conclusion
La technologie des web services, est l’une des technologies les plus connues et les
plus utilisées. Elle est basée sur le standard XML, permet de rendre disponibles
dans un annuaire UDDI des services dont les fonctionnalités sont décrites dans
des fichiers WSDL. Le protocole SOAP permet aux consommateurs d’interroger
l’annuaire et d’invoquer le service facilement à travers un réseau.
Dans le chapitre suivant nous allons voir en détail, les attaques sur les web
services ; en général ; et les attaques par injection en particulier.
17

Chapitre 2
Attaques par injection sur les web
services
2.1 Introduction
Une plateforme basée sur les web services est confrontée à plusieurs types d’at-taques
et menaces dus à des failles dans la communication (message SOAP) entre
les web services. Ces attaques, souvent appelées « XML-Based Attacks » (les at-taque
à base XML), exploitent les vulnérabilités de XML tel que : XPath injection,
XML-based denial of service (XDoS), XML injection,...etc.
Dans ce chapitre nous allons présenté, les attaques par injection en général, Il
s’agit bien des attaques XPath, XML, SQL et l’injection de commandes systèmes,
on verra par la suite chaque attaque dans les web services, pour celà nous avons
utilisé l’outil SOAPUI pour tester ses injections sur des web service réels.
2.2 Les vulnérabilités dans les Web Services
Les Web services sont devenus une partie importante du Web, grâce aux avan-tages
qu’elles offrent, tel que l’utilisation des protocoles standards comme XML,
SOAP et HTTP. Toutefois, ces caractéristiques les rendent vulnérables à de nom-breuses
menaces de sécurité.
En général, le processus d’attaque sur une application consiste à découvrir, tout
d’abord, ses faiblesses et par la suite essayer d’y pénétrer ;le processus reste le
même pour les web services.
Les pirates aujourd’hui découvrent de nouvelles techniques d’attaques, à des
niveaux de données XML/SOAP. Entre autres, un attaquant peut nuire à la
sécurité, et pénétrer dans les systèmes, en s’appuyant sur la structure des mes-
19

Chapitre 2 Attaques par injection sur les web services
sages SOAP pour développer un modèle d’attaque pour parvenir à ses objectifs
[Yaron, 2007].
Nous allons voir dans ce qui suit les principales vulnérabilités SOAP/XML.
2.3 Attaques à base XML sur les web services
Nous avons vu dans le paragraphe précédent que les web services sont devenus
de plus en plus vulnérable. Cette vulnérabilité est due en général à la manière
d’échange de données entre les web services par le protocole SOAP.
L’échange de données entre web services se fait par le biais du protocole SOAP
qui est un protocole de type requête/réponse, et un mécanisme d’échange de don-nées
XML à travers un protocole de communication http. Cependant SOAP ne
définit aucun mécanisme de sécurité, ce qui fait que les messages SOAP sont vul-nérables
à être capturés et modifiés par un attaquant. Un autre point de moins
contre SOAP; c’est que la plupart des problèmes ne concernent pas seulement le
protocole lui-même mais d’autres protocoles utilisés comme http et XML. Nous
allons voir quelques problèmes et attaques sur XML et SOAP; dites les attaques
basées sur XML « XML-based Attacks ».
Il existe de grandes familles des attaques sur XML, comme le montre la figure
suivante (figure 2.3.1) :
Figure 2.3.1 : Attaques à base XML
20

2.4 Les attaques de déni de services XDOS
2.4 Les attaques de déni de services XDOS
Une attaque de type « déni de service » en anglais « Denial Of Service» abrégée
« Dos » est un type d’attaque visant à rendre les services ou les ressources d’une
organisation indisponibles pendant un temps indéterminé. Cette menace concerne
en général le fournisseur de service. Il s’agit la plupart du temps d’attaques à
l’encontre des serveurs d’une entreprise, afin qu’ils ne puissent être utilisés et con-sultés.
Le principe de l’attaque DOS consiste à saturer le fournisseur de service, en lui
envoyant des messages XML non valides ; qui peuvent engendrer une récursivité
infinie en les analysant par le fournisseur [Wells, 2007].
Les attaques par déni de service sont un fléau pouvant toucher tout serveur
d’entreprise, ou tout particulier relié à internet. Le but d’une telle attaque n’est
pas de récupérer ou d’altérer des données, mais de nuire à la réputation de sociétés
ayant une présence sur internet, et éventuellement de nuire à leur fonctionnement
si leur activité repose sur un système d’information [CCM, 2014a].
Cette classe regroupe les attaques suivantes :
– Attaque oversize / récursive :Il s’agit d’une attaque d’épuisement des
ressources. Cette attaque vise à éliminer la disponibilité d’un service en épuisant
les ressources du système du service, comme la mémoire, les ressources de
traitement, ou la bande passante du réseau. Une façon «classique» pour ef-fectuer
une telle attaque est d’interroger un service en utilisant un message
SOAP de grande taille [Jensen, 2009].
– Attaque dite XML bombe : Une bombe XML est un message composé
et envoyé avec l’intention de la surcharge d’un analyseur XML (généralement
de serveur HTTP). Les Bombes XML exploitent le fait que XML permet de
définir des entités. Par exemple, définir l’entité ’e1’ être définie par 20 entités
’e2’, qui à son tour est définie de 20 entité ’e3’. Si nous continuons dans le
même schéma jusqu’à ’e8’, l’analyseur XML va analyser une occurrence de
’e1’ et 1 280 000 000 entités ’e8’ prenant 5 Gio de mémoire. Le but ultime de
cette attaque est de consommer les ressources de l’analyseur XML àfind de
causer un déni de service [SoapUI, 2011].
– Attaque par référence externe : Au lieu de définir des chaînes de remplace-ment
d’entité en tant que constantes, il est également possible de les définir
de sorte que leurs valeurs sont extraites des URI externes par ex. !ENTITY
stockprice SYSTEM http ://www.contoso.com/currentstockprice.ashx. L’idée
la plus simple pour cette attaques est d’envoyer le parser XML à une ressource
externe qui ne retourne jamais, l’envoyer par ex. à une boucle infinie [Bryan, 2009].
– Attaque par envoie massif de messages SOAP : Le but de cette attaque
est de surcharger le Web Service par l’envoi des messages SOAP répétitifs. Le
21

message SOAP lui-même est valide, mais le serveur XML ne peut pas traiter
tous ces messages envoyés en une période courte, et cela peut provoquer la
non réception des messages SOAP des non attaquants par le Web Service
[Radhamani, 2007] .
2.5 Les attaques par injection
Les attaques par injections représentent les attaques prédominantes contre les
web services aujourd’hui. Ce type d’attaque repose sur le problème qu’il n’existe
aucune séparation stricte entre les instructions d’un programme et les données
qu’y saisit un utilisateur [Lackey, ]. Lorsque les données passent sans être validées
correctement, un utilisateur malveillant peut injecter du code malicieux, dans le
but d’extraire ou de modifier des données confidentielles.
Pour réaliser une attaque par injection, il faut réussir à placer, dans des saisies
classiques, des données interprétées comme des instructions. Le succès de l’opéra-tion
repose sur trois éléments [Lackey, ] :
– Identifier la technologie sur laquelle repose l’application web. Les attaques par
injection dépendent beaucoup du langage de programmation ou du matériel
impliqué.
– Établir la liste de toutes les saisies utilisateur possibles. Dans certains cas,
elles seront évidentes.
– Trouver la saisie utilisateur vulnérable.
Cette classe d’attaques comprend les attaques suivantes ; les plus répandues ; :
– Les injections XML
– Les injections XPath
– Les inejctions SQL
– Les injections de commandes systèmes
On peut schématiser la taxonomie des attaques par inejction par la figure
suivante (figure 2.5.1) :
22

Figure 2.5.1 : Les attaques par injection
2.5.1 Injection XML
Les XML injections sont utilisés pour manipuler le contenu XML. Le but de
cette attaque est d’envoyer au serveur des données en rentrant par exemple, des
informations d’identification contenant des caractères spéciaux, qui pourrait ne
pas être prisent en charge par l’application.
Voici les différentes formes des injections XML :
2.5.1.1 Injection XML simple
Prenons le fichier XML suivant des utilisateurs pour une fonction d’authentifi-cation
(login).
Le fichier contient l’entrée suivante user avec nom d’utilisateur « username » :
’Alice’ et mot de passe « password » : ’secret’ :
23

Fichier XML des utilisateurs et leurs mots de passe
?xml version=1.0 encoding=ISO-8859-1 ?
users
user
usernameAlice/username
passwordSecret/password
/user
/users
Afin d’exploiter cette vulnérabilité, on fait entrer des données composées de
métadonnées comme ’’ ou ’’. La requête peut devenir alors :
Fichier XML des utilisateurs « vulnérable »
users
user
/user
/users
On a obtenu donc un code XML Malveillant. Le fait d’insérer ce caractère
’’ bloque les analyseurs des fichiers XML (XML Parser) d’analyser ce fichier
la prochaine fois en indiquant une erreur lors la lecture (un début d’une balise
ouvrante ou fermante).
Nota que la plupart des Parsers XML ont balaysé à ce probmème en encodant
les caractères spéciaux ’’ ,’’, néanmoins, il existe toujours des XML Stream
Reader qui sont toujours vulnérable à cette faille.
2.5.1.2 Injection de code XML Malformé
Ce type d’injection est une amélioration du type précédent, elle consiste à in-jecter
des balises XML mal formées.
Prenons le fichier XML suivant des utilisateurs pour une fonction d’authentifi-cation
(login).
Le fichier contient l’entrée suivante user avec nom d’utilisateur « username » :
’Alice’ et mot de passe « password » : ’secret’ :
24

users
user
/user
/users
Afin d’exploiter cette vulnérabilité, on va injecter les balises mal formées :
xmljoke/xml/joke
La requête peut devenir alors :
Fichier XML des utilisateurs « vulnérable »
users
user
usernameAlicexmljoke/xml/joke/username
/user
/users
On a obtenu donc un code XML Malveillant. Le fait d’insérer les balises mal
formées xmljoke/xml/joke bloque, comme dans le type vu précédem-ment
; les analyseurs des fichiers XML (XML Parser) d’analyser ce fichier la prochaine
fois en indiquant une erreur lors la lecture (error parsing xml).
2.5.1.3 Injection de balises XML automatiques
Il s’agit du fait de rajouter une information que l’on met soi-même dans la
requête en spécifiant par exemple manuellement son ID, alors qu’en temps normal
il est généré automatiquement [Stamos, 2005].
L’utilisateur fait entrer les données de la manière suivante :
Username : Charly/usernameID0/IDusername
Une fois insérée le fichier XML sera de la forme :
Injection de balises XML
users
user
usernameCharly/usernameID0/IDusernameAlice/username
/user
/users
25

Charly aura maintenant un ID de 0 qui pourrait par exemple représenter les
administrateurs. On arrivait donc à ajouter un utilisateur au groupe des adminis-trateurs,
qui devrait normalement être secrét.
2.5.1.4 Injection XML Persistante
C’est une simple attaque XML, la différence réside qu’elle est stockée sur le «
provider » et exécutée par le serveur lorsque la requête est servie [Renaud, 2010].
Soit le fichier XML suivant :
users
user
emailz_smahi@esi.dz/email
adresse Bechar /adresse
zip 08000 /zip
/user
/users
En utilisant la balised’inclusion « xi » pour inclure le fichier « /etc/passwd »des
mots de passe des utilisateurs. Le fichier sera alors :
users
user
passwordxi :include href=file :///etc/passwd parse=text/ /password
emailz_smahi@esi.dz/email
adresse Bechar /adresse
zip 08000 /zip
/user
/users
Après l’analyse (parsing) du fichier XML, on aura le résultat suivant (tableau
2.1) :
26

Balise Valeur retournée
username zsmahi
root :x :0 :0 :root :/root :/bin/bash
password daemon :x :1 :1 :daemon :/usr/sbin :/bin/sh
bin :x :2 :2 :bin :/bin :/bin/sh
email z_smahi@esi.dz
adresse Bechar
zip 08000
Table 2.1 : Résultat d’analyse du fichier XML
On a pu donc obtenir le contenu du fichier des mots de passe sous Linux
‘/etc/passwd’, maintenant avec une simple attaque de type force brute en util-isant
l’outil ’John The Ripper’ par exemple , on aura tous les mots passe des
utilisateurs du serveurs hébergeant ce fichier XML et le web service, y compris le
super-utilisateur ’root’.
2.5.1.5 Injection XML dans les messages SOAP
L’injection XML est présente dans les web services qui utilisent un fichier XML
pour sauvegarder les données, ceci est un exemple (figure 2.5.2) illustrant un exploit
via un message SOAP :
27

Figure 2.5.2 : Injection XML dans un message SOAP
A travers cet exemple ; nous avons essayé d’injecter un code XML mal formé
qui est : xmljoke/xml/joke. La réponse ainsi sera la suivante (figure
2.5.3) :
Figure 2.5.3 : Réponse du serveur au message SOAP envoyé
28

L’analysur a généré une erreur lors de l’analyse (parsing) due à la balise mal
formée injectée xmljoke/xml/joke.
2.5.2 Injection XPath
Les documents XML sont devenus de plus en plus compliqués et trop chargés,
cela a conduit à définir un langage d’interrogation des fichiers XML. Le langage
qui a été créé alors est XPath.
XPath est un langage de requêtes spécialisé, qui joue un rôle comparable à celui
de SQL dans les contextes des bases de données. Mais malgré sa simplicité il pose
aussi des problèmes d’injection (voir Annexe A).
Lorsqu’on choisit de stocker des données sensibles en XML plutôt que dans
une base de données SQL, les attaquants peuvent s’appuyer sur une injection de
XPath pour contourner une authentification, comme pour inscrire des données sur
le système distant [Lackey, ].
2.5.2.1 Injection XPath Simple
Le document XML suivant ‘users.xml’ renferme les numéros d’identifiants, noms
d’utilisateurs et mots de passe employés par un service web [OWASP, 2013b] :
Fichier XML d’authentification des utilisateurs
users
user
id1/id
usernameAdmin/username
password xpathr00lz /password
/user
user
id2/id
usernametestuser/username
passwordtest123/password
/user
/users
Un simple programme peut charger le document XML et recherche le numéro d’i-dentifiant
associé au nom d’utilisateur et au mot de passe proposés. En supposant
que ces valeurs soient respectivement admin et xpathr00lz , la requête XPath se
présenterait comme suit :
//users[username/text()=’admin’ and password/text()=’xpathr00lz’]/id/ text()
29

On remarquera que cette saisie d’utilisateur n’est pas échappée dans le code
source de sorte qu’un attaquant pourra y insérer toute donnée ou instruction XPath
souhaitée. En choisissant pour mot de passe ’ or ’1’=’1, la requête deviendrait
ainsi :
//users[username/text()=’admin’ ]/id/text() and password/text()=” or ’1’=’1’
Cette instruction renverra le numéro correspondant à l’identifiant admin et qui
en outre, soit dispose d’un mot de passe vide (cas de figure hautement improbable),
soit vérifie un égale un – ce qui est toujours vérifié. Par conséquent, l’injection de
’ or ’1’=’1 renvoie l’ID de l’administrateur sans que l’attaquant n’ait besoin d’en
connaître le mot de passe.
Signalons que XPath est un sous-ensemble d’un langage XML de requêtes plus
large, appelé XQuery. Comme XPath et SQL, ce dernier souffre de problèmes
d’injection comparables.
Voici un exemple d’un script perl vulnérable à cette attaque (Algoritme 2.1) :
Algorithme 2.1 Script Perl vulnérable à l’injection XPath
#!/usr/bin/perl
use XML : :XPath ;
use XML : :XPath : :XMLParser ;
my $login = $ARGV[0] ;
my $pass = $ARGV[1] ;
my $userfile = users.xml ;
my $expr = //user[username=’$login’ and password=’$pass’] ;
my $xp = XML : :XPath-new(filename = $userfile) ;
my $nodeset = $xp-find($expr) ;
if($nodeset-size) { print Authentication successfuln ; }
else { print Authentication failedn ; }
Ce script lis le nom d’utilisateur et le mot de passe donnés comme paramètres
(ARGV[0] et ARGV[1]) et intérroge les fichier XML via une requête XPath, la
vulnérabilité réside dans le fait qu’il est possbile d’injecter la chaîne vulnérable
« or ’1’ = ’1’ » aprés le mot de passe, donc l’expression $expr va contenir la valeur :
//user[username=’$login’ and password=’$pass’ or ‘1’ = ‘1’]
le code sera exécuté et le résultat sera vrai toujours ; cela permet de récupérer
les utilisateurs enregistrés comme décrit précédemment.
30

2.5.2.2 Dumping d’un Document XML
Le Dumping se fait à l’aide de l’opérateur‘|’ [Renaud, 2010].Cet opérateur est :
– L’opérateur identique à UNION mais plus flexible.
– Effectue des opérations séquentielles.
– Exploite l’absence de restrictions d’accès aux parties d’un document.
2.5.2.2.1 Utilisation dans une injection XPath
– La requête de description d’un attribut via XPath :
– « //item[itemID=‘$id’]/description/text() »
– Injection : $itemID = whatever‘] | /* | //item[itemID=‘whatever’.
– Expression devient alors :
– « //item[itemID=‘whatever‘] | /* | //item[itemID=‘whatever’]/description/text() »
– Cette technique nécessite une connaissance préalable de l’expression.
2.5.2.3 Blind XPath Injection
Le Blind XPath Injection a été introduite pour la 1ére fois en 2004 par Amit
KLEIN [Klein, 2005], elle permet de récupérer l’intégralité du document XML,
sans connaissance de l’expression XPath.
2.5.2.3.1 Mode opératoire
1. Trouver une injection “standard”
2. Remplacer le prédicat ‘1’=‘1’ par une expression E dont le résultat est binaire
3. E est utilisé pour évaluer :
– Chaque bit du nom ou de la valeur d’un élément
– Le nombre d’éléments de chaque type (élément, texte, PI etc.)
2.5.2.3.2 Contraintes
– Lent (à-la Brute Force)
– Démontré mais pas d’implémentation disponible
2.5.2.4 Injection XQuery
XPath est un sous-ensemble d’un langage de requête sous XML plus large, qui
est XQuery, et que ce dernier lui aussi souffre d’un grand problème de sécurité et
plus précisément problème des injections [WEBAPPSEC, 2010].
L’injection XQuery est une variante de la fameuse attaque injection SQL :
31

– Elle utilise les mauvaises données passées à une requête XQuery pour traverses
et exécuter les routines XQuery.
– Elle peut être utilisée pour lister les éléments d’un environnement victime,
injecter des commandes en local ou exécuter des commander à distance.
– Un attaquant peut injecter des requêtes XQuery dans un message SOAP pour
manipuler un document XML au niveau du fournisseur du service web.
L’exemple suivant montre comment interroger le fichier users.xml afin de récupérer
la liste des utilisateurs.
doc(users.xml)//user[name=’*’]
Il existe plusieurs formes des injections XQuery qu’on ne peut pas listées toutes,
cependant elles sont toutes dues à la non vérification des champs de saisie avant
l’envoi de la requête.
2.5.2.5 Injection XPath dans les messages SOAP
L’injection XPath est présente dans les web services qui utilisent un fichier XML
pour sauvegarder les données, ceci est un exemple (figure 2.5.4) illustrant un exploit
via un message SOAP; où on a injecté la chaîne vulnérable ’ or ’1’ = ’1’ or ’a’ =
’a :
Figure 2.5.4 : Injection XPath dans un message SOAP
32

Le web service recevra ainsi une requête XPath malveillante de lister tous les
utilisateurs et leurs mots de passe, la réponse est la suivante (figure 2.5.5) :
Figure 2.5.5 : Réponse du service web : lister tous les (username,password)
2.5.3 Injection SQL
Les injections SQL consistent à insérer ou injecter du code SQL via des don-nées
entrées par l’utilisateur à l’application. un exploit réussi d’une injection
SQL peut lire données sensibles depuis la base de données, modifier ces données
(Insertion/Mise-à-jour/Suppresion), éxecuter des opérations d’administration de la
base de données (ex. Arréter le SGBD), récupérer le contenu d’un fichier présent
dans le système de fichiers du SGBD, ou dans certains cas éxecute des commandes
du système d’exploitation [OWASP, 2014b].
Les injections SQL sont un type d’attaques par injection, dont c’est le code SQL
qui est injecté dans le champ de saisie à fain d’éxecuter une commande SQL bien
définie.
Il existe plusieurs formes d’injections SQL, qui sont :
2.5.3.1 Manipulation du SQL
C’est la forme la plus commune, l’attaquant essaye de modifier le code SQL
existant en ajoutant des éléments à la clause ’WHERE’ ou étendre la requête SQL
par des opérations comme ’UNION’, ’MINUS’ ou ’INTERSECT’. Il existe bien
évidemment d’autres formats mais ceux sont les plus répandus et les plus fréquents
[Scambray, 2006].
Exemple 01
La manipulation de SQL la plus classique est durant une fonction d’authentifi-cation
« login ». Une application web ou un service web vérifie l’authentification
de l’utilisateur en éxecutant la requêtes suivante et vérifiant si des lignes sont
retournées ou pas.
Requête SQL pour authentification
SELECT * FROM users
WHERE username = ’zsmahi’ and password = ’mypassword’
33

L’attaquant essayera alors de manipuler le code SQL pour l’éxecuter de cette
façon
Requête SQL pour authentification
SELECT * FROM users
WHERE username = ’zsmahi’ and password = ’mypassword’ or ’a’ = ’a’
La clause ’WHERE’ est vraie pour chaque ligne et le pirate obtient l’accés total
à l’application.
Exemple 02
L’opérateur ’UNION’ est souvent utilisé dans les injections SQL. Le but est de
manipuler SQO afin de retourner des enregistrement d’une autre table. Un exemple
d’une telle requete :
Requête SQL typique
SELECT product_name FROM all_products
WHERE product_name like ’%Chairs%’
un pirate tentera de manipuler SQL afin d’éxecuter cette requête :
Requête SQL avec injection UNION
SELECT product_name FROM all_products
WHERE product_name like ’%Chairs%’
UNION
SELECT username FROM dba_users
WHERE username like ’%’
Cette requête retourne non seulement les noms des produits mais aussi tous les
noms d’utilisateurs.
2.5.3.2 Injection de Code
L’injection de code essaye d’ajouter du code SQL ou bien des commandes au code
code SQL existant. Ce type d’attaques est utilisé fréquement utilisé contre le SGBD
Microsoft SQL Server et rarement avec Oracle. L’instruction ’EXECUTE’ dans
SQL Server est une cible fréquente des attaques par injection SQL [Kost, 2004].
Requête SQL avec injection UNION
SELECT * FROM users
WHERE username = ’zsmahi’ ans password = ’mypassword’ ; DELETE
FROM users WHERE username =’admin’ ;
Nota que cette faille n’est disponible que dans un certains nombre de langages
de programmation et de API qui autorisent l’éxecution de plusieures requêtes SQL
à la fois.
34

2.5.3.3 Injection des appels de fonctions
L’injection des appels de fonctions est l’insertion des fonctions de la base de don-nées
Oracle ou des fonctions spéciales dans un code SQL vulnérable [Kost, 2004].
Ces appels sont utilisés pour faire des appels systèmes ou bien pour manipuler les
données de la base.
En utilisant les standards des fonctions Oracle, l’attaquant peut envoyer des
informations depuis la base de données jusqu’à un Serveur (ou PC) distant ou
éxecuter d’autres attaques depuis le serveur de la base de données. Plusieurs pa-quetages
des base de données Oracle peuvent être exploité par un attaquant. Ces
paquetages peuvent inclure des fonctions pour changer les mots de passes ou éf-fectuer
d’autres transactions sensibles.
Le problème avec ce type d’injections est que n’importe quelle requête SQL
générée automatiquement, même la requête la plus simple peut être exploitée.
Les développeurs d’applications utilisent des fois des fonctions de bases de don-nées
au lieu du native code (ex. Java) pour effectuer des tâches courantes. Un
exemple trés courant et qui vient tout de suite à l’esprit c’est bien la fonction
’TRANSLATE’ qui n’a pas d’équivalant en Java, donc le programmeur décide
d’utiliser les requêtes SQL à la place.
L’exemple suivant montre la fonction translate et comment on peut l’utiliser
pour effecuter un exploit d’injection SQL :
Requête SQL ’TRANSLATE’
SELECT TRANSLATE(’user input’,
’0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ’,
’0123456789’)
FROM dual ;
Cette requête n’est pas vulnérable aus types vues précédemment mais elle est
facilement manipulée via une injection d’appel de fonction, on peut la modifier
pour éxecuter le code suivant :
Injection d’Appel de fonction dans la requête TRANSLATE
SELECT TRANSLATE(’|| UTL_HTTP.REQUEST(’http ://192.168.1.1/’)|| ’,
’0123456789’)
FROM dual ;
La nouvelle requête SQL va intérroger une page depuis un serveur web. L’at-taquant
peut manipuler la chaîne et l’URL pour inclure autres fonctions àfin
de rechercher des informations utiles depuis le serveur de la base de données et
l’envoyer au serveur web via l’URL. Cette faille peut être utilisée pour attaquer
d’autres serveurs et web services dans le réseau interne.
35

Des fonctions particuliéres et les fonctions de paquetages particuliers peuvent
aussi être éxecutées. Un exemple est une application avec une fonction ’ADDUSER’
(ajouter utilisateur) dans le paquetage ’MYAPPADMIN’. Le développeur a mar-qué
la fonction avec ’PRAGMA TRANSACTION’ une fonctionnalité des bases de
données Oracle qui permet à l’application d’écrire à la base de données même avec
une requête SQL.
Injection d’Appel de fonction
SELECT TRANSLATE(’|| myappadmin.adduser(’admin’,’newpass’)|| ’,
’0123456789’)
FROM dual ;
Executer la requête précédente permet même d’ajouter un utilisateur « admin »
avec le mot de passe « newpass ».
2.5.3.4 Blind SQL Injection
Le Blind SQL Inejction est un type d’injections SQL, qui intérroge la base de
données à travers des requêtes vrai/faux (true/false) et détérmine la réponses basée
sur les réponses d’application. Cette attaque figure souvent lorsqu’une application
est configurée pour afficher des messages d’erreurs génériques et n’indique pas qu’il
ya une vulnérabilité aux injections SQL [OWASP, 2013a].
Quand un attaquant exploite une injection SQL, des fois le service web ; ou
l’application web en général ; affiche des messages d’erreurs indiquant une erreur
dans la syntaxe SQL. Le Blind SQL Injection est similaire à l’injection SQL simple ;
la différence réside dans la manière que les données sont récupérées depuis la base
de données.
Une base de données qui n’affiche pas les données dans une réponse (message
SOAP, page web, API ...etc.) force les pirates à voler les données en interrogeant
la base par une série de questions vrai/faux, ceci met l’exploit plus difficile mais
pas impossible.
Il existe plusieurs formes de cette attaque,
2.5.3.4.1 Blind basé sur le contenu (Content-Based)
l’URL « http ://newspaper.com/items.php ?id=2 » envoie la requête suivante :
SELECT title, description, body FROM items WHERE ID = 2
Le pirate essayera d’injecter une requête qui retourne ’false’ (faux) :
« http ://newspaper.com/items.php ?id=2 and 1=2 »
36

Maintenat la requête est :
SELECT title, description, body FROM items WHERE ID = 2 and 1=2
Si l’application est vulnérable aux injections SQL, alors il est probables qu’elle
ne fait retourner rien. Pour s’assurer le pirate tente d’injection une requête qui
retourne ’true’ :
« http ://newspaper.com/items.php ?id=2 and 1=1 »
Si le contenu de la page qui retourne ’true’ est différent de celui de ’false’ alors
l’attaquant est capable de distinguer quand la requêt fait retourner vrai ou faux.
Une fois vérifiée, les seuls limitations sont les privilèges faites par l’administrateur
de la base de donnée, la syntaxe SQL et l’imagination et le savoir-faire du pirate.
2.5.3.4.2 Blind basé sur le temps d’attente (Time-Based)
Elle est basée sur les appels d’attente de chaque SGBD pour indiquer l’éxecution
avec succés de la requête. L’attaquant énumére chaque lettre de la réponse désirée
en suivant cette logique :
– Si la 1ere lettre du 1er nom de la base de données est ’A’ : pause de 10 sec.
– Si la 1ere lettre du 1er nom de la base de données est ’B’ : pause de 10 sec.,
...etc.
Pour effectuer ceci, on a recours à certains fonctions de « pause » des SGBD :
comme ’waitfor delay’ pour MS-SQL Server, ’by n seconds’ de MySQL, ’pg_sleep()’
de PostegreSQL ...etc.
Le blind SQL n’est pas, en général, facile à exploiter mais en même temps il est
possible de l’exploiter, tout dépendera de l’expérimentation du pirate.
2.5.3.5 Injection SQL dans les messages SOAP
L’injection SQL est présente dans les web services. L’exemple (figure 2.5.4) suiv-ant
illustre comment l’exploiter via un message SOAP : Voir figure suivante (figure
2.5.6) où on a injecté la chaîne vulnérable ’ OR 1 = 1 – :
37

Figure 2.5.6 : Injection SQL dans un message SOAP
Le web service recevra ainsi une requête SQL malveillante pour tout lister, la
réponse est la suivante (figure 2.5.7) :
Figure 2.5.7 : Réponse SOAP à l’injection SQL
38

2.5.4 Injection de commandes OS
L’injection de commandes du système (OS) ou plus communement l’injection de
commande est un type d’injection ou l’objectif est d’éxecuter des commandes sur la
machine hôte via une application vulnérable. Cette injection est possible lorsqu’une
application passe des données vulnérables entrées par l’utilisateur( cookies, en-têtes
HTTP ...etc.) au shell du système[Lackey, ]. Les commandes systèmes envoyées
sont souvenet exécutées avec les privilèges de l’application vulnérable. L’injection
de commande est due à l’absence ou l’insuffisance de validation de données de
l’input [OWASP, 2014a].
Ci-dessous un code en langage C qui est vulnérable à cette injection
Algorithme 2.2 Code C vulnérable à l’injection de commandes
#include stdio.h
#include unistd.h
int main(int argc, char **argv)
{
char cat[] = cat ;
char *command ;
size_t commandLength ;
commandLength = strlen(cat) + strlen(argv[1]) + 1 ;
command = (char *) malloc(commandLength) ;
strncpy(command, cat, commandLength) ;
strncat(command, argv[1], (commandLength - strlen(cat)) ) ;
system(command) ;
return (0) ;
}
39

Ce code ne fait rien d’autre qu’imprimer le contenu d’un fichier passé comme
1er argument en utilisant la commande ’cat’ de UNIX. On l’éxecute comme suit :
$ ./commandeCat fichier.txt
Le résultat est :
Ceci est le contenu du fichier « fichier.txt »
éxecutons le même programme cette fois-ci en remplaçons le paramètre fichier.txt
par « fichier.txt ; ls » ; rappelons que la commande ’ls’ sert à lister le contenu d’un
répertoire.
Le résultat sera alors cette fois-ci (tableau 2.2) :
Résulat
Ceci est le contenu du fichier « fichier.txt »
fichier.txt ; unAutreFichier.txt ; unRepertoire
Table 2.2 : Exemple d’injection de commande
L’injection de commande est présente fréquement dans les services web qui pro-posent
des services réseaux tel que le ’ping’ et le ’traceroute’.
2.5.4.1 Injection de commandes OS dans les messages SOAP
L’injection de commandes est présente dans les web services. L’exemple (figure
2.5.8) suivant illustre comment l’exploiter via un message SOAP dans un service
web qui propose des « ping » :
Figure 2.5.8 : Injection Commandes dans un message SOAP
40

On a injecté la chaîne « ; cat /etc/passwd » pour lister le fichier des mots de
passe des utilisateurs du serveur hébergeant le web service. La réponse a été la
suivante (figure 2.5.9) ; on a pu effectué le ping et en plus on a listé le fichier
passwd :
Figure 2.5.9 : Injection Commandes dans un message SOAP
41

2.6 Conclusion
Les Web Services sont de plus en plus déployés sur l’Internet en raison de leurs
protocoles normalisés, et des techniques qui permettent l’intégration efficace des
applications faiblement couplées sur les réseaux. Toutefois, en raison de l’interface
ouverte pour une architecture orientée services, les attaques contre les systèmes
axés sur les Web Services sont plus compliquées que les attaques classiques qui
peuvent être traitées par des pare-feu traditionnels. Ainsi, il est nécessaire d’intro-duire
de nouveaux mécanismes de sécurité pour protéger les systèmes axés sur les
Web Services.
Nous allons vois dans le chapitre suivant les principaux travaux qui ont été faites
afin de sécuriser les web services contre les attaques par injection.
42

Chapitre 3
Approches de sécurisation des web
services
3.1 Introduction
Nous avons vu précédemment que les web services sont confrontés à un certain
nombre d’attaques qui visent à les détruire. Malheureusement ces attaques ne sont
pas prises par les outils de protection, existants tel que les pare-feu.
Pour assurer une protection effective et réelle des web services, les pare-feu
XML ont été introduits comme extension des pare-feu actuels et comme approche
de sécurisation des web services.
On verra dans cette section c’est quoi un pare-feu XML et quels sont les recherches
effectuées dans ce domaine ainsi les solutions proposées.
3.2 Firewall XML
Les pare-feu XML (XML firewall en anglais) est une nouvelle technologie intro-duite
afin de sécuriser les web services contre les attaques. Avant d’introduire la
notion d’un pare-feu XML, nous rappelons la notion de pare-feu.
3.2.1 Pare-feu (Firewall en anglais)
C’est est un système qui assure la protection d’un ordinateur, ou un réseau
d’ordinateurs des incursions provenant d’un réseau internet. Il s’agit d’un système
de filtrage des paquets de données échangées avec le réseau[Xu, 2008].
Les pare-feux sont généralement mis en oeuvre pour bloquer et restreindre cer-tains
accès et implémenter les règles de la politique de sécurité [Cheswick, 2003].
43

Chapitre 3 Approches de sécurisation des web services
3.2.2 Pare-feu XML
Il est particulièrement approprié pour neutraliser les actes malveillants contre
les Web Services. Il utilise les informations de sécurité contenues dans chaque
message échangé, pour sécuriser les différentes parties d’un message SOAP échangé
[Ayachit, 2006].
Ainsi ; Il est compatible aux différents protocoles de transport, et renforce les in-sertions
de sécurité des messages de services, de port ou d’opération [CCM, 2014b].
Actuellement, on a la tendance d’utiliser le terme «XML Security Gateway» pour
les XML Firewall, car on attend de ces pare-feu un travail plus qu’un conventionnel
pare-feu[Patterson, 2007].
La figure suivante (figure 3.2.1) montre un système basé sur les web services
protégés par un pare-feu XML[Xu, 2008] :
Figure 3.2.1 : Système basé sur les web services protégé par un pare-feu XML
3.3 Les approches de sécurisation des web services
Afin de sécuriser un web service plusieurs travaux et recherches ont été effectuées
proposant chacune une architecture d’un système de sécurisation (XML Firewall).
Nous allons dans cette section introduire les différentes approches et les méthodes.
Avant d’entammer les approches de sécurité, rappelons la notion des expressions
régulières et de la distance de Khi-2.
3.3.1 Les expressions régulières
Une expression régulière ou rationnelle est une chaîne de caractères (appellée
parfois un motif ) qui décrit un ensemble de chaînes de caractères possibles selon
44

une syntaxe précise. Les expressions régulières sont issues des théories mathéma-tiques
des langages formels des années 1940. Leur puissance à décrire des ensembles
réguliers explique qu’elles se retrouvent dans plusieurs domaines scientifiques dans
les années d’après-guerre et justifie leur adoption en informatique. Les expressions
rationnelles sont aujourd’hui utilisées par les informaticiens dans l’édition et le
contrôle de texte ainsi que dans la manipulation des langues formelles que sont les
langages de l’informatique[Desgraupes, 2008].
Exemples
Voici quelques exemples des expressions réguliéres les plus utilisées (tableau 3.1)
[loribel, 2003] :
caractères Signification
. n’importe quel caractère
(123.5 = 123.5, 12345...etc.)
? le caractère précédent ? est optionnel
(12 ?34 = 1234, 134...etc.)
* le caractère précédent * peut être répété 0 ou plusieurs fois
(12*34 = 134, 1234, 12234, 122234...etc)
+ le caractère précédent * peut être répété 1 ou plusieurs fois
12+34 = 1234, 12334, 12222234...etc. mais ne trouvera pas 134
$ le carcatère est à la fin d’une ligne
toto$ = toute ligne finissant pas toto
Table 3.1 : Exemples expressions régulières
3.3.2 Test du Khi-2 2
Le test du Khi2 (khi deux ou khi carré) fournit une méthode pour déterminer
la nature d’une répartition, qui peut être continue ou discrète. Il est utilisé dans
différents domaines tels que la comparaison des échantillons, Recherche de liaison
entre les données ou Recherche de l’influence d’une donnée autre que celle étudiée
[Zerrouk, 2011].
Principe :
– Formuler H0 (la distribution observée n’est pas différente de la distribution
supposée d’après la loi que l’on souhaite tester).
– Répartir les données en classes.
– Déterminer le nombre de degrés de liberté à partir du nombre de classes.
– Fixer un risque de se tromper (la valeur 5 % est souvent choisie par défaut).
45

– Calculer algébriquement la distance entre les ensembles d’informations à com-parer.
– Déterminer Khi-2 théorique (déduire la distance critique à l’aide d’une table
de 2 ).
– Conclure si cette distance est supérieure à la distance critique (on conclut que
le résultat n’est pas dû seulement aux fluctuations d’échantillonnage).
Une statistique de khi-2 entre une distribution observée et une distribution atten-due
se calcule comme celui-là (Algorithme 3.4) :
Algorithme 3.1 Distance de Khi-2
D2(O,E)=PNi
=1
(Oi−Ei)2
Ei
Dans cette formule D²(O,E) est la distance Khi-2 2 entre une distribution
observée O et un résultat attendue E ( souvent un dataset extrait à partir d’une
phase d’apprentissage) et N-1 est le degré de liberté du test de 2.
La distance D² calculé et le degré de liberté N-1(cas d’un test d’ajustement) sont
utilisés pour obtenir une valeur p de la table 2. La valeur p indique la probabilité
de la distribution observée pour être compatible avec la distribution attendue.
La distance D² est comparée à un seuil 2(,N-1) (( est généralement pris 0.05
(ou erreur à 95%) , 2(,N-1) est le seuil de décision pour une distribution 2
avec un degré de liberté de N-1.) Deux hypothèses sont posées alors H0 et son
alternative H1 :
– H0 : D² 2(,N-1)
– H1 : D² 2(,N-1)
H0= {les i échantillons sont issus d’une seule population}
Contre H1 = {les i échantillons sont issus de deux populations différentes}
Procédure de lecture à partir de La table Khi-2
– On calcule d’abord la distance de Khi-2 (formule Algorithme 1.4).
– On cherche cette valeur dans la table (Figure 3.3.1) pour un degré de liberté
précis ( les lignes de la table).
– Une fois trouvée (ou bien un voisinage de la valeur est trouvé) on remonte à
la valeur trouvé en colonne qui représente une valeur p de probabilité.
– la valeur p est comparée au seuil défini au préalable et on décide d’admettre
ou de rejet l’hypothèse nulle H0.
46

Figure 3.3.1 : Table de Khi-2
47

3.3.3 Les approches à base de signatures
Ces approches sont les plus anciennes et les plus basiques. Elles consistent à
rechercher dans les messages SOAP entrants les empreintes ou les signature d’at-taques
connues. Cette approches a été utilisée dans les IDS (Intrusion Detection
System) et dans les antivirus.
3.3.3.1 Avantages :
– Un firewall XML utilisant cette approche est facilement conçu et développée
et maintenu par la suite.
– Il permet également une classification relativement facile de la criticité des
attaques signalées.
3.3.3.2 Inconvénients :
– L’incovénient majeur de cette approche est qu’elle est limitée, un firewall
XML utilisant cette approche est purement réactif, il ne peut détécter que les
attaques dont il posséde déjà la signature, de ce fait, il nécessite des mises à
jour quotidiennes.
– Un autre inconvénient de cette approche est qu’elle est bonne que l’est la
base de signature, si les signatures sont erronées ou incorrectement conçues le
systèmes est inefficace, c’est pourquoi ces systèmes sont souvent contournés
par les pirates qui utilisent des techniques d’évasion qui consistent à camoufler
les attaques utilisées. Ces techniques de camouflage ont tendance à faire varier
les signatures des attaques qui ainsi ne sont par reconnues par le firewall XML.
Les signatures sont souvent représentées par des formats compacts tel que les ex-pressions
régulières. Ci-dessous (tableau 3.2) quelques expressions régulières util-isées
afin de bloquer quelques attaques par injection [Mookhey, 2004] :
Inejction Expression régulières
« ’ »,« ## » /(%27)|(’)|(--)|(%23)|(#)/ix
« or » /w*((%27)|(’))((%6F)|o|(%4F))((%72)|r|(%52))/ix
« exec » /exec(s|+)+(s|x)pw+/ix
Table 3.2 : Signature de quelques attaques par inejction (cas injection SQL)
3.3.4 Les approches probabilistes
Nous avons défini précédement ; la 1ère approche utilisée afin de sécuriser les
web services contre les attaques par injection (l’approche par signature), et ses
48

insuffisances. Dans cette section nous présentons une autre approche qui n’est
pas exacte comme l’approche par signature, vu qu’elle est basée sur des modèles
statistiques ou probabilistes, mais en revanche elle balaye aux insuffisances de
l’ancienne approche ; tel que la détection de nouvelles attaques ; et elle donne de
bons résultats. Une approche probabiliste utilise des notions du « data mining ».
Il existe plusieurs algorithmes probabilistes qui ont été proposés pour sécuriser
les web services basés tous sur le data mining, on va se limiter dans cette section
aux approches utilisants la comparaison et la similarité entre chaînes de caractères
comme critère de classification.
3.3.4.1 Comparaison et calcul de similarité entre chaînes de caractères
La comparaison entre chaînes de caractères est une opération importante dans
plusieurs disciplines (biologie moléculaire, Recherche de l’Information R.I, caté-gorisation
des textes ...etc.). Après isolation et séquençage d’une chaîne de car-actères,
qui peut consister de plusieurs centaines à voir des milliers de caractères
alphanumériques et symboles, les chercheurs essayent souvent de trouver une base
de données de chaînes de caractères connues -dans un certain domaine de recherche-afin
de mettre la ressemblance par la suite. En faisant ça, ils espèrent que les ré-sultats
précédents aideront à tirer des conclusions au sujet de leur nouveau volet ;
d’ou est née la théorie de comparaison de chaînes de caractères [Lipton, 1985].
Par la suite on verra, les différents algorithmes et distance utilisées pour calculer
la similarité entre deux chaînes de caractères.
3.3.4.1.1 Distance de Levenshtein
La distance de Levenshtein mesure le degré de similarité entre deux chaînes de
caractères. Elle est égale au nombre minimal de caractères qu’il faut supprimer,
insérer ou remplacer pour passer d’une chaîne à l’autre. C’est une distance au sens
mathématique du terme, donc en particulier c’est un nombre positif ou nul, et
deux chaînes sont identiques si et seulement si leur distance est nulle. On a aussi
des propriétés de symétrie, et l’inégalité triangulaire de la géométrie est ici aussi
vérifiée. (Algorithme voir annexe B)[Nicolas, 2012].
Exemple
1. La distance de Levenshtein entre kitten and sitting est 3 :
a) Substitution de ’k’ par ’s’.
b) Substitution de ’e’ par ’i’
c) Insertion de ’g’ à la fin.
2. La distance de Levenshtein entre rosettacode and raisethysword est 8.
49

3.3.4.1.2 LCS (Longest Common Subsequence) : La plus longue séquence
Commune
Le problème de la plus longue séquence commune est de trouver consiste à
trouver la plus longue séquence commune à toutes les séquences dans un ensemble
de séquence (souvent deux). Notez qu’une séquence est différente de la sous-chaîne
par le fait que les termes ne sont pas nécessairement consécutifs dans la chaîne
originale. Il s’agit d’un problème informatique classique utilisé dans la comparaison
de fichiers tels que ‘diff’, et en bioinformatique. La complexité de cet algorithme
est O(nm).
Voici l’algorithme (Algorihme 3.1) récursif de la fonction LCS : On note LCS(XiYj)
pour la plus longue sous-séquence commune de (x1..,xi) et (y1..,yj) [Binet, 2010].
Algorithme 3.2 Algorithme de LCS
LCS(Xi, Yj) =
8
:
vide i = 0 ou j = 0
LCS(Xi−1, Yj−1) + 1 xi = yj
laPlusLongue(LCS(Xi, Yj−1),LCS(Xi−1, Yj)) xi6= yj
3.3.4.1.3 La similarité cosinus
Si on peut relier la similarité entre deux vecteurs A et B à la mesure de l’angle
¸ qu’ils forment, alors on peut l’évaluer en calculant le cosinus de cet angle :
c’est ainsi qu’est définie la similarité cosinus. Le calcul du cosinus se base sur
l’expression du produit scalaire A.B = ||A||.||B||.cos() et implique qu’aucun des
deux vecteurs ne soit nul [Progdupeupl, 2012]. Voici la formule de la similarité
cosinus (Algorithme 3.2)
Algorithme 3.3 Formule de similarité de cosinus
similarité(A,B) = cos()= A.B
||A||.||B||=
Pni
pP =1Ai×Bi n
i=1 A2i
pPn
×
B2
i=1 i
Si nos poids ne peuvent pas être négatifs, alors on a 05similarité(A,B)51. Plus
la mesure de l’angle est faible, plus son cosinus est élevé : avec cette formule, plus
similarité(A,B) s’approche de 1, plus la similarité entre les objets représentés par
les vecteurs A et B est grande.
3.3.4.1.4 Coefficient de Dice
Le Coefficient de Dice est une mesure de similarité, utilisée en statistique pour
déterminer la similarité entre deux échantillons. Ce coefficient est compris entre 0
50

et 1. Il se définit comme le double de l’intersection de deux lots (échantillons de
valeurs) divisé par l’union de ces deux lots. La formule ci-dessous (Algorithme 3.3)
résume la méthode de calcul [Tony, 2010] :
Algorithme 3.4 Formule de Coefficient de Dice
S = 2×|X
T
Y |
|X|+|Y |
Dans cette formule, X et Y sont des lots. Pour calculer le coefficient de Dice de
deux chaines, il est possible de définir X et Y comme l’ensemble des bigrammes de
chacune des chaines respectives.
3.3.4.1.5 Représentation en N-gramme d’une chaîne de caractères
Un n-gramme est une sous-séquence de n éléments construite à partir d’une
séquence donnée. L’idée provient des travaux de Claude Shannon [Shannon, 1951]
en théorie de l’information. Son idée était que, à partir d’une séquence de lettres
donnée (par exemple par exemple) il est possible d’obtenir la fonction de vraisem-blance
de l’apparition de la lettre suivante. À partir d’un corpus d’apprentissage,
il est facile de construire une distribution de probabilité pour la prochaine lettre
avec un historique de taille n. Cette modélisation correspond en fait à un mod-èle
de Markov d’ordre n où seules les n dernières observations sont utilisées pour
la prédiction de la lettre suivante. Ainsi un bigramme est un modèle de Markov
d’ordre 2.
A partir du (court) corpus par exemple, nous obtenons (tableau 3.3) :
Pas d’historique (unigramme) Historique de taille 1 (bigramme)
p : 2 occurrences sur 10 lettres = 1/5 ; p-a : 1 occurrence sur 9 couples = 1/9 ;
e : 3 occurrences sur 10 lettres = 3/10 ; p-l : 1 occurrence sur 9 couples = 1/9 ;
x : 1 occurrence sur 10 lettres = 1/10 ; p-e : 0 occurrence sur 9 couples = 0 ;
... La somme des probabilités étant nécessairement égale à 1
Table 3.3 : 1-grammes et bigrammes extraits de la chaîne par exemple
Le modèle des N-grammes est un modèle de représentation du langage partic-ulièrement
utilisé pour étudier la prédictibilité d’apparition de suites de chaîne.
On qualifie de N- grammes aussi bien des n-uplets de caractères que des n-uples de
mots. Dans une matrice de contingence au lieu de croiser des objets entre eux on va
croiser des n-uplets entre eux et appliquer ensuite un algorithme de classification.
Ainsi pour un alphabet de 26 lettres on obtient 262 = 626 bigrammes ou 263 =
16 276 trigrammes, pour un dictionnaire de 20 000 mots on obtient 20 0002 = 400
millions de bigrammes et 20 0003 = 8 000 milliards de trigrammes. On construit
51

un modèle à partir de données d’apprentissage pour déduire la probabilité d’avoir
telle suite de N-grammes [Lelu, 1998].
On parle souvent de n-gramme de mot et n-gramme de caractères :
N-gramme de mot
On définit un n-gramme de mots par une suite de n mots ; séparés par délimiteurs
(espaces, ponctuation, . . . etc.). Ce type de n-gramme est utilisé dans plusieurs do-maines
tels que la détection des attaques http, détection des injections SQL. . . etc
[Choi, 2011].
Un exemple qui arrive souvent est la détection des attaques XSS dans un for-mulaire
web, examinons la chaîne suivante : script alert(« XSS ») ;/script :
Après l’extraction des délimiteurs (‘’,’’,’ « ‘, ‘ »’, ‘ ;’, ‘/’,’(‘,’)’) on aura les
n-grammes suivants :
– Bigrammes : « script alert », « alert XSS », « XSS script »
– Trigrammes : « script alert XSS », « alert XSS script »
– Quadri-grammes : « script alert xss script »
N-gramme de caractères
On définit un n-gramme de caractère par une suite de n caractères ; bi-grammes
pour n= 2, trigrammes pour n=3, quadri-grammes pour n=4 . . . etc. A la différence
de n-gramme de mots, on ne cherche pas ici de délimiteurs, un tel découpage per-met
l’extraction de données dans une base de données contextuelles quelques soit
la langue utilisée. La notion de n-grams de caractères prit davantage d’impor-tance
avec les travaux de Grefenstette (1996) [Hull and Grefenstette, 1996]
sur l’identification de la langue et de Damashek (1995) [Damashek, 1995] sur
le traitement de l’écrit. Les n-grammes de caractères ont figuré aussi dans l’in-dexation
; l’hypertextualisation automatique multilingue avec les travaux de Lelu
(1998) [Lelu, 1998].
Comparaison et distance entre n-grammes
On peut calculer la similarité entre n-grammes en utilisant les n-grammes avec
les distance vues précédemment :
– distance entre n-grammes : en utilisant les distances dice, cosinus...etc.
– distance entre fréqueneces de n-grammes : en utilisant la distance 2.
52

3.3.4.2 Quelques travaux sur la détection des attaques par injection
3.3.4.2.1 Urjita Thakar
Un Honeypot est un système volontairement vulnérable à une ou plusieurs men-aces,
déployé sur un réseau afin d’analyser les attaques dans le Honeypot. Ces sys-tèmes
peuvent être volontairement insécurisés, afin d’attirer les attaquants pour
étudier leurs techniques, outils ou leurs motivations.
On propose dans cet article [Thakar and Dagdee, 2010] une approche semi-automatique
pour analyser les attaques et générer les signatures pour les web
services. En dehors des données SOAP conventionnelles journalisées, les honeypots
sont utilisées pour collecter les données.
Afin de filtrer la plupart des données suspects, un classificateur basé sur SVM
est utilisé pour aider l’admnistration. En appliquant un algorithme de signature
d’attaque sur des données filtrées, une signature d’attaque plus équilibrée est ex-trait
qui entraîne moins de faux positifs et négatifs. Il permet à l’administrateur
de sécurité d’identifier les services Web qui sont vulnérables ou sont attaqués plus
fréquemment.
3.3.4.2.2 Junho Choi
Dans ce travail de recherche [Choi, 2011], les auteurs proposent une méthode
pour la détection des attaques injections SQL et XSS (Cross Site Scripting) en
utilisant les n-grammes de mots et le SVM (Support Vector Machine).
Un algorithme de détection du code malicieux basé sur les n-grammes a été
proposé, par lequel plusieurs vecteurs de caractéristiques précis et efficaces peuvent
être extraites, et assortis par les différences entre les vecteurs de caractéristiques
des codes malicieux. Les caractéristiques extraites de code malveillant à l’aide des
n-grammeq peuvent être appliquées dans toutes sortes d’algorithmes de code de
détection malveillants pour détecter les codes malveillants inconnus. L’approche
proposée utilise le SVM comme classificateur d’apprentissage automatique.
3.3.4.2.3 Khwairakpam Amitab
Les auteurs [Amitab, 2011]proposent une comparaison entre les techniques de
détection d’injections SQL qui utilisent le test de Khi-2. La comparaison a été faite
sur les trois approches attribute character distribution (ACD), Same Character
Comparison (SCC) et Idealized Character Distribution (ICD), le critère était le
taux des vrai positifs et faux positifs.
53

3.3.4.2.4 Adityaram Oza
L’auteur propose dans sa thèse de master [Oza, 2013] intitulée « HTTP Attacks
Detection using n-gram analysis » une méthode pour la détection des attaques
HTTP en utilisant l’analyse par n-gramme et le test de Khi-2.
La méthode consiste à collectionner les bonnes requetes HTTP depuis les logs
des serveurs Apache, et extraire à partir de chaque requete les différents 3-grammes
possibles et leurs fréquences d’apparition normalisées par la taille du paquet http.
Un vecteur moyen sera construi par la suite à partir des bonne requêtes et il
sera comme un dataset afin de le comparer avec les nouvelles requetes entrantes.
Lorsqu’une requete est arrivée, on extrace ses différents n-grammes ; comme on a
fait pour les requêtes d’apprentissage, et on calcule la distance de Khi-2 « D » ;
selon cette distance et sous les hypothèses : on décide :
– H0 : D 2(0.05,N-1) = La requête est bonne.
– H1 : D 2(0.05,N-1) = la requête est malveillante.
3.3.5 Synthèse des travaux
Dans la partie précédente, nous avons présenté les travaux de sécurisation des
Web Services, ces travaux traitent les attaques contre les Web Services avec dif-férentes
techniques, permettant ainsi de détecter plusieurs types d’attaques. Cepen-dant,
nous avons constaté que malgré les bienfaits de ces approches, chacune d’en-tre
elles détient des points faibles remarquables. Par la suite nous allons discuté
les avantages et les inconvénients de chaque méthode.
3.3.5.1 Les Approches par signature et les approches probabilistes
Les approches par signature sont faciles à implémenter et configurer et main-tenir
par la suite, elle donne de bonnes résultats de protection, malheureusement
un XML firewall basé sur cette technique est réactif et ne s’adapte pas avec les
nouvelles attaques.
Les approches probabilistes, en revanche, sont actifs et s’adaptent avec les nou-velles
s’attaques, mais tout dépendera de l’échantillon utilisé dutant la phase d’ap-prentissage.
Ces techniques générent un nombre de faux postifs et faux négatifs
.
3.3.5.2 Les approches probabilistes
Dans la partie précédente, nous avons présenté les travaux de sécurisation des
Web Services, ces travaux traitent les attaques contre les Web Services avec dif-férentes
techniques, permettant ainsi de détecter plusieurs types d’attaques. Cepen-dant,
nous avons constaté que malgré les bienfaits de ces approches, chacune d’en-
54

3.4 Conclusion
tre elles détient des points faibles remarquables. Par la suite nous allons discuté
les avantages et les inconvénients de chaque méthode.
– Dans le travail [Thakar and Dagdee, 2010] , on propose un système à base
de honeypot pour la détection des attaques contre les web services. Ce système
est une amélioration des approches de signatures en ajoutant un aspect de
détection d’anomalie (classificateur SVM).
– L’inconvénient majeur de ce honeypot est le fait qu’il n’est pas déployé dans
un environnement réel, il se base juste sur la simulation, et ne traite pas les
attaques en temps réel.
– Dans leurs travail [Choi, 2011], les auteurs proposent un système pour sécuri-sation
des applications web contre les attaques XSS et Injection SQL en util-isant
les n-grammes et le classificateur SVM. Cette approche utilise une ap-proche
probabiliste qui parait efficace pour la détection des attaques ; cepen-dant
elle n’est pas générale ; ne prend pas en considération toutes les attaques ;
et ne prend pas en considération le cas des web services.
– Les travaux de [Amitab, 2011] et [Oza, 2013] proposent l’utilisation de la
distance de Khi-2 à fin de détecter les attaques injection SQL, et les attaques
HTTP. L’utilisation de cette distance était efficace.
3.4 Conclusion
Un pare-feu XML peut être considéré comme un moyen de sécurité contre les
attaques basées sur XML, en examinant le contenu des messages SOAP, pour
distinguer entre le contenu autorisé et le non autorisé. Plusieurs recherches ont été
effectués afin d’améliorer ces pare-feu.
On a distingué deux mécanismes de sécurité :
– La technique utilisant les signatures qui est facile à implémenter et config-urer
et maintenir par la suite, elle donne de bonnes résultats de protection,
malheureusement un XML firewall basé sur cette technique est réactif et ne
s’adapte pas avec les nouvelles attaques.
– La technique probabiliste utilisant les techniques du data mining ( distances
et similarités entre chaînes de caractères) et qui est en revanche active, les
problèmes avec cette technique résident dans le taux des faux positifs ( rejet à
tord) et faux négatifs (acceptation à tord) qui peuvent s’accroire et diminuer
les performances du firewall.
Quelques approches ont été proposées, et qui donnent des résultats plus ou moins
acceptables. Nous avons constaté que les approches utilisant la distance de Khi-2
et les n-grammes donnent de meilleurs résultats.
Pour cela nous avons décidé d’adopter la distance ² et les n-grammes dans notre
solution pour la sécurisation des web services contre les attaques par injection.
55

Conception
« Il ya deux façons de faire la
conception d’un logiciel. Une
façon est de le rendre si
simple qu’il n’y a selon toute
apparence aucun défaut. Et
l’autre est de le faire si
compliqué qu’il n’y a pas de
défaut apparent.. »
(Tony HOARE)

Chapitre 4
Conception
4.1 Introduction
Le but de notre projet est de concevoir et de réaliser un firewall XML pour la
détection et la prévention des attaques par injection sur les web services SOAP.
Les firewalls actuels ne sont pas dotés de méthodes pour protéger les web services
contre ces attaques, d’ou la nécessité d’un firewall XML qui sera une extension du
firewall déjà existant netfilter.
4.2 Les attaques détectées par notre pare-feu
Les web services SOAP sont de plus en plus vulnérable aux attaques de type
injection. Notre Firewall permet la détection des attaques par injection suivantes :
– Injection XPath : Les attaques injection XPath se produisent lorsqu’un un
site Web utilise les informations fournies par l’utilisateur pour interroger des
données XML. En envoyant des informations mal formées volontairement dans
le site Web, un attaquant peut avoir la structure du fichier XML, ou accède
aux données qu’il ne peut pas normalement en avoir accès.
– Injection XML : Les injections XML sont utilisées pour manipuler un fichier
XML, Le but de cette attaque est d’envoyer au serveur des données en ren-trant
par exemple, des informations d’identification contenant des caractères
spéciaux, qui pourrait ne pas être prisent en charge par l’application.
– Injection SQL : Les injections SQL consistent en injection de commandes
SQL via les données entrées par l’utilisateur. Un exploit de type injection SQL
réussie, peut avoir des accès à des données non-autorisées, ou même extraire
le schéma de la base de données.
– Injection de commandes OS : une attaque de type injection de commande
59

Chapitre 4 Conception
OS se produit lorsqu’un attaquant tente d’exécuter des commandes au niveau
du système par le biais d’une application vulnérable.
Dans notre approche, on va procéder par une comparaison entre chaîne de carac-tères
en utilisant les n-grammes de caractères et le Test du2.
4.3 Architecture globale de notre firewall
L’architecture de notre Firewall contient deux parties, une d’administration ou
l’administrateur peut créer un profil du web service en question, comme il peut
visualiser le log (le journal) des attaques. Et la partie de protection qui s’occupe
de la sécurisation en temps réel. La figure 4.3.1 montre l’Architecure globale de
notre pare-feu XML
Figure 4.3.1 : Architecure globale pare-feu XML
4.4 Le noyeau d’administration
L’interface d’administration offre à l’administrateur les options suivantes (voir
figure 4.4.2) :
– Création de profil de web service ou modification d’un profil web service ex-istant.
– Visualisation du journal des évènements ; il peut aussi visualiser les paquets
entrant en temps réel.
60

– Modification de la configuration du noyeau de protection (taille des n-grammes,
seuil de détection ...etc.)
– Bloquer/Autoriser une requête malveillante avec justification en cas d’autori-sation.
Pour pouvoir réaliser ces tâches, l’administrateur doit tout d’abord s’authentifier
avec son nom d’utilisateur et mot de passe UNIX.
4.4.1 Création/Mise-à-jour d’un profil web service
4.4.1.1 Création d’un profil web service
L’administrateur peut ajouter un web service en lui créant un profil Web Service
(profilWS).
4.4.1.1.1 Profil Web Service
Un web service est caractérisé par :
– Nom du web service.
– URL de son fichier WSDL.
– La liste de ses bons messages.
– Le vecteur des n-grammes moyen.
La figure 4.4.1 montre les profils des web services :
61

Figure 4.4.1 : Profils des web services
62

Lors de la création d’un profil de web service l’administrateur fournit comme
entrée le nom du web service ainsi que l’URL de son fichier de description WSDL.
L’obtention de l’URL du fichier WSDL permet l’extraction ; à partir du log du
serveur http où le web service est déployé ; les messages SOAP autorisés qui seront
utilisées par la suite pour la protection.
Figure 4.4.2 : Ajouter un web service
Lorsqu’on ajoute un web service le gestionnaire vérifie la présence du web service
et essaye de parser les logs des requêtes à fin d’extraire les bons messages SOAP.
Une fois trouvée on procéde à la création du profil web service.
Gestionnaire des profils web services
Le Gestionnaire valide l’existence du web service en vérifiant l’existence du fichier
WSDL sur le serveur http. On a vu que le schéma d’ajout de web services était le
suivant (figure 4.4.3) :
63

Figure 4.4.3 : mécanisme d’ajout d’un web service
Le gestionnaire de profils web service vérifier l’existance du web service en es-sayant
d’extraire ses méthodes en parsant le fichier WSDL. Ceci permet ;par la
suite ; la récupération des requêtes autorisées depuis le log du serveur http.
Parser du fichier WSDL
Le parser permet l’extraction des différents possibles messages SOAP que peu-vent
envoyer au service web ses clients. Le schéma d’un tel parser est décrit par
Figure 4.4.4 :
Figure 4.4.4 : Parser du fichier WSDL
64

Les templates de messsages SOAP seront utilisées par la suite pour l’acquisition
des requêtes autorisées depuis le serveur http du web service.
Acquisiteur de messages autorisés pour le web service
Une fois on a les templates des messages SOAP, on procédera à l’acquisition des
bons messages de notre web service, cette liste sera mise à jour par la suite dans
la phase de protection chaque fois qu’un message SOAP autorisé est intércépté.
On admet que le serveur hébérgeant le web service ne contient dans son log que
des bons messages, généralement ceux testés par le développeur du web service.
Le schéma de ce module est décrit comme suit Figure 4.4.5 :
Figure 4.4.5 : Acquisiteur de requêtes autorisées
Caclul des n-grammes et vecteur moyen de n-grammes
Une fois la liste des requêtes est obtenue on procéde au calcul des différents
n-grammes pour chaque message SOAP. Rappelons qu’un n-gramme est une sous-séquence
de n éléments construite à partir d’une séquence donnée.
On extrait à partir de chaque message autorisé tous les n-grammes de caractères
possibles. Pour chaque n-grammes on calcule sa fréquence qui est normalisée par
la taille du message SOAP et on crée un vecteur de fréquence de n-grammes.
Nota qu’on aura ; théoriquement ; (256)n cas possibles de n-grammes ( 256 le
nombre de caractères possibles selon l’encodage ASCII) pour chaque message
SOAP.
Nous avons constaté que le nombre maximum des n-grammes possible i.e. (256)n
ne sera jamais atteint ; donc on ne va présenter que les n-grammes présents.
65

Figure 4.4.6 : Extraction des n-grammes et de tableau de fréquences des n-grammes
Une fois les fréquences des n-grammes sont calculées pour chaque message, on
calcule le vecteur moyen ; par une moyenne arithmétique ; qui va présenter une
image globale de toutes les requêtes autorisées.
Figure 4.4.7 : Vecteur moyen des fréquences de n-grammes
Le vecteur moyen calculé sera utilisé par la suite pour la détéction, chaque
message intércépté subira un calcul de fréquence des n-grammes et il sera comparé
à ce vecteur moyen.
D’après cela, on conclut que notre gestionnaire de profils de web services contient
les modules suivants :
– Parser du fichier WSDL.
– Acquisiteur des bons messages (autorisés).
66

4.5 Le noyeau de protection
– Extracteur des n-grammes.
4.4.1.2 Modification de profil du web service
Il arrive parfois qu’on désire modifier le profil du web service, notre système
le permettra. L’administrateur peut modifier le nom du web service, ou bien le
chemin du fichier WSDL si ceci a été remplacé pour une raison ou une autre.
Une fois que les champs à mettre à jour sont entrés par l’administrateur, une
mise à jour des champs du profil de web service (nom , URL , liste des messages
autorisés) sera lancée si nécessaire (voir schéma figure 4.4.8).
Figure 4.4.8 : Processus de modification d’un profil web service
La partie la plus importante dans notre firewall XML, Il s’agit bien du module
de détection et de prévention d’attaques contre le web service. Nous allons voir en
détail, comment cette partie fonctionne.
L’approche globale de protection consiste à :
1. Intercepter le message SOAP provenant de l’extérieur.
2. Comparer-le avec le dataset (vecteur moyen) créé auparavant par le gestion-naire
de profils web services.
3. Décider si attaque ou non et journaliser l’évènement
a) Si attaque : bloquer-la
b) Sinon : autoriser le message et ajouter-le aux messages autorisés du web
service, mettre à jour le vecteur moyen
4.5.1 Interception du message SOAP
Dans cette étape notre système intercepte les requêtes http qui proviennent, et
vérifie s’il s’agit bien d’un message SOAP.
67

4.5.2 Extraction des n-grammes et de la table de fréquences
Une fois le message est intercepté on extrait ses n-grammes et on génére la table
de fréquence des n-grammes correspondante à ce message, ceci est analogue à ce
qu’on a fait dans le noyeau d’administration lors la création du profilWs.
4.5.3 Calcul de la distance Khi-2
Rappelons que la distance de khi-2 est donnée par la formule :
Algorithme 4.1 Distance de Khi-2
D2(O,E)=PNi
=1
(Oi−Ei)2
Ei
Dans ce cas, le vecteur de résultat attendu E sera le vecteur de fréquences n-grammes
moyen et le vecteur observé O sera le vecteur de fréquences n-grammes
de requête interceptée. Le degré de liberté est N - 1
avec N = Taille du vecteur moyen = taille du vecteur des n-grammes ; qui n’est
rien d’autre que le cardinal de l’ensemble union des deux ensembles.
Ici trois cas de figures qui apparaissent :
1. 1er cas : le n-gramme x apparaît dans les deux vecteur donc pour ce n-gramme
la formule sera : (Ox −Ex)2
Ex
2. 2éme cas : le n-gramme x apparaît dans le vecteur moyen (celui des bons
messages) alors la formule sera :(Ox −Ex)2
Ex
avec Ox= 0
3. 3éme cas : le n-gramme x apparaît dans le vecteur observé (celui dela requête
en entrée) alors la formule sera : (Ox −min)2
min avec min = MIN(E) ( la valeur
minimale dans les vecteur moyen) (ceci est fait pour éviter la division par
0).
Cette distance D² sera comparée à la valeur de la table de khi-2 2(seuil ; N-
1). Si D² 2(seuil ; N-1) le message est considéré comme malveillant, on accepte
l’hypothèse nulle H0, sinon on rejette l’hypothèse nulle et le message sera considéré
comme bon.
L’organigramme de détection des attaques est le suivant (figure 4.5.1).
68

Figure 4.5.1 : Schéma de décision de malveillance ou pas du message
69

Une fois le message est classifié, il sera journalisé (ajouté au journal des évène-ments).
Si le message est autorisé alors il sera transféré au web service. Le vecteur
ne sera mis-à-jour que si l’administrateur ajoute le message autorisé manuellement,
on évite l’ajout automatique et la mise-à-jour automatique du vecteur moyen afin
d’éviter l’augmentation du tôt des faux négatifs.
S’il s’agit bien d’une attaque elle sera bloquée et journalisée dans le journal des
attaques ainsi que son type.
Afin de détecter le type d’attaque, on utilise un vecteur d’attaques contenant
les différents types d’attaques et leurs chaînes malveillantes, un tel vecteur est
disponible et téléchargeable depuis le net.
Voici l’algorithme de la distance de 2
Algorithme 4.2 Distance 2
Fonction DistanceKhi2(vectObservé, vectMoyen : tableau) :booléen :
variables :
| d : entier ; // distance
| ddl : entier ; // degré de liberté
Début :
| d 0 ;
| ddl NEC(vectObservé,vectMoyen)+NENC(vectObservé,vectMoyen)-1 ;
| // NEC = Nombre d’Elements Communs
| // NENC = Nombre d’Elements Non Communs
| minimum = min(vectMoyen) ; // la fréquence minimale dans le vecteur moyen
| POUR CHAQUE ngramme ng DANS vectObservé FAIRE :
| | SI existe(vectMoyen,ng) ALORS :
| | | d = d +(vectObservé[ng] - vectMoyen[ng])2 / vectMoyen[ng]
| | SINON :
| | | d = d +(vectObservé[ng] - minimum)2 / minimum
| | FINSI
| FINPOUR
| POUR CHAQUE ngramme ng DANS vectMoyen FAIRE :
| | SI NON (existe(vectObservé,ng)) ALORS :
| | | d = d +vectMoyen[ng]
| | | // une simplification de formule
| | FSI
| FINPOUR
| RENVOYER Khi2(d,ddl) seuil
FIN
70

4.6 Fichier de configuration
4.6 Fichier de configuration
L’administrateur peut configurer le firewall en modifiant la taille des n-grammes
utilisée, la distance utilisée et le seuil de détection. nota que ces derniés sont
configurés à des valeurs par-défaut ( 3-grammes, Khi-2 et 0.05 comme seuil).
Figure 4.6.1 : Structure du fichier de configuration
4.7 Journal des évènements (log)
Il est clair que notre parefeu fonctionne même à l’absence de l’administrateur,
avoir un journal des évènements est primordial, grâce à ce log, l’administrateur
pourra savoir quels sont les attaques signalées et en général quels sont les requêtes
envoyées au web service.
Dans notre architecture, on propose deux fichiers logs, un général et un autre
d’attaques bloquées :
– Un fichier journal n’est rien d’autre qu’un simple fichier texte dont chaque
ligne est un évènement journalisé.
– Un fichier journal d’attque ne contient que les requêtes malveillantes ainsi que
le type d’attaque signalée.
Voici en figures 4.7.1 et 4.7.2 les structures des fichiers logs.
71

Figure 4.7.1 : Structure d’un fichier journal
Figure 4.7.2 : Structure d’un fichier journal d’attaques
72

4.7 Journal des évènements (log)
4.7.1 Visualisation et suppression du journal
L’administrateur peut visualiser à tout moment le journal des événements ainsi
le supprimer comme le montre la figure 4.7.3 à travers l’interface figure 4.7.4.
Figure 4.7.3 : Visualisation et suppression du journal
73

Figure 4.7.4 : Exemple d’un fichier Journal (log)
74

4.8 Algorithme de protection
4.8 Algorithme de protection
Comme nous avions vu précédemment, on constate que l’algorithme de notre
firewall est le suivant :
Algorithme 4.3 Algorithme de protection
ALGORITHME Protection
| VARIABLES
| message : MessageSOAP
| vecteurMoyen : Tableau
| decision : booléen
| DEBUT
| | TANT QUE (Vrai)
| | | IntercepterMessage(message) ;
| | | Appel(fréquencesNGrammes(message)) ;
| | | // récupérer le vecteur moyen déjà sauvegardé
| | | vecteurMoyen = Appel(VecteurMoyen()) ;
| | | decision = KhiDeux(message,vecteurMoyen,seuil)
| | | SI (decision)
| | | | transférerLePaquet(message) ;
| | | | AjouterAuJournal(date.now(),date.now().time(),message) ;
| | | SINON
| | | | bloquerAttaque() ;
| | | | AjouterAuJournal(date.now(),date.now().time(),message) ;
| | | | AjouterAuJournal(date.now(),date.now().time(),message,typeAttaque(message)) ;
| | | FINSI
| | FINTANQUE
| FIN
4.9 Etude de cas
Nous allons tester notre firewall XML sur le web service « Users » permettant :
l’authentification des utilisateurs, ajouter des informations personnelles, tester un
« ping » d’un site web ou une adresse IP.
Nous verrons ainsi toutes les étapes de sécurisation de ce web service, en com-mençant
par la phase d’apprentissage ( génération du vecteur moyen) jusqu’à un
scénario d’attaque.
75

4.9.1 Les méthodes de notre service web
– Login : Permet aux clients de s’authentifier, leurs login et mots de passe sont
stockées sur une base de données MySQL.
– Subscribe : Permet aux utilisateurs d’ajouter leurs informations personnelles.
Ces derniers sont stockées dans un fichier XML.
– Search : Permet de rechercher les informations personnelles d’un utilisateur à
partir du fichier XML des utilisateurs.
– Ping : Permet de tester la commande « ping ».
4.9.2 Ajout du web service « Users »
On va ajouter notre web service à la liste des wb services sécurisés par notre
pare-feu, on va donc lui créer un profil.
4.9.2.1 Profil du web service
– Nom : Users
– URL du fichier WSDL : http ://127.0.0.1 :8087 ?wsdl
4.9.2.2 Extraction des méthodes
– Login (username :string,password :string) :string
– Subscribe(Matricule :string,NomPrenom :string,...) :void
– Search(item :string) :string
– Ping(host :string) :string
4.9.2.3 Récupération du log
On récupére la log http de la méthode Login. Nous avions en total 1000 enreg-istrements.
Les logins enregistrés sont :
– Login(zsmahi, zsmahi)
– Login(user, password)
– Login(zakaria, monMotDePasse)
– Login(ABENHAIM, 8accruement)
– ... etc.
4.9.2.4 Extraction des n-grammes et génération du vecteur moyen
4.9.2.4.1 Extraction des n-grammes
Appel au module d’extraction des n-grammes :
ngramme(’loginnusernamezsmahi/usernamenpasswordzsmahi
76

4.9 Etude de cas
/passwordn/ login’, 3)
– nombre de ngrammes uniques : 43
– quelques ngrammes et leurs fréquences (USE :2 ; WOR :2 ; PA :1 ...etc.)
4.9.2.4.2 Construction du vecteur moyen
Après l’extraction des n-grammes on procède par la création du vecteur moyen
qui regroupe tous les n-grammes de la phase d’apprentissage. La taille du vecteur
construit est : 9482 éléments.
4.9.3 Scénarios d’attaques
Nous allons présenter un ensemble de scénarios d’attaques, à partir desquels
nous allons montrer les vulnérabilités du Web Service concerné, et expliquer le
déroulement du processus de détection des attaques proposé dans notre système.
4.9.3.1 Injection SQL
On essayera d’injecter un code SQL malveillant afin de récupérer les noms et
mots de passes des utilisateurs.
soapenv :Envelope xmlns :soapenv=http ://schemas.xmlsoap.org/soap/envelope/
xmlns :pub=http ://publisher.mywebservice.org/
soapenv :Header/
soapenv :Body
Login
username’ OR 1 = 1 – /username
password/password
/Login
/soapenv :Body
/soapenv :Envelope
Table 4.1 : Attaque Injection SQL
4.9.3.2 Injection XPath
On va insérer un code XPath qui rend la requête XPath malveillante.
77

soapenv :Header/
soapenv :Body
Search
itemzsmahi’ or ’1’ =’1/item
/Search
/soapenv :Body
/soapenv :Envelope
Table 4.2 : Attaque Injection XPath
4.9.3.3 Injection XML
Dans cette attaque on va essayer d’insérer du code XML qui sera intérprété
prochainement par les parsers XML et générant des erreurs au niveau du fichier
XML.
soapenv :Header/
soapenv :Body
Subscribe
Matriculexi :include href=file :///etc/passwd parse=text//Matricule
NomPrenomJordan Fox/NomPrenom
DateDeNaissance13/02/88/DateDeNaissance
LieuDeNaissanceLeut/LieuDeNaissance
AdresseAppartement 844-3869 Ante Av./Adresse
Tel0-975-789-352/Tel
/Subscribe
/soapenv :Body
/soapenv :Envelope
Table 4.3 : Attaque Injection XML
78

4.9 Etude de cas
4.9.3.4 Injection de commandes OS
Dans la méthode Ping, l’utilisateur fournit comme paramêtre l’adresse IP de
l’hôte à scanner, on va passer une autre commande avec cette adresse.
soapenv :Header/
soapenv :Body
Ping
host127.0.0.1 ; cat /etc/passwd/host
/Ping
/soapenv :Body
/soapenv :Envelope
Table 4.4 : Attaque Injection de commandes OS
4.9.3.5 Tester une attaque
On va tester l’injection SQL sur la méthode Login. On intércepte le message
Tableau 4.1.
4.9.3.5.1 Extraction des n-grammes du messages
Appel au module d’extraction des n-grammes :
ngmal = ngramme(Tableau 4.1, 3)
– nombre de ngrammes uniques : 51
– quelques ngrammes et leurs fréquences (ERN :2 ; ’ OR’ :1 ; ...etc.)
4.9.3.5.2 Calcul de la distance Khi2
Appel au module khi2 :
chisquare(vecteurMoyen,ngmal)
– Degré de liberté : 9538
– Distance De Khi2 : 40086.39759125321
– Probabilité de Khi2 : 0.0000000001
On remarque que la probabilité est inférieure au seuil choisi 0.05 [Greenwood, 1996]
donc le message sera considéré comme malveillant. Comme le message contient la
chaîne « ’ OR 1=1 – » donc il s’agit d’une injection SQL. Ce message sera journalisé
dans les deux fichiers journal et journal des attaques.
79

4.9.4 Scénario un bon message
On va tester cette fois-ci le message suivant Login(zsmahi,zsmahi) qui est bon,
comme on a procédé précedemment on lui extrait ces n-grammes, et on calcule la
distance de Khi2.
– Degré de liberté : 9523
– Distance De Khi2 : 16795.8930622712
– Probabilité de Khi2 : 0.07
On remarque que la probabilité est supérieure au seuil choisi 0.05 donc le message
sera considéré comme bon. Il sera journalisé dans le fichier journal.
4.10 Conclusion
Dans ce chapitre, nous avons conçu l’architecture de notre firewall XML, qui
utilise les n-grammes et la distance de Khi-2 pour la détection des attaques par in-jection
sur les web services. Nous avons détaillé son architecture modulaire (noyeau
de protection et noyeau d’administration).
Le noyeau d’administration permet de définir les différentes configurations (
profils web services, taille n-grammes , ...etc.) qui seront utilisées par la suite par
le noyeau de protection dans la phase de sécurisation.
Une telle approche permet la détection des attaques par injection sur les web
services, mais sa n’empêche pas d’avoir des faux positifs ou de faux négatifs.
Le calcul du taux de ces faux-positifs ainsi que les faux-négatifs sera l’objet des
chapitres suivants réalisation et tests.
80

Réalisation et Tests
« Talk is cheap. Show me the
code. »
(Linus Torvalds)

Chapitre 5
Réalisation
5.1 Introduction
Après avoir décrit la conception de notre système, nous allons passer dans cette
dernière partie à sa réalisation. Nous allons présenter tout d’abord, l’environnement
et les outils que nous avons utilisé, ensuite nous verrons les étapes par lesquelles
nous nous sommes passées dans le processus de détection des attaques d’injections.
5.2 Système d’exploitation
Linux a été créé à l’origine par Linus Torvalds, au début des années 1991, comme
une alternative libre et gratuite aux noyaux pour les systèmes d’exploitation de
type Unix existant à l’époque. Dès le début, il fut conçu comme un système multi-tâche
et multiutilisateur. Ces caractéristiques suffisent à distinguer Linux d’autres
systèmes bien connus.
il est bon de noter que Linux n’est pas un système d’exploitation en lui-même
mais un noyau (ou kernel). Il devient système d’exploitation lorsqu’il est accom-pagné
de GNU et des applications qui s’y greffent. Cet ensemble est appelé une
distribution. Ce n’est que par abus de langage, qu’on utilise maintenant le terme
« Linux » pour parler de « Gnu-Linux » [Stallman, 1997].
Figure 5.2.1 : Système Linux
83

Chapitre 5 Réalisation
Ubuntu est une distribution linux libre [Fischer, 2007] commanditée par la
société Canonical et une marque déposée par cette même société. Fondé sur la dis-tribution
Linux Debian, ce système d’exploitation est constitué de logiciels libres,
et est disponible gratuitement, y compris pour les entreprises, selon un principe
lié à la philosophie affichée du projet.
Figure 5.2.2 : Logo de la distribution ubuntu
5.3 Environnement de développement
Pour créer le Web Service, nous avons utilisé : JavaEE et Mysql sous l’environ-nement
de développement Eclipse JEE Kepler et apache tomcat7/Axis2 pour son
déploiement. Par ailleurs nous avons utilisé : Python et SOAPUI pour développer
le système de protection.
5.3.1 Python
Python est un langage portable, dynamique, extensible, gratuit, qui permet (sans
l’imposer) une approche modulaire et orientée objet de la programmation. Python
est developpé depuis 1989 par Guido van Rossum et de nombreux contributeurs
bénévoles [Swinnen, 2012].
Le langage Python est placé sous une licence libre (PSF -Python Software
Foundation- license) [Van Rossum, 2007] proche de la licence BSD et fonctionne
sur la plupart des plates-formes informatiques, des supercalculateurs aux ordina-teurs
centraux, de Windows à Unix en passant par GNU/Linux, Mac OS, ou encore
Android, iOS, et aussi avec Java ou encore .NET. Il est conçu pour optimiser la
productivité des programmeurs en offrant des outils de haut niveau et une syntaxe
simple à utiliser.
84

5.3 Environnement de développement
Figure 5.3.1 : Langage Python
5.3.2 CGI-BIN
Pour la réalisation de notre solution, nous optons pour une interface web et ce
pour les raisons suivantes :
– Notre solution va être déployé sur un Serveur Linux, souvent ces serveurs ne
disposent pas d’un environnement graphique fenêtré « X Window » (appelé
communement X11).
– Faciliter l’accès aux administrateurs à l’application à distance.
D’où la nécessité d’avoir une application web et non pas desktop. Afin de la réaliser
nous utilisons le CGI.
CGI (Common Gateway Interface) est une interface permettant l’exécution de
programmes externes par un serveur HTTP. Plus généralement, CGI est en fait
un standard pour l’écriture de passerelles entre des serveurs d’informations tel que
HTTP et des programmes externes. L’interface CGI permet de faire communiquer
le programme et le serveur HTTP (voir figure 5.3.2) [Gundavaram, 1996].
Figure 5.3.2 : Principe de fonctionnement du CGI
85

5.3.3 Bootstrap
Bootstrap ou Twitter Bootstrap est une collection d’outils utile à la création de
sites web et applications web [Cochran, 2012]. C’est un ensemble qui contient
des codes HTML et CSS, des formulaires, boutons, outils de navigation et autres
éléments interactifs, ainsi que des extensions JavaScript en option.
Figure 5.3.3 : Twitter Bootstrap
Son avantage est qu’il permet également un gain de temps énorme en proposant
des fondations prédéfinies pour les projets, une normalisation de code en respectant
les standards et des éléments graphiques loin d’etre négligeables. En plus de tout
ceci, Bootstrap permet de faire rapidement et efficacement des structures de sites
en Responsive Web Design, en d’autres termes de prendre en compte et d’adapter
le contenu du site Web aux différents types d’appareils, mobiles ou non.
5.3.4 SoapUI
SOAPUI est un outil graphique qui permet de tester des Web Services basés sur
diverses technologies. Il est disponible en deux versions : open source et payante.
Il est également disponible sous forme de plugin pour les IDE Netbeans, IntelliJ
IDEA et Eclipse [Kankanamge, 2012].
SoapUI est développé entièrement en Java, et utilise Java Swing pour son GUI,
il fonctionne donc sur la plupart des systèmes d’exploitation, et en plus il est
disponible sous la licence GNU LGPL.
L’outil gère respectivement les Web Services basés sur les technologies telles que
le HTTP (S), HTML, SOAP (WSDL), REST, AMF, JDBC et JMS. Il permet de
mettre en place une suite de tests, qui peuvent être lancés du côté client, il permet
de tester les Web Services grâce aux tests de charge.
86

5.4 La Réalisation
Figure 5.3.4 : SoapUI
5.3.5 La bibliothèque NetfilterQueue
La bibliothèque NetfilterQueue est une bibliothèque de développement sous
python qui permit d’intercepter, et de manipuler les paquets qui transitent sur
un réseau. Cette bibliothèque est utilisée conjointement avec le firewall Netfilter
(à travers la commande iptables sous Linux) pour renvoyer les paquets dans l’es-pace
utilisateur. Ainsi, les paquets peuvent être manipulés par un programme.(voir
Annexe C).
5.4 La Réalisation
5.4.1 Diagramme de classes
Afin de faciliter la réalisation de la solution proposée, nous avons établi le dia-gramme
de classes suivant (figure 5.4.1) afin de montrer les principales entités et
les différentes relations entre elles.
87

Figure 5.4.1 : Diagramme de classes de la solution proposée
88

5.4 La Réalisation
5.4.2 Architecture technique du firewall
La figure suivante (figure 5.4.2) montre l’architecture technique de notre pare-feu
XML qui est composée d’une interface d’administration gérée par un administra-teur
et qui permet la supervision de l’état du firewall ainsi la définition de ses règles
et la gestion des profils web services. Le corps du parefeu se charge de l’interception
et l’analyse des messages SOAP et détécter les attaques par injection.
Figure 5.4.2 : Architecture de notre firewall
5.4.3 Noyeau de Protection
Comme nous avons vu précédement, notre pare-feu est constitué de deux noyeaux :
Protection et Administration. Nous détaillons ainsi l’architecture technique du
noyeau de Protection.
Dans la figure suivante (figure 5.4.3) nous montrons un exemple d’un message
SOAP malveillant (injectionSQL) qui sera envoyé au web service (dans ce cas les
client est l’outil SoapUI), comme nous avons détaillé dans la partie conception ce
message sera intercépté et analysé par notre firewall.
89

Figure 5.4.3 : Injection SQL envoyée via l’outil SoapUI
5.4.3.1 Interception
Pour pouvoir intercepter les paquets destinés pour notre réseau LAN, ajoutons
d’abord la règle suivante à IPTABLES :
# iptables -I INPUT -d 192.168.0.0/24 -j NFQUEUE –queue-num 1
Cette règle permet de capturer tous les paquets entrant au réseau 192.168.0.0
et les mettre en queue numéro 1. Cette même queue sera utilisée par notre code
d’interception suivant (en Python) :
90

5.4 La Réalisation
Algorithme 5.1 Code D’interception de messages SOAP
”””
Code D’interception des messages SOAP
”””
__author__ = Zakaria SMAHI
from netfilterqueue import NetfilterQueue
from verification import verifier
def verif(pkt) :
if not (SOAPmessage(pkt.get_payload()) :
#S’il ne s’agit pas d’un message SOAP, on accepte le paquet
pkt.accept()
else :
if verifier(pkt.get_payload()) :
#Appel au module de verification contre les attaques
#Si le paquet est clean on l’accepte
pkt.accept()
else :
#sinon on le bloque
pkt.drop()
#initialisation de la queue
nfqueue = NetfilterQueue()
#liaison avec la queue numero 1 de IPTABLES
nfqueue.bind(1, verif)
#lancement du code
#ce code sera lance tant que l’utilisateur n’a pas
#clique sur la combinaison CTRL+C
try :
nfqueue.run()
except KeyboardInterrupt :
print
91

Ce code permet de récupérer les paquets mis en queue gràce à la règle précédente.
Le code reste à l’écoute et intercepte les messages tant que on n’a pas clique sur
la combinaison CTRL+C (signal stop).
Remarque : on évite d’utiliser la boucle infinie while true afin d’éviter les in-terblocages
au niveau de réception de paquets.
5.4.3.2 Vérification
Dans ce module on fait appel à la logique de sécurisation (distance de ²).
Algorithme 5.2 Code De vérification du message SOAP
”””
Code De verification du message SOAP
”””
__author__ = Zakaria SMAHI
from ngram import ngram
from chisquare import chisquare
def verifier(message) :
#appel au module d’extraction de n-grammes
#on extrait les 3-grammes a partir du message
ng = ngram(message,3)
#appel au module de calcul de distance khi2
#dc est la distance khi2
#pc est la probabilité khi2
dc,pc = chisquare(ng,vecteurMoyen)
return float(pc) = 0.05
Ce code permet la vérification du message SOAP s’il est bon ou malveillant,
lorsqu’il est bon (i.e probabilité de Khi2 = 0.05) la fonction retourne vrai sinon
faux.
5.4.4 Noyeau d’Administration
Le noyeau d’administration comme vu dans la partie conception est le panneau
d’administration du pare-feu XML. On présente ici les interfaces des différents
rôles d’administrateur.
92

5.4 La Réalisation
5.4.4.1 Interface Login Panneau d’administration
L’administrateur fournit le nom d’utilisateur et le mot de passe pour s’authen-tifier
comme le montre la figure suivante (figure 5.4.4).
Figure 5.4.4 : Interface d’authentification
5.4.4.2 Interface globale du Panneau d’administration
La figure suivante (figure 5.4.5) montre bien l’interface globale de notre panneau
d’administration et sa page d’acceuil après l’authentification
93

Figure 5.4.5 : Interface globale du Panneau d’administration
5.4.4.3 Interface Profils des web services
La partie la plus importante de notre panneau d’administration est l’interface
des profils des web services (figure 5.4.6), c’est à ce niveau que l’administrateur
peut ajouter, modifier ou même supprimer un profil d’un web service.
94

5.4 La Réalisation
Figure 5.4.6 : Interface des Profils des Web Services
5.4.4.4 Interface de Configuration
L’administrateur peut modifier la configuration du firewall ou la restaurer au
valeurs par défaut (figure 5.4.7).
95

Figure 5.4.7 : Interface configuration du firewall
5.4.4.5 Interface Journal des évènements
L’administrateur peut visualiser le journal des évènements et le journal des at-taques
détectées ainsi le vider (figure 5.4.8).
96

5.5 Conclusion
Figure 5.4.8 : Journal des attaques détectées
5.5 Conclusion
Dans cette partie nous avons présenté les détails de l’implémentation et la mise
en oeuvre de notre système dans ses deux grands modules (protection et adminis-tration),
ainsi les différentes technologies utilisées pour le développer.
Dans la partie de protection, nous avons pu gràce à la bibliothèque netfilterqueue
et IPTABLES créer un système de sécurisation qui fonctionne en mode continu, et
qui intércepte tous les messages SOAP et les analyse. Quant à la partie d’admin-istration,
nous avons pu réalisé un panneau d’administration facile à manipuler,
inspiré de panneaux d’administration existants et les simplifiant aussi. Notre sys-tème
gràce à un certain nombre de controleurs facilite la tâche de l’administrateur
et le guide pour gérer ce système.
Dans le chapitre suivant nous allons présenter les différents tests effectués, leurs
résultats ainsi que notre propre interprétation.
97

Chapitre 6
Tests et Résultats
6.1 Introduction
Dans ce chapitre nous allons présenter les différents tests effectués afin d’évaluer
les performances de notre firewall. Nous allons présenter en premier lieu les données
utilisées ainsi que et les mesures de perfomances. Ensuite nous allons présenter
les différents résultats obtenus. Nous terminons par des interprétations et une
synthèse.
6.2 L’ensemble de données utilisées pour la
construction du vecteur moyen
Nous allons choisir un échantillon représentatif, qui ne contient que des bons
messages, ensuite nous allons varier la taille de cet échantillon, pour voir l’influence
de la taille de l’échantillon sur la detection. Ces données sont aussi appelées données
d’apprentissage.
Rappelons que nous avons déployé un web service (Users) (voir partie Etude de
cas chapitre4 conception) qui offre plusieurs méthodes. Nous avons effectué nos
tests sur deux méthodes :
– Méthode login(username :string,password :string) :string : authentifier un
utilisateur du web service enregistré dans une base de données MySQL.
– Méthode subscribe(Matricule :string,NomPrenom :string,...) :void : pour
permettre aux utilisateurs de s’inscrire, les données des utilisateurs sont en-registrées
dans un fichier XML.
Afin de pouvoir effectuer nos tests, nous avons utilisé des échantillons générés en
utilisant des bases de tests disponibles sur le net de [briandunning, 2005] et le
script libre de generatedata [genratedata, 2012].
99

Chapitre 6 Tests et Résultats
Ces échantillons ont été utilisé pour générer les paires (nom d’utilisateur, mot
de passe) pour la méthode login et les informations personnelles des utilisateurs
dans la méthode subscribe.
Les messages malveillants ont été générés en utilisant ces échantillons et un
certain nombre de vecteurs d’attaques (chaînes malveillantes) (voir Annexe D). Le
type des attaques ainsi que leurs nombres utilisées sont détaillés plus loin dans la
section résultats des expérimentations .
Voici les différents tailles dec échantillons d’apprentissage utilisés :
Echantillon d’Apprentissage 1000 5000 10000
Table 6.1 : Les différentes tailles d’échantillons d’apprentissage utilisés
6.2.1 Mesures d’évaluations utilisées
Nous avons utilisé deux mesures d’évaluations : le taux de faux positifs et
le taux de faux négatifs afin d’évaluer les performances de notre système de
protection.
– Taux de Faux Positifs F.P : c’est le taux d’instances identifiés à tort comme
«malveillant».
– Taux de Faux Négatifs F.N : c’est le taux d’instances « malveillant »
identifiés à tort comme «bon».
Ces deux mesures ont été représentés sous les deux formes suivantes :
– Matrice de Confusion
– Courbe de ROC
6.2.1.1 Matrice de confusion
Une matrice de confusion [Kohavi, 1998] contient des informations sur la clas-sification
réelles et prédites effectuées par un système de classification. Les per-formances
de tel système sont souvent mesurés par les données de cette matrice.
Un système de classification sera d’autant meilleur que sa matrice de confusion
s’approchera d’une matrice diagonale.
L’exemple suivant montre une matrice de confusion d’un classficateur binaire :
100

6.2 L’ensemble de données utilisées pour la construction du vecteur moyen
Classe Estimée
normal pourriel
Classe normal a b
Réelle pourriel c d
Table 6.2 : Exemple matrice de confusion
– a : le nombre de vrai positif (VP).
– b : le nombre de faux positif (FP).
– c : le nombre de faux négatif (FN).
– d : le nombre de vrai négatif (VN).
D’après cette matrice, plusieurs formules peuvent être extraites ; on se limite à
deux formules qui sont la spécificité et la senibilité.
– La spécificité : mesure la capacité d’un test à donner un résultat négatif
V N +FP .
lorsque l’hypothèse n’est pas vérifiée. Elle est donnée par : V N
– La sensibilité : mesure la capacité d’un test à donner un résultat positif
lorsqu’une hypothèse est vérifiée. Elle est donnée par : V P
V P +FN .
Ces deux mesures sont utilisées pour tracer la courbe de ROC.
6.2.1.2 Courbe de ROC
La courbe ROC (Receiver Operating Characteristic) est une représentation
graphique de la relation existante entre la sensibilité et la spécificité d’un test,
calculée pour toutes les valeurs seuils possibles. Elle permet la détermination et la
comparaison des performances diagnostiques de plusieurs tests à l’aide de l’évalu-ation
des aires sous la courbe. La courbe de ROC se dessine à partir de la matrice
de confusion en calculant la sensibilité et la quantité ( 1 - spécificité). L’ordonnée
représente la sensiblité et l’abscisse la quantité (1-spécificité) [Delacour, 2005].
Pour pouvoir décider si un classificateur est bon ou mauvais, on utilise la notion
de l’aire sous la courbe de ROC (appelée aussi AUC : Area Under Curve)[Hanley, 1982].
Plus cette aire est grande, plus la courbe s’écarte de la ligne du classificateur aléa-toire
et se rapproche du coude du classificateur idéal (qui passe de (0, 0) à (0, 1)
à (1, 1)).
L’AUC peut se calculer par l’intégrale de la fonction de la courbe ROC sous
l’intervale[0 1] en utilisant la fameuse formule de trapèze décrite comme suit :
bf(x) (b − a)f(b)+f(a)
a
2 sous l’intervalle[0 1].
101

6.3 La configuration de la plateforme des tests
Pour tester notre solution, nous avons préparé un environnement de test ( un
réseau LAN) qui se compose d’un switch/router, 3 machines réelles et une virtuelle,
les machines réelles sont celles des clients (client normal et client attaquant) et le
firewall, la machine virtuelle contient le web service Users.
Caractéristique de la machine firewall :
– CPU :Intel® Core™ i3 CPU M 370 @ 2.40GHz × 4
– RAM : 4Go
Voici la configuration de notre réseau LAN utilisée pour les tests (figure 6.3.1) :
Figure 6.3.1 : Configuration du réseau LAN utilisée pour les tests
6.4 Résultats des expérimentations
Dans cette partie, nous allons présenter les résultats des tests effectués, à savoir :
– la taille et le temps de generation du vecteur moyen ( temps d’apprentissage
)
– le taux de faux positif , le taux de faux négatifs , la matrice de confusion et
le temps moyen du traitement des messages.
– la courbe ROC ainsi que l’AUC.
Touts les tests sont effectués avec un seuil de 0.05 et pour les valeurs de n-gramme
2 , 3, 4 et 5.
6.4.1 Méthode Login
Pour effectuer les tests nous avons utilisé 500 messages dont :
102

– 200 malveillants : dont 170 injections SQL et 30 injections de commandes
systèmes.
– 300 bon messages : 150 figurent déjà dans l’échantillon d’apprentissage, et 150
nouveaux (ne figurent pas dans l’échantillon d’apprentissage).
6.4.1.1 Test 1 : 1000 messages
Taille n-gramme Taille Vecteur Moyen T.G Vecteur moyen (sec)
N=2 1949 26.6578671932
N=3 9642 80.91
N=4 17926 139.71
N=5 22721 176.08
Table 6.3 : Taille et Temps Génération du Vecteur moyen cas 1000 messages
Taille F.P F.N Matrice Spécificité Sensibilité T.M
n-gramme De Confusion Detection (sec)

N=2 5 0
295 5
0 200
!
0,97561 1 0.01994
N=3 12 7

288 12
7 193
!
0,94146 0,97627119 0.11922
N=4 44 9

256 44
9 191
!
0,81277 0,96603774 0.26632
N=5 68 12

232 68
12 188
!
0,73438 0,95081967 0.37032
Table 6.4 : Taux de F.Ps et F.Ns, T.M de détection cas 1000 messages
AUC
0.98667
0.92473
0.74727
0.65685
Table 6.5 : AUC méthode login cas 1000 messages
103

Figure 6.4.1 : Graphe de variations de FP et FN cas 1000 messages
Figure 6.4.2 : Courbe de ROC pour la méthode login cas 1000 messages
104

N=2 2936 137.950116873
N=3 17794 453.323413849
N=4 35314 1049.42596292
N=5 46578 1202.90369391

N=2 3 5
297 3
5 195
!
0,98485 0,98344371 0.03658
N=3 7 18

293 7
18 182
!
0,96296 0,94212219 0.29466
N=4 56 52

244 56
52 148
!
0,72549 0,82432432 0.86566
N=5 81 53

219 81
53 147
!
0,64474 0,80514706 0.889
Table 6.7 : Taux de F.Ps et F.Ns cas 5000 messages
AUC
0.98972
0.93252
0.67725
0.55157
105

106

6.4.1.3 Test 3 : 10000 messages
N=2 2965 261.381808996
N=3 18936 891.2
N=4 41686 2654.62627196
N=5 59865 4262.75661802

N=2 3 5
297 3
5 195
!
0,98485 0,98344371 0.03294
N=3 23 8

277 23
8 192
!
0,89302 0,97192982 0.25186
N=4 76 8

256 76
8 192
!
0,71642 0,96551724 0.7301
N=5 132 20

168 132
20 180
!
0,57692 0,89361702 1.26766
AUC
0.98976
0.80927
0.60690
0.51288
107

108

6.4.2 Méthode Subscribe
Pour effectuer les tests nous avons utilisé 502 messages dont :
– 201 malveillants : dont 78 injections XPath et 123 injections XML
– 301 bon messages : 151 figurent déjà dans l’échantillon d’apprentissage, et 150
nouveaux .
N=2 922 7.94242405891
N=3 6741 74.0461111069
N=4 22535 231.35886097
N=5 37705 836.827261925
N=2 15 13

285 15
13 188
!
0,926108374 0,956521739 0.0205910851756
N=3 23 52

278 23
52 149
!
0,86627907 0,842424242 0.183366533865
N=4 53 104

248 53
9 191
!
0,646666667 0,704545455 0.764462151394
N=5 97 131

204 97
131 70
!
0,419161677 0,608955224 2.24703187251
AUC
0.92427
0.90417
0.75303
0.63911
Table 6.14 : AUC méthode subscribe cas 1000 messages
109

Figure 6.4.8 : Courbe de ROC pour la méthode subscribe cas 1000 messages
110

N=2 1086 84.4723329544
N=3 8530 537.234969139
N=4 39219 3883.45131087
N=5 97168 11486.3602328
N=2 8 13

293 8
13 188
!
0,959183673 0,95751634 0.0210358565737
N=3 16 0

285 16
0 201
!
0,926267281 1 0.220976095618
N=4 24 52

277 24
52 149
!
0,861271676 0,841945289 1.95007968127
N=5 31 102

270 31
102 99
!
0,761538462 0,725806452 15.8371858486
AUC
0.93598
0.94684
0.84514
0.76521
111

112

6.4.2.3 Test 3 : 10000 messages
N=2 1130 164.966710091
N=3 9064 1200.01119804
N=4 46020 10826.568001
N=5 133118 38419.0080411
N=2 5 13

296 5
13 188
!
0,974093264 0,957928803 0.0222310756972
N=3 16 0

285 16
0 201
!
0,926267281 1 0.248207171315
N=4 16 45

285 16
45 156
!
0,906976744 0,863636364 2.43976095618
N=5 11 60

290 11
60 141
!
0,927631579 0,828571429 18.8930822629
AUC
0.95008
0.95017
0.94180
0.84908
113

114

6.5 Discussion et Synthèse
6.5 Discussion et Synthèse
Nous allons dans cette section discuter et interpréter les résultats des tests
obtenus précédemment, nous synthétisons ces résultats à la fin pour proposer la
meilleure configuration de notre pare-feu.
6.5.1 Discussion
Rappelons qu’on a pris comme seuil de décision 0.05, ce seuil indique qu’on
accepte l’hypothèse nulle H0 avec un pourcentage de 5% [Greenwood, 1996].
6.5.1.1 Taille du vecteur moyen
D’après les tableaux 6.3, 6.6 et 6.9 pour la méthode « Login » et les tableaux
6.12, 6.15 et 6.18 pour la méthode « Subscribe », nous constatons que varier la
taille du n-gramme influe sur la taille du vecteur moyen, celle-ci augmente si on
augmente la taille du n-gramme. Ceci est dû au fait que le nombre de n-grammes
uniques augmente lorsqu’on augmente la taille du n-gramme.
La taille du vecteur moyen augmente aussi lorsqu’on augmente la taille de
l’échantillon d’apprentissage et ce pour chaque n (n allant de 2 à 5) augmen-tation
de 9642 à 18936 pour n=3 pour la méthode « login » et de 6741 à 9064 pour
la méthode « subscribe ».
6.5.1.2 Temps moyen d’execution
Nous avons vu dans la section précédente que le temps d’apprentissage (construc-tion
du vecteur moyen) augmente avec l’augmentation du nombre des messages
ainsi que le nombre des n-grammes uniques (taille du vecteur moyen).
Notons aussi que le temps de détection (vérification) augmente aussi avec l’aug-mentation
de la taille du vecteur moyen puisque il faut le parcourir complet afin
de de calculer la distance Khi-2 .
6.5.1.3 Taux de faux positifs et faux négatifs
Les tableaux 6.4, 6.7 et 6.10 pour la méthode « login », et 6.13, 6.16 et 6.19
pour la méthode « subscribe » indiquent les taux des faux positifs et faux né-gatifs.
D’après ces tableaux on constate que les bigrammes (2-grammes) et les
trigrammes (3-grammes) donnent de meilleurs résultats comparés aux 4-grammes
ou 5-grammes
L’augmentation de l’échantillon du test ; et par la suite le vecteur moyen ; fait
diminuer le taux de faux négatifs : diminution de 104 à 45 pour n=4 dans la
méthode « subscribe ».
115

Les figures 6.4.1, 6.4.3 et 6.4.5 pour la méthode « login » ainsi que les figures
6.4.7, 6.4.9 et 6.4.11 présentent les diagrammes en bâtons des variations de taux de
faux postifis et faux négatifs pour chaque échantillon et pour les différentes tailles
de n-grammes testées.
6.5.1.4 Courbe de ROC
Les tests précédents ont montré l’efficacité de l’utilisation des bi-grammes et tri-grammes
pour la détéction des attaques par injections sur les web services. Après
tracer les courbes de ROC (figures 6.4.2, 6.4.4et 6.4.6 pour la méthode « login »
et figures 6.4.8, 6.4.10et 6.4.12 pour la méthode « subscribe ») et calculer les AUC
de chaque courbe, nous avons obtenu les résultats suivants :
– Pour n = 2 et n = 3 nous avons obtenus une meilleure detection comparées
aux n=4 ou 5, ( AUC2 0.99, AUC3 0.81) pour la méthode login pour
10000 messages et ( AUC2 AUC3 0.95) pour la méthode subscribe pour
10000 messages.
– Pour le n=5 nous remarquons que les résultats ne sont pas bonnes , cela est
dû au faite que lorsque la taille du ngramme augmente la propabilité que les
ngramme d’un message soit présent dans le vecteur moyen est faible ( on va
avoir toujours des nouveaux n-grammes) ; et par conséquent la distance de khi-
2 augmente et la propabilité de rejet augmente . D’autant plus ; la majorité
des attaques par injection ne contiennent que des séquences de catactéres de
petite taille ; ce qui explique les bonnes performances pour le n=2 et n=3 .
6.5.2 Synthèse
L’utilisation de la méthode 2avec les n-grammes donne une bonne détection
des attaques par injection contre les web services.
Nous avons constaté que l’augmentation de l’échantillon d’apprentissage permet
d’augmenter la précision du firewall en réduisant le taux des faux négatifs.
On a constaté aussi d’après les courbes de ROC que l’utilisation du seuil 0.05
et les bigrammes (n=2) et les trigrammes (n=3) donne la meilleure detection.
6.6 Conclusion
Dans cette partie de travail nous avons présenté un plan de test, à partir duquel
nous avons montré et interprété une série des résultats, concernant le fonction-nement
et les performances du firewall XML, dans le but d’avoir une idée subjective
sur le système proposé.
116

6.6 Conclusion
Nous avons pu obtenir un certains nombre de de résultats acceptables suite
aux tests effectués, ces résultats ont été synthétisé par la suite ce qui nous a
permis d’obtenir une trés bonne configuration (taille n-gramme n=2 et 3, seuil de
détéction= 0.05) pour notre pare-feu permettant une meilleure sécurisation.
117

Conclusion générale et perspectives
Rappel des objectifs
À travers ce projet de fin d’études, nous avons abordé le domaine de la sécurité
des Web Services. Le problème majeur des Web Services réside dans les vulnéra-bilités
des messages échangés entre les Web Services et leurs clients à travers XML
via le protocole SOAP.
Notre objectif était de concevoir et de mettre en oeuvre un firewall XML, pour
la protection des plateformes basées sur les Web Services, contre les attaques par
injection.
Bilan des travaux effectués
Pour mener à bien notre travail, nous avons effectué une étude théorique et bib-liographique
dans laquelle nous avons présenté les web services et les technologies
et les standards qu’ils utilisent. Nous avons traité par la suite le domaine de la
sécurité des web service en présentant les différents types d’attaques qui confron-tent
les web services et plus précisément les attaques de type injection ; ainsi que
les principales caractéristiques des solutions proposées.
Par la suite, nous nous sommes focalisés sur le processus de comparaison et
calcul de similarité entre chaînes de caractères pour la détection des attaques de
type injection. Nous avons proposé une solution intégrant ce processus en utilisant
la fameuse distance Khi2 pour la détéction des attaques par injection suivantes (et
leurs variantes formes) :
– Injection XML
– Injection XPath
– Injection SQL
– Injection de commandes système
Nous avons implémenté notre firewall XML sous Linux en utilisant le langage
119

Conclusion générale et perspectives
Python et en utilisant la bibliothèque netfilterqueue. Gràce au panneau d’admin-istration,
l’administrateur peut reconfigurer le firewall en spécifiant la taille de
n-gramme et le seuil de détéction, et visualier le journal des messages et attaques
bloquées.
Nous avons effectué une série de tests pour montrer l’éfficacité de notre sys-tème,
les résultats obtenus montrent bien à quel point notre système est efficace
et montrent aussi que nos objectifs fixés au début ont été atteints.
Perspectives
Nous avons pu à travers ce travail atteindre nos objectifs fixés, cependant un
certain nombre d’améliorations peuvent être envisagés.
Nous présentons ici quelques améliorations possibles à notre solution :
– Réduire la taille du vecteur moyen, en n’utilisant que les paramêtres des méth-odes,
lors de la création du vecteur ; et ce pour accélèrer le traitement.
– Elargir la solution à d’autres types d’injections connues dans le web qui peu-vent
briller dans l’environnement des web services, à l’instar des injections
LDAP, injections d’expréssions régulières, XSS, ces attaques qui ont
été bien expliquées dans le « OWASP Top 10 » [Wichers, 2010].
– Etendre le champ de détection du système vers l’autre famille d’attaques vue
qui est le XDOS en utilisant des algorithmes de classification basées sur des
sessions des clients.
– Une autre amélioration qu’on peur porter, est de proposer d’autres algo-rithmes
de sécurisation, et concevoir un système d’aide à la décision permet-tant
de choisir parmi tous les algorithmes existants, le meilleur pour détecter
tel ou tel attaque ; tout en laissant à l’administrateur la possibilité de fixer l’al-gorithme
de sécurisation (voir chapitre 5 section 5.4.4.4 figure 5.4.7 « Interface
de configuration du firewall »).
120

Bibliographie
[Alkamari, 2008] Alkamari, A. (2008). Composition de services web par ap-pariement
de signatures.
[Amitab, 2011] Amitab, Khwairakpam et Padmavati, P. (2011). Comparison of sql
injection detection techniques which uses chi-square test. International Journal
of Engineering Science and Technology, 3(6).
[Ayachit, 2006] Ayachit, Mihir M et Xu, H. (2006). A petri net based xml firewall
security model for web services invocation. In Communication, Network, and
Information Security, pages 61–67.
[Binet, 2010] Binet, A. d. l. P. (2010). plus longue sous-séquence commune. http:
//binetacm.wikidot.com/algo:commsubseq. consulté le : 20-08-2014.
[Booth, 2004] Booth, David et Haas, H. e. M. F. e. N. E. e. C. M. e. F. C. e. O. D.
(2004). Web services architecture, w3c working group note, 11 february 2004.
World Wide Web Consortium, article disponible sur : http: // www. w3. org/
TR/ ws-arch .
[Bouhabel, 2013] Bouhabel, Y. (2013). Les bases de données semi structurées
(xml). Cours Base de Données avancées 2SIT, ESI.
[Bray, 1998] Bray, Tim et Paoli, J. e. S.-M. C. M. e. M. E. e. Y. F. (1998). Exten-sible
markup language (xml). World Wide Web Consortium Recommendation
REC-xml-19980210. http: // www. w3. org/ TR/ 1998/ REC-xml-19980210.
[briandunning, 2005] briandunning (2005). Free sample data for testing. https:
//www.briandunning.com/sample-data/. consulté le : 02-07-2014.
[Bryan, 2009] Bryan, S. (2009). Xml denial of service attacks and defenses. http:
//msdn.microsoft.com/fr-fr/magazine/ee335713.aspx. consulté le : 23-08-
2014.
[CCM, 2014a] CCM, Comment ca marche, C. (2014a). Attaque par
déni de service. http://www.commentcamarche.net/contents/
52-attaque-par-deni-de-service. consulté le : 23-08-2014.
121

BIBLIOGRAPHIE
[CCM, 2014b] CCM, Comment ca marche, C. (2014b). Firewall (pare-feu). http:
//www.commentcamarche.net/contents/992-firewall-pare-feu. consulté
le : 23-08-2014.
[Cheswick, 2003] Cheswick, William R et Bellovin, S. M. e. R. A. D. (2003). Fire-walls
and Internet security : repelling the wily hacker. Addison-Wesley Longman
Publishing Co., Inc.
[Choi, 2011] Choi, Junho et Kim, H. e. C. C. e. K. P. (2011). Efficient malicious
code detection using n-gram analysis and svm. In Network-Based Information
Systems (NBiS), 2011 14th International Conference on, pages 618–621. IEEE.
[Chollet, 2009] Chollet, S. (2009). Orchestration de services hétérogènes et
sécurisés. PhD thesis, Université Joseph-Fourier-Grenoble I.
[Cochran, 2012] Cochran, D. (2012). Twitter Bootstrap Web Development How-
To. Packt Publishing Ltd.
[Damashek, 1995] Damashek, M. e. a. (1995). Gauging similarity with n-grams :
Language-independent categorization of text. Science, 267(5199) :843–848.
[Delacour, 2005] Delacour, H et Servonnet, A. e. P. A. e. V. J. e. R. J. (2005).
La courbe roc (receiver operating characteristic) : principes et principales ap-plications
en biologie clinique. In Annales de biologie clinique, volume 63, pages
145–154.
[Desgraupes, 2008] Desgraupes, B. (2008). Introduction aux expressions régulières.
Vuibert.
[Dominique, 2008] Dominique, R. (2008). Les spécifications webservice. http:
//www-igm.univ-mlv.fr/~dr/XPOSE2005/rouvio_WebServices/soap.html.
consulté le : 13-01-2014.
[Fawcett, 2012] Fawcett, Joe et Ayers, D. e. Q. L. R. (2012). Beginning XML.
John Wiley Sons.
[Fischer, 2007] Fischer, M. (2007). Ubuntu GNU/Linux. Galileo Press.
[genratedata, 2012] genratedata (2012). genrate data. http://www.
generatedata.com/. consulté le : 02-07-2014.
[Greenwood, 1996] Greenwood, P. E. (1996). A guide to chi-squared testing, vol-ume
280. John Wiley Sons.
[Gundavaram, 1996] Gundavaram, S. (1996). CGI programming on the World
Wide Web. O’Reilly.
[Hanley, 1982] Hanley, James A et McNeil, B. J. (1982). The meaning and use
of the area under a receiver operating characteristic (roc) curve. Radiology,
143(1) :29–36.
122

BIBLIOGRAPHIE
[Hassen, 2009] Hassen, R. R. (2009). Automatic composition of prototocol-based
Web services. PhD thesis, Université Blaise Pascal-Clermont-Ferrand II.
[Hugo, 2002] Hugo, H. (2002). Standardisation des services web au w3c. Présen-tation
à la Journée de veille technologique à l’IRISA, Rennes, France.
[Hull and Grefenstette, 1996] Hull, D. A. and Grefenstette, G. (1996). Querying
across languages : a dictionary-based approach to multilingual information re-trieval.
In Proceedings of the 19th annual international ACM SIGIR conference
on Research and development in information retrieval, pages 49–57. ACM.
[Jensen, 2009] Jensen, Meiko et Gruschka, N. e. H. R. (2009). A survey of attacks
on web services. Computer Science-Research and Development, 24(4) :185–197.
[Kankanamge, 2012] Kankanamge, C. (2012). Web services testing with soapUI.
Packt Publishing Ltd.
[Klein, 2005] Klein, A. (2005). Blind xpath injection. Whitepaper from Watchfire.
[Kohavi, 1998] Kohavi, Ron et Provost, F. (1998). Glossary of terms. Machine
Learning, 30(2-3) :271–274.
[Kost, 2004] Kost, S. (2004). An introduction to sql injection attacks for oracle
developers.
[Kreger, 2001] Kreger, H. e. a. (2001). Web services conceptual architecture (wsca
1.0). IBM Software Group, 5 :6–7.
[Lackey, ] Lackey, Zane et Dwivedi, H. e. C. R. Hacking sur le Web 2.0. Pearson
Education France.
[Lelu, 1998] Lelu, Alain et Halleb, M. e. D. B. (1998). Recherche d’information
et cartographie dans des corpus textuels à partir des fréquences de n-grammes.
Actes de JADT, 98.
[Lipton, 1985] Lipton, Richard J et Lopresti, D. (1985). A systolic array for rapid
string comparison. In Proceedings of the Chapel Hill Conference on VLSI, pages
363–376.
[loribel, 2003] loribel (2003). Memento expression régulière. http://www.
loribel.com/info/memento/regex.html. consulté le : 20-08-2014.
[Michel, 2002] Michel, L. (2002). Les web services : définition, technologies, ac-teurs,
impact sur l’entreprise et problemes. Master’s thesis, HEC Montréal.
[Mookhey, 2004] Mookhey, KK et Burghate, N. (2004). Detection of sql injection
and cross-site scripting attacks. Symantec SecurityFocus.
[Nicolas, 2012] Nicolas, F. (2012). distance de levenshtein. http://nicolas.
francois.free.fr/fichiers/algo/se_levenshtein.pdf. consulté le : 20-08-
2014.
123

BIBLIOGRAPHIE
[OWASP, 2013a] OWASP (2013a). Blind sql injection. https://www.owasp.org/
index.php/Blind_SQL_Injection. consulté le : 01-01-2014.
[OWASP, 2013b] OWASP (2013b). Xpath injection. https://www.owasp.org/
index.php/XPATH_Injection. consulté le : 01-01-2014.
[OWASP, 2014a] OWASP (2014a). Command injection. https://www.owasp.
org/index.php/Command_Injection. consulté le : 01-07-2014.
[OWASP, 2014b] OWASP (2014b). Sql injection. https://www.owasp.org/
index.php/SQL_Injection. consulté le : 22-08-2014.
[Oza, 2013] Oza, A. (2013). Http attack detection using n-gram analysis.
[Patterson, 2007] Patterson, D. (2007). Xml firewall architecture and best prac-tices
for configuration and auditing. As Part of the Information Security Reading
Room Sans Institute.
[Progdupeupl, 2012] Progdupeupl (2012). Similarité cosinus et
recherche textuelle. http://progdupeu.pl/tutoriels/258/
similarite-cosinus-et-recherche-textuelle/. consulté le : 20-04-2014.
[Purdy, 2004] Purdy, G. N. (2004). Les iptables Linux. O’Reilly Media, Inc.
[Pypi, 2011] Pypi (2011). Netfilterqueue 0.3. https://pypi.python.org/pypi/
NetfilterQueue/0.3. consulté le : 01-07-2014.
[Rabhi, 2012] Rabhi, I. (2012). Testabilité des services Web. PhD thesis, Université
Blaise Pascal-Clermont-Ferrand II.
[Radhamani, 2007] Radhamani, G et Rao, G. R. K. (2007). Web services security
and e-business. IGI Global.
[Renaud, 2010] Renaud, B. (2010). Attaques sur les web services. http://www.
soapui.org/Security/xml-bomb.html. consulté le : 23-08-2014.
[Rossberg, 2006] Rossberg, Joachim et Redler, R. (2006). Pro scalable .net 2.0
application designs. web services design and practice. apress 2006. Technical
report, ISBN 978-1-59059-541-1 (Print) 978-1-4302-0080-2 (Online). Pag. 207-
276.
[Scambray, 2006] Scambray, Joel et Shema, M. e. S. C. (2006). Hacking exposed :
Web applications. McGraw-Hill New York.
[Shannon, 1951] Shannon, C. E. (1951). Prediction and entropy of printed english.
Bell system technical journal, 30(1) :50–64.
[SoapUI, 2011] SoapUI (2011). Xml bomb. http://www.soapui.org/Security/
xml-bomb.html. consulté le : 23-08-2014.
[Stallman, 1997] Stallman, R. (1997). Linux and the gnu project. Online Docu-ment,
2006.
124

BIBLIOGRAPHIE
[Stamos, 2005] Stamos, Alex et Stender, S. (2005). Attacking web services.
SyScan05.
[Suda, 2003] Suda, B. (2003). Soap web services. Retrieved June, 29 :2010.
[Swinnen, 2012] Swinnen, G. (2012). Apprendre à programmer avec Python 3.
Editions Eyrolles.
[Thakar and Dagdee, 2010] Thakar, U. and Dagdee, Nirmal et Varma, S. (2010).
Pattern analysis and signature extraction for intrusion attacks on web services.
International Journal of Network Security Its Applications, 2(3) :190–205.
[Tony, 2010] Tony, A. (2010). [php] coefficient de dice. http://tonyarchambeau.
com/blog/400-php-coefficient-de-dice/. consulté le : 02-08-2014.
[Van Rossum, 2007] Van Rossum, G. e. o. (2007). Python programming language.
In USENIX Annual Technical Conference.
[WEBAPPSEC, 2010] WEBAPPSEC (2010). Xquery injection. http://
projects.webappsec.org/w/page/13247006/XQueryInjection. consulté le :
01-01-2014.
[Wells, 2007] Wells, C. (2007). Securing Ajax Applications : Ensuring the Safety
of the Dynamic Web. O’Reilly Media, Inc..
[Wichers, 2010] Wichers, D. (2010). Owasp top-10 2013.
[Xu, 2008] Xu, Haiping et Ayachit, M. e. R. A. (2008). Formal modelling and
analysis of xml firewall for service-oriented systems. International journal of
security and networks, 3(3) :147–160.
[Yaron, 2007] Yaron, B. (2007). Understanding web services attacks a guide to pre-ventive
measures against threats. http://www.datacom.cz/files_datacom/
understanding_webservicesattacks_0.pdf. consulté le : 20-08-2014.
[Zerrouk, 2011] Zerrouk, F. (2011). Test du khi2. http://www.issep-ks.rnu.
tn/fileadmin/templates/Fcad/Test_de_Khi_carre.pdf. consulté le : 02-08-
2014.
125

Annexe A
Le langage XPath
Le langage XML Path (XPath) sert principalement à adresser (référencer) les
noeuds d’un document XML représenté sous la forme d’un arbre de noeuds. Il tire
son nom du fait qu’il utilise une notation sous forme de chemin pour parcourir la
structure hiérarchique d’un document XML. Sa syntaxe ; compacte et non-XML ;
est utilisée pour former des expressions à employer dans les URI et les valeurs
d’attributs XML tout en prenant les espaces de nom XML. XPath est conçu pour
être utilisé par des applications XML comme XSLT et XQuery.
La figure suivante (Figure A.1) montre le modèle de noeuds utilisé par XPath
[Bouhabel, 2013].
129

La forme syntaxique de base de XPath est l’expression. Une expression répond à
la règle de production Expr. Une expression s’applique à 4 types possibles d’objets :
– ensemble de noeuds (une suite non-ordonnée de noeuds sans doublon)
– booléen (vrai ou faux)
– nombre (un réel)
– chaîne de caractère
A.1 La forme d’une expression XPath
La forme générale d’une expression XPATH est [Fawcett, 2012] :
– sélecteur1/sélecteur2/... (exp. relative)
– /sélecteur1/sélecteur2/... (exp. absolue)
Chaque sélecteur sélectionne un ensemble de noeuds en fonction du résultat du
sélecteur précédent. D’autres syntaxes abrégées peuvent être utilisées dans une
expression XPath ; comme :
– * : sélectionne tous les enfants du noeud contextuel
– text() : sélectionne tous les noeuds enfants de type textuels du noeud contextuel
– @name : sélectionne l’attribut name du noeud contextuel
– @* : sélectionne tous les attributs du noeud contextuel
– para[1] : sélectionne le premier enfant para du noeud contextuel
– employée[@secretary and @assistant] : sélectionne tous les enfants employée
du noeud contextuel qui ont simultanément les attributs secretary et assistant.

Annexe B
Algorithme de distance de
Levenshtein
Nous présentons dans ce qui suis l’algorithme de la distance Levenshtein vue en
chapitre 3.
133

Exemple de déroulement de l’algorithme
Pour comprendre le fonctionnement de cet algorithme, prenons un exemple :
Soit chaine1 = « NICHE » Soit chaine2 = « CHIENS »
on voit bien que l’on peut transformer chaîne1 en chaine2 en 5 étapes :
– Suppression de N et I CHE;
– Insertion de I, N et S CHIENS.
La distance de Levenshtein d entre « NICHE » et « CHIENS » est donc 5.

Annexe C
La commande IPTables/La
Bibliothèque NetfilterQueue
C.1 La commande IPTables
Iptables est une interface en ligne de commande permettant de configurer les
chaînes et règles dans le pare-feu en espace noyau (et qui est composé par des
modules Netfilter). Iptables est utilisée pour différents protocoles réseau( IPv4,
ARP,...etc.) [Purdy, 2004].
C.1.1 Fonctionnement
Iptables fonctionne selon un système de tables, ces tables sont composées de
chaîne. Dans le cadre de la configuration et de l’utilisation de Netfilter comme
pare-feu, c’est la table Filter qui est utile, elle permet de filtrer les paquets réseaux.
Tout paquet entrant est analysé afin de déterminer notamment sa source et sa
destination. Elle est composée de trois sortes de chaîne :
– INPUT : Permet d’analyser les paquets entrants. Si le paquet est adressé au
poste, il est confronté au filtre INPUT.
– FORWARD : Permet d’analyser et d’autoriser les trames à passer d’une
interface à une autre, seulement dans le cadre d’une interface réseau servant
de passerelle.
– OUTPUT : Permet d’analyser les paquets sortants. Si le paquet sort du
poste, il passera par la chaîne OUTPUT.
Chaque chaîne est composée d’un ensemble de règles de traitement des paquets,
chaque règle d’une chaîne contient la spécification des paquets qui lui correspon-dent.
Elle peut également contenir une action (utilisée pour les extensions) ou un
jugement (une de plusieurs décisions intégrées). Quand un paquet traverse une
137

chaîne, chaque règle, à son tour, est examinée. Si une règle ne correspond pas au
paquet, le paquet est passé à la règle suivante.
Si une règle correspond au paquet, elle prend les mesures indiquées par l’ac-tion/
le jugement, ce qui peut conduire à autoriser le paquet à continuer dans la
chaîne ou, à l’inverse, à l’exclure. Les spécifications constituent la grande partie des
règles, car elles contiennent les conditions selon lesquelles les paquets sont testés.
Ces spécifications peuvent fournir pour toute couche du modèle OSI, comme par
exemple les paramètres : –mac-source et -p tcp – dport.
Le paquet continue à parcourir la chaîne jusqu’à ce que :
– soit une règle corresponde au paquet et décide du sort ultime du paquet.
– soit une règle appelle le jugement RETURN et, dans ce cas, le traitement
revient à la chaîne d’appel.
– soit la fin de la chaîne est atteinte. Actions aussi rend un verdict comme
ACCEPT ou DROP, mais aussi peut impliquer CONTINUE pour continuer
avec la règle suivante, comme si aucun action/jugement n’avait été précisé.
C.2 La Bibliothèque NetfilterQueue
Il s’agit d’un binding de la fameuse bibliothèque C libnetfilter_queue en python.
NetfilterQueue fournit accès à des paquets appariés par une règle iptables Linux.
Les paquets ainsi appariés peuvent être acceptés, bloquées, modifiés, ou marqués.
La bibliothèque est sous license MIT et disponible pour téléchargement via github
ou PyPi ( le gestionnaire des bibliothèques python) [Pypi, 2011].
Exemple
Le script suivant affiche une petite description de chaque paquet avant de l’ac-cepter.

Algorithme C.1 Exemple d’utilisation de la bibliothèque NetfilterQueue
from ngram import ngram
def print_and_accept(pkt) :
print pkt
pkt.accept()
nfqueue = NetfilterQueue()
nfqueue.bind(1, print_and_accept)
try :
nfqueue.run()
except KeyboardInterrupt :
print
Pour envoyer les paquets destinés à notre LAN au script, on ajoute la régle
suivante.
# iptables -I INPUT -d 192.168.0.0/24 -j NFQUEUE –queue-num 1
C.2.1 Principaux objets et méthodes de la bibliothèque
QueueHandler.bind(queue_num,....) Créer et lier à la file d’attente.
QueueHandler.unbind() Retirer la file d’attente.
Les paquets appariés par votre règle
iptables seront supprimés.
QueueHandler.run() Envoyer des paquets au CALLBACK.
Packet.get_payload() Retourne le payload comme string.
Packet.accept() Accepter le paquet
Packet.drop() Bloquer le paquet (drop)

Annexe D
Les vecteurs d’attaques utilisées
dans ce projet
Pour pouvoir effectuer nos tests nous avons utilisé une série de vecteurs d’at-taques
(chaînes de caractères d’injection), ces vecteus ont été récupéré depuis le
net, et via les outils de scan et test de pénétration (SQLmap, SQLninja, xcat) et
l’outil SoapUI. Nous citons quelques unes les plus usuelles.
D.1 Injection SQL
Injection Signification
SELECT @@version Séléctionner la version utilisée de MySQL
SELECT user FROM mysql.user ; Séléctionner les utilisateurs MySQL
SELECT distinct(db) FROM mysql.db Séléctionner toutes les bases de données
’ or 1=1– tautologie résultat vrai toujours
’ union select 1, requete suivie de la requete de séléction
de la 1ere table ; souvent celle des admins
zsmahi’– accéder en tant que l’utilisateur zsmahi
sans mot de passe
Table D.1 : Injections SQL les plus usuelles cas MySQL
141

D.2 Injection de commandes OS
; ls -al Lister tout le contenu du répertoire courant
; cat /etc/passwd Afficher le contenu du fichier des mots de passe
des utilisateurs unix
file.txt ; mail file.txt rediriger la sortile de la commande vers un fichier
file.txt et l’envoyer par mail
; rm -r ~/* supprimer tout le contenu du répértoire de
l’utilisateur courant.
Table D.2 : Injections de commandes OS cas Linux
D.3 Injection XPath
or 1=1 or ”=’ Equivalente à or 1 = 1 du SQL ; tout est vrai.
or name(//subscribers/Matricule[1]) Utiliser pour tester le blind XPath injection
= ’1’ or ’a’=’b
doc(subscribers.xml)/* Injection XQuery pour récupérer tout le
contenu du fichier XML (dumping)
Table D.3 : Injections XPath

D.4 Injection XML
ouvrir une balise
fermer une balise
xmlxml joke /xml /joke Bloquer l’analyseur (Parser) XML
xi :include href=file :///etc/passwd Inclure le fichier des mot de passe
parse=text/ des utilisateurs Linux
![CDATA[ / ]] Injection de la balise CDATA
Table D.4 : Injections XML

Securisation des web services soap contre les attaques par injection

Contenu connexe

Tendances

Similaire à Securisation des web services soap contre les attaques par injection

Plus de Zakaria SMAHI

Securisation des web services soap contre les attaques par injection