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

Securisation des web services soap contre les attaques par injection

Securisation des web services soap contre les attaques par injection

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

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

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

Plus de Zakaria SMAHI

Plus de Zakaria SMAHI (11)

Securisation des web services soap contre les attaques par injection