Securisation des web services soap contre les attaques par injection

Mmoire de fin dtudes

Pour lobtention du diplme dIngnieur dEtat en Informatique

Option : Systmes Informatiques (SIQ)

Thme

Ralis par : Propos et encadr par :

- Mr. SMAHI Zakaria

- Mr. AMROUCHE Hakim

Soutenu le : 16/09/2014

Devant le Jury compos de :

Mr. CHALLAL.Y (Prsident)

Mr. KHELOUAT.B (Assesseur1)

Mr. DELLYS. H (Assesseur2)

Mr. AMROUCHE. H (Assesseur3)

Promotion: 2013 - 2014

Scurisation des Web Services SOAP contre les attaques

par injection par la mthode Khi-2 ()

Ddicaces

ceux qui ont sacrifi une partie de leur vie pour me voir grandir etrussir, ceux qui mont toujours soutenu et encourag, A vous ma chremaman et mon chre papa, que dieu vous garde.

la mmoire de mes grands-parents, et ma grande mre et mongrand pre, que dieu les garde. mes deux adorables frres, Abdeldjalil et Salaheddine.

mon PC El-Nino ;)

mes amis denfance 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 jai pass les moments

les plus heureux de mon cursus lESI, chacun par son nom.

mes enseignants du primaire, jusqu luniversit. tous ceux que ce papier na pas pu contenir.

Zakaria

i

Remerciements

Au terme de ce travail je tiens tout dabord remercier Allah le toutpuissant de mavoir donn la foi, la volont et la persvrance pourlaboutissement de ce modeste travail.Je prsente mes sincres remerciements mon encadreur Mr AM-

ROUCHE Hakim qui ma soutenu et encadr durant toutes les tapesde ce projet de fin dtude, je le remercie infiniment pour sa disponi-bilit, sa patience, sa rigueur scientifique, et ses remarques et conseilspertinents.Je remercie aussi, lensemble des enseignants Mr. GUERROUT, Mr.

ARIES et Mr. BENCHERIF de lESI et Mr. BENDJIMA et Mr. BE-NAHMED de luniversit de Bechar et Mr. BOUTEFARA de luniversitde Jijel pour leur aide, leurs conseils et leurs remarques.Je remercie les membres de la grande communaut de lopen source

et la scurit informatique Mr. Djamil SLIMANI (aka Chevrosky), Mr.Islem MENNOUCHI et Mr. Assem CHELLI pour leurs aides techniqueset documentaires.Je tiens remercier galement lensemble des ingnieurs et doctor-

ant de lESI : 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 sincres remerciements tous ceux qui, de prs ou de loin,

ont contribu par leurs conseils et leurs encouragements ldificationde ce mmoire.

iii

Rsum

Les Web Services sont des applications bases sur XML qui fournissent uneinfrastructure pour dcrire (WSDL), dcouvrir (UDDI) et invoquer (SOAP) desservices. Malheureusement, une plateforme base sur les web services est confronte un certains nombre dattaques dues lutilisation du XML comme format pourles messages de communication SOAP.Ces attaques sont gnralement de type injection (do lappellation attaques

par injection) et reposent sur le problme quil nexiste aucune sparation stricteentre les instructions dun programme et les donnes quun utilisateur y saisit. Lafamille dattaques par injection regroupe les injections SQL, les injections surles fichiers XML (injections XML, injections XPath et injections XQuery)et les injections de commandes du systme.Pour fournir un mcanisme de scurit plus efficace pour les plateformes bases

sur les web services, les pare-feu XML ont t rcemment introduits comme uneextension pour les pare-feux conventionnels. Dans ce contexte nous allons concevoiret raliser un pare-feu XML, qui peut tre utilis pour scuriser les web servicescontre les attaques par injection. Notre firewall reoit en entre un message SOAP,qui lui extrait ses diffrents n-grammes et les compare avec un model dej crcontenant des bons messages du web service (un vecteur moyen) en utilisant unalgorithme de calcul de similarit entre chanes de caractres qui est la distanceKhi-2 (2) ; cette distance permet de dcider si le message est bon ou malveillant.Enfin, pour montrer lefficacit de notre pare-feu, nous lavons test sur une

plateforme base dun web service permettant aux clients de sauthentifier et desinscrire et ce pour pouvoir tester les diffrents types dinjections. Suite une sriede tests ; nous montrerons comment une injection peut tre dtcte efficacementpar notre pare-feu.

Mots cls : Web services, scurit, SOAP, attaques base XML , attaques parinjection, 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 bythe 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 anduser inputs data. The injection attacks family includes SQL injections, XMLfiles 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 stringswhich is the Khi-squared (2) distance; this distance allows to decide whetherthe 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 testdifferent types of injections. Following a series of performed tests ; we show howan 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 matires

Ddicaces i

Remerciements iii

Rsum v

Abstract vii

Table des matires ix

Table des figures xv

Liste des tableaux xvii

Liste des algorithmes xix

Liste des abrviations xxi

Introduction Gnrale 1

tude bibliographique 5

1 Les web services SOAP 71.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Dfinitions des Web Services . . . . . . . . . . . . . . . . . . . . . . 7

1.2.1 Dfinition du W3C . . . . . . . . . . . . . . . . . . . . . . . 71.2.2 Dfinition de IBM . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Caractristiques des Web services . . . . . . . . . . . . . . . . . . . 9

ix

TABLE DES MATIRES

1.4 Technologies des Web Services . . . . . . . . . . . . . . . . . . . . . 91.4.1 XML (eXtensibleMarkupLanguage) . . . . . . . . . . . . . . 10

1.4.1.1 Dfinition du W3C . . . . . . . . . . . . . . . . . 101.4.1.2 Autre dfinition . . . . . . . . . . . . . . . . . . . . 10

1.4.2 WSDL (Web Services Description Language) . . . . . . . . . 101.4.3 SOAP(Simple Object Access Protocol) . . . . . . . . . . . . 11

1.4.3.1 Messages SOAP du Cot Client . . . . . . . . . . . 121.4.3.2 Messages SOAP du Cot Serveur . . . . . . . . . . 121.4.3.3 Caratristiques du protocole SOAP . . . . . . . . . 131.4.3.4 Structure dun message SOAP . . . . . . . . . . . . 13

1.4.4 UDDI (Universal Description Discovery and Integration) . . 151.5 Fonctionnement des web services . . . . . . . . . . . . . . . . . . . 151.6 Avantages dutilisation des web services . . . . . . . . . . . . . . . . 171.7 Inconvnients dutilisation des web services . . . . . . . . . . . . . . 171.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Attaques par injection sur les web services 192.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 Les vulnrabilits dans les Web Services . . . . . . . . . . . . . . . 192.3 Attaques base XML sur les web services . . . . . . . . . . . . . . 202.4 Les attaques de dni de services XDOS . . . . . . . . . . . . . . . . 212.5 Les attaques par injection . . . . . . . . . . . . . . . . . . . . . . . 22

2.5.1 Injection XML . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.1.1 Injection XML simple . . . . . . . . . . . . . . . . 232.5.1.2 Injection de code XML Malform . . . . . . . . . . 242.5.1.3 Injection de balises XML automatiques . . . . . . . 252.5.1.4 Injection XML Persistante . . . . . . . . . . . . . 262.5.1.5 Injection XML dans les messages SOAP . . . . . . 27

2.5.2 Injection XPath . . . . . . . . . . . . . . . . . . . . . . . . . 292.5.2.1 Injection XPath Simple . . . . . . . . . . . . . . . 292.5.2.2 Dumping dun Document XML . . . . . . . . . . . 312.5.2.3 Blind XPath Injection . . . . . . . . . . . . . . . . 312.5.2.4 Injection XQuery . . . . . . . . . . . . . . . . . . . 312.5.2.5 Injection XPath dans les messages SOAP . . . . . 32

2.5.3 Injection SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 332.5.3.1 Manipulation du SQL . . . . . . . . . . . . . . . . 332.5.3.2 Injection de Code . . . . . . . . . . . . . . . . . . . 342.5.3.3 Injection des appels de fonctions . . . . . . . . . . 352.5.3.4 Blind SQL Injection . . . . . . . . . . . . . . . . . 362.5.3.5 Injection SQL dans les messages SOAP . . . . . . . 37

x

TABLE DES MATIRES

2.5.4 Injection de commandes OS . . . . . . . . . . . . . . . . . . 392.5.4.1 Injection de commandes OS dans les messages SOAP 40

2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3 Approches de scurisation des web services 433.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2 Firewall XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2.1 Pare-feu (Firewall en anglais) . . . . . . . . . . . . . . . . . 433.2.2 Pare-feu XML . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.3 Les approches de scurisation des web services . . . . . . . . . . . . 443.3.1 Les expressions rgulires . . . . . . . . . . . . . . . . . . . . 443.3.2 Test du Khi-2 2 . . . . . . . . . . . . . . . . . . . . . . . . 453.3.3 Les approches base de signatures . . . . . . . . . . . . . . 48

3.3.3.1 Avantages : . . . . . . . . . . . . . . . . . . . . . . 483.3.3.2 Inconvnients : . . . . . . . . . . . . . . . . . . . . 48

3.3.4 Les approches probabilistes . . . . . . . . . . . . . . . . . . 483.3.4.1 Comparaison et calcul de similarit entre chanes

de caractres . . . . . . . . . . . . . . . . . . . . . 493.3.4.2 Quelques travaux sur la dtection des attaques par

injection . . . . . . . . . . . . . . . . . . . . . . . . 533.3.5 Synthse des travaux . . . . . . . . . . . . . . . . . . . . . . 54

3.3.5.1 Les Approches par signature et les approches prob-abilistes . . . . . . . . . . . . . . . . . . . . . . . . 54

3.3.5.2 Les approches probabilistes . . . . . . . . . . . . . 543.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Conception 57

4 Conception 594.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2 Les attaques dtectes par notre pare-feu . . . . . . . . . . . . . . . 594.3 Architecture globale de notre firewall . . . . . . . . . . . . . . . . . 604.4 Le noyeau dadministration . . . . . . . . . . . . . . . . . . . . . . 60

4.4.1 Cration/Mise--jour dun profil web service . . . . . . . . . 614.4.1.1 Cration dun profil web service . . . . . . . . . . . 614.4.1.2 Modification de profil du web service . . . . . . . 67

4.5 Le noyeau de protection . . . . . . . . . . . . . . . . . . . . . . . . 674.5.1 Interception du message SOAP . . . . . . . . . . . . . . . . 674.5.2 Extraction des n-grammes et de la table de frquences . . . 684.5.3 Calcul de la distance Khi-2 . . . . . . . . . . . . . . . . . . . 68

xi

TABLE DES MATIRES

4.6 Fichier de configuration . . . . . . . . . . . . . . . . . . . . . . . . 714.7 Journal des vnements (log) . . . . . . . . . . . . . . . . . . . . . . 71

4.7.1 Visualisation et suppression du journal . . . . . . . . . . . . 734.8 Algorithme de protection . . . . . . . . . . . . . . . . . . . . . . . 754.9 Etude de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.9.1 Les mthodes de notre service web . . . . . . . . . . . . . . 764.9.2 Ajout du web service Users . . . . . . . . . . . . . . . . 76

4.9.2.1 Profil du web service . . . . . . . . . . . . . . . . . 764.9.2.2 Extraction des mthodes . . . . . . . . . . . . . . 764.9.2.3 Rcupration du log . . . . . . . . . . . . . . . . . 764.9.2.4 Extraction des n-grammes et gnration du vecteur

moyen . . . . . . . . . . . . . . . . . . . . . . . . . 764.9.3 Scnarios dattaques . . . . . . . . . . . . . . . . . . . . . . 77

4.9.3.1 Injection SQL . . . . . . . . . . . . . . . . . . . . . 774.9.3.2 Injection XPath . . . . . . . . . . . . . . . . . . . . 774.9.3.3 Injection XML . . . . . . . . . . . . . . . . . . . . 784.9.3.4 Injection de commandes OS . . . . . . . . . . . . . 794.9.3.5 Tester une attaque . . . . . . . . . . . . . . . . . . 79

4.9.4 Scnario un bon message . . . . . . . . . . . . . . . . . . . . 804.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Ralisation et Tests 81

5 Ralisation 835.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2 Systme dexploitation . . . . . . . . . . . . . . . . . . . . . . . . . 835.3 Environnement de dveloppement . . . . . . . . . . . . . . . . . . . 84

5.3.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.3.2 CGI-BIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.3.3 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.4 SoapUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.5 La bibliothque NetfilterQueue . . . . . . . . . . . . . . . . 87

5.4 La Ralisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.4.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . 875.4.2 Architecture technique du firewall . . . . . . . . . . . . . . . 895.4.3 Noyeau de Protection . . . . . . . . . . . . . . . . . . . . . . 89

5.4.3.1 Interception . . . . . . . . . . . . . . . . . . . . . . 905.4.3.2 Vrification . . . . . . . . . . . . . . . . . . . . . . 92

5.4.4 Noyeau dAdministration . . . . . . . . . . . . . . . . . . . . 925.4.4.1 Interface Login Panneau dadministration . . . . . 93

xii

TABLE DES MATIRES

5.4.4.2 Interface globale du Panneau dadministration . . . 935.4.4.3 Interface Profils des web services . . . . . . . . . . 945.4.4.4 Interface de Configuration . . . . . . . . . . . . . . 955.4.4.5 Interface Journal des vnements . . . . . . . . . . 96

5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6 Tests et Rsultats 996.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.2 Lensemble de donnes utilises pour la construction du vecteur

moyen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.2.1 Mesures dvaluations utilises . . . . . . . . . . . . . . . . . 100

6.2.1.1 Matrice de confusion . . . . . . . . . . . . . . . . . 1006.2.1.2 Courbe de ROC . . . . . . . . . . . . . . . . . . . 101

6.3 La configuration de la plateforme des tests . . . . . . . . . . . . . . 1026.4 Rsultats des exprimentations . . . . . . . . . . . . . . . . . . . . 102

6.4.1 Mthode Login . . . . . . . . . . . . . . . . . . . . . . . . . 1026.4.1.1 Test 1 : 1000 messages . . . . . . . . . . . . . . . . 1036.4.1.2 Test 2 : 5000 messages . . . . . . . . . . . . . . . . 1056.4.1.3 Test 3 : 10000 messages . . . . . . . . . . . . . . . 107

6.4.2 Mthode Subscribe . . . . . . . . . . . . . . . . . . . . . . . 1096.4.2.1 Test 1 : 1000 messages . . . . . . . . . . . . . . . . 1096.4.2.2 Test 2 : 5000 messages . . . . . . . . . . . . . . . . 1116.4.2.3 Test 3 : 10000 messages . . . . . . . . . . . . . . . 113

6.5 Discussion et Synthse . . . . . . . . . . . . . . . . . . . . . . . . . 1156.5.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.5.1.1 Taille du vecteur moyen . . . . . . . . . . . . . . . 1156.5.1.2 Temps moyen dexecution . . . . . . . . . . . . . . 1156.5.1.3 Taux de faux positifs et faux ngatifs . . . . . . . . 1156.5.1.4 Courbe de ROC . . . . . . . . . . . . . . . . . . . 116

6.5.2 Synthse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1166.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Conclusion gnrale et perspectives 119

Bibliographie 121

xiii

TABLE DES MATIRES

Annexes 127

A Le langage XPath 129A.1 La forme dune expression XPath . . . . . . . . . . . . . . . . . . . 131

B Algorithme de distance de Levenshtein 133

C La commande IPTables/La Bibliothque NetfilterQueue 137C.1 La commande IPTables . . . . . . . . . . . . . . . . . . . . . . . . 137

C.1.1 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . 137C.2 La Bibliothque NetfilterQueue . . . . . . . . . . . . . . . . . . . . 138

C.2.1 Principaux objets et mthodes de la bibliothque . . . . . . 139

D Les vecteurs dattaques utilises dans ce projet 141D.1 Injection SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141D.2 Injection de commandes OS . . . . . . . . . . . . . . . . . . . . . . 142D.3 Injection XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142D.4 Injection XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

xiv

Table des figures

1.4.1 Structure gnrale dun fichier WSDL . . . . . . . . . . . . . . . . 111.4.2 Description du fonctionnement du protocole SOAP . . . . . . . . . 121.4.3 Structure du message SOAP . . . . . . . . . . . . . . . . . . . . . 141.4.4 Exemple dun message SOAP . . . . . . . . . . . . . . . . . . . . . 141.5.1 Les principaux acteurs dans un web service . . . . . . . . . . . . . 16

2.3.1 Attaques base XML . . . . . . . . . . . . . . . . . . . . . . . . . 202.5.1 Les attaques par injection . . . . . . . . . . . . . . . . . . . . . . . 232.5.2 Injection XML dans un message SOAP . . . . . . . . . . . . . . . 282.5.3 Rponse du serveur au message SOAP envoy . . . . . . . . . . . . 282.5.4 Injection XPath dans un message SOAP . . . . . . . . . . . . . . . 322.5.5 Rponse du service web : lister tous les (username,password) . . . 332.5.6 Injection SQL dans un message SOAP . . . . . . . . . . . . . . . . 382.5.7 Rponse SOAP linjection SQL . . . . . . . . . . . . . . . . . . . 382.5.8 Injection Commandes dans un message SOAP . . . . . . . . . . . 402.5.9 Injection Commandes dans un message SOAP . . . . . . . . . . . 41

3.2.1 Systme bas sur les web services protg par un pare-feu XML . 443.3.1 Table de Khi-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.1 Architecure globale pare-feu XML . . . . . . . . . . . . . . . . . . 604.4.1 Profils des web services . . . . . . . . . . . . . . . . . . . . . . . . 624.4.2 Ajouter un web service . . . . . . . . . . . . . . . . . . . . . . . . 634.4.3 mcanisme dajout dun web service . . . . . . . . . . . . . . . . . 644.4.4 Parser du fichier WSDL . . . . . . . . . . . . . . . . . . . . . . . . 644.4.5 Acquisiteur de requtes autorises . . . . . . . . . . . . . . . . . . 654.4.6 Extraction des n-grammes et de tableau de frquences des n-grammes 664.4.7 Vecteur moyen des frquences de n-grammes . . . . . . . . . . . . 664.4.8 Processus de modification dun profil web service . . . . . . . . . . 674.5.1 Schma de dcision de malveillance ou pas du message . . . . . . . 694.6.1 Structure du fichier de configuration . . . . . . . . . . . . . . . . . 71

xv

TABLE DES FIGURES

4.7.1 Structure dun fichier journal . . . . . . . . . . . . . . . . . . . . . 724.7.2 Structure dun fichier journal dattaques . . . . . . . . . . . . . . . 724.7.3 Visualisation et suppression du journal . . . . . . . . . . . . . . . 734.7.4 Exemple dun fichier Journal (log) . . . . . . . . . . . . . . . . . . 74

5.2.1 Systme Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2.2 Logo de la distribution ubuntu . . . . . . . . . . . . . . . . . . . . 845.3.1 Langage Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.3.2 Principe de fonctionnement du CGI . . . . . . . . . . . . . . . . . 855.3.3 Twitter Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.4 SoapUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.4.1 Diagramme de classes de la solution propose . . . . . . . . . . . . 885.4.2 Architecture de notre firewall . . . . . . . . . . . . . . . . . . . . . 895.4.3 Injection SQL envoye via loutil SoapUI . . . . . . . . . . . . . . 905.4.4 Interface dauthentification . . . . . . . . . . . . . . . . . . . . . . 935.4.5 Interface globale du Panneau dadministration . . . . . . . . . . . 945.4.6 Interface des Profils des Web Services . . . . . . . . . . . . . . . . 955.4.7 Interface configuration du firewall . . . . . . . . . . . . . . . . . . 965.4.8 Journal des attaques dtectes . . . . . . . . . . . . . . . . . . . . 97

6.3.1 Configuration du rseau LAN utilise pour les tests . . . . . . . . 1026.4.1 Graphe de variations de FP et FN cas 1000 messages . . . . . . . 1046.4.2 Courbe de ROC pour la mthode login cas 1000 messages . . . . . 1046.4.3 Graphe de variations de FP et FN cas 5000 messages . . . . . . . 1066.4.4 Courbe de ROC pour la mthode login cas 5000 messages . . . . . 1066.4.5 Graphe de variations de FP et FN cas 10000 messages . . . . . . . 1086.4.6 Courbe de ROC pour la mthode login cas 10000 messages . . . . 1086.4.7 Graphe de variations de FP et FN cas 1000 messages . . . . . . . 1106.4.8 Courbe de ROC pour la mthode subscribe cas 1000 messages . . 1106.4.9 Graphe de variations de FP et FN cas 5000 messages . . . . . . . 1126.4.10 Courbe de ROC pour la mthode subscribe cas 5000 messages . . 1126.4.11 Graphe de variations de FP et FN cas 10000 messages . . . . . . . 1146.4.12 Courbe de ROC pour la mthode subscribe cas 10000 messages . . 114

A.1 Le modle XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

xvi

Liste des tableaux

2.1 Rsultat danalyse du fichier XML . . . . . . . . . . . . . . . . . . 272.2 Exemple dinjection de commande . . . . . . . . . . . . . . . . . . 40

3.1 Exemples expressions rgulires . . . . . . . . . . . . . . . . . . . . 453.2 Signature de quelques attaques par inejction (cas injection SQL) . 483.3 1-grammes et bigrammes extraits de la chane "par exemple" . . . 51

4.1 Attaque Injection SQL . . . . . . . . . . . . . . . . . . . . . . . . 774.2 Attaque Injection XPath . . . . . . . . . . . . . . . . . . . . . . . 784.3 Attaque Injection XML . . . . . . . . . . . . . . . . . . . . . . . . 784.4 Attaque Injection de commandes OS . . . . . . . . . . . . . . . . . 79

6.1 Les diffrentes tailles dchantillons dapprentissage utiliss . . . . 1006.2 Exemple matrice de confusion . . . . . . . . . . . . . . . . . . . . 1016.3 Taille et Temps Gnration du Vecteur moyen cas 1000 messages . 1036.4 Taux de F.Ps et F.Ns, T.M de dtection cas 1000 messages . . . . 1036.5 AUC mthode login cas 1000 messages . . . . . . . . . . . . . . . . 1036.6 Taille et Temps Gnration du Vecteur moyen cas 5000 messages . 1056.7 Taux de F.Ps et F.Ns cas 5000 messages . . . . . . . . . . . . . . . 1056.8 AUC mthode login cas 5000 messages . . . . . . . . . . . . . . . . 1056.9 Taille et Temps Gnration du Vecteur moyen cas 10000 messages 1076.10 Taux de F.Ps et F.Ns cas 10000 messages . . . . . . . . . . . . . . 1076.11 AUC mthode login cas 10000 messages . . . . . . . . . . . . . . . 1076.12 Taille et Temps Gnration du Vecteur moyen cas 1000 messages . 1096.13 Taux de F.Ps et F.Ns cas 1000 messages . . . . . . . . . . . . . . . 1096.14 AUC mthode subscribe cas 1000 messages . . . . . . . . . . . . . 1096.15 Taille et Temps Gnration du Vecteur moyen cas 5000 messages . 1116.16 Taux de F.Ps et F.Ns cas 5000 messages . . . . . . . . . . . . . . . 1116.17 AUC mthode subscribe cas 5000 messages . . . . . . . . . . . . . 1116.18 Taille et Temps Gnration du Vecteur moyen cas 10000 messages 1136.19 Taux de F.Ps et F.Ns cas 10000 messages . . . . . . . . . . . . . . 113

xvii

LISTE DES TABLEAUX

6.20 AUC mthode subscribe cas 10000 messages . . . . . . . . . . . . 113

D.1 Injections SQL les plus usuelles cas MySQL . . . . . . . . . . . . . 141D.2 Injections de commandes OS cas Linux . . . . . . . . . . . . . . . 142D.3 Injections XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142D.4 Injections XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

xviii

Liste des algorithmes

2.1 Script Perl vulnrable linjection XPath . . . . . . . . . . . . . . . 302.2 Code C vulnrable linjection de commandes . . . . . . . . . . . . 39

3.1 Distance de Khi-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.2 Algorithme de LCS . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3 Formule de similarit de cosinus . . . . . . . . . . . . . . . . . . . . 503.4 Formule de Coefficient de Dice . . . . . . . . . . . . . . . . . . . . . 51

4.1 Distance de Khi-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.2 Distance 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.3 Algorithme de protection . . . . . . . . . . . . . . . . . . . . . . . . 75

5.1 Code Dinterception de messages SOAP . . . . . . . . . . . . . . . . 915.2 Code De vrification du message SOAP . . . . . . . . . . . . . . . . 92

B.1 Algorithme Distance de Levenshtein . . . . . . . . . . . . . . . . . . 134

C.1 Exemple dutilisation de la bibliothque NetfilterQueue . . . . . . . 139

xix

Liste des abrviations

API Application Programming InterfaceAUC Area Under CurveDNS Domain Name SystemFW FireWallHTTP HyperText Transfer ProtocolHTTPS HyperText Transfer Protocol over SSLOASIS Organization for the Advancement of Structural

Information StandardsOS Operating SystemOWASP Open Web Applications Security ProjectROC Receiver Operating CharacteristicSOAP Simple Object Access ProtocolSQL Structured Query LanguageSSL Secure Socket LayerSVM Support Vector MachineUDDI Universal Description, Discovery and IntegrationURI Uniform Resource IdentifierURL Uniform Resource LocatorXDOS XML Denial Of ServiceXML eXtensible Markup LanguageXPath XML PathXQuery XML QueryW3C World Wide Web ConsortiumWEBAPPSEC WEB APPlication SECurity consortiumWS Web ServiceWSDL Web Service Description LanguageWWW World Wide Web

xxi

Introduction Gnrale

Cadre gnral et objectifsUn web service est un composant applicatif mis la disposition dautres systmes

et applications sur un rseau, il dispose de mthodes qui peuvent tre invoques distance via des protocoles rseau standards (HTTP). La communication entreles Web Services seffectue grce lutilisation du langage XML, et du protocoleSOAP.Les web services sont vulnrables un certain nombre dattaques dites attaques

base XML ou XML-based attacks , ces attaques sont en gnral des attaquesde type injection. Nous nous intrssons ce type, car il a une forte relation avecles donnes entres par un client du web service et qui ; en gnral ; ne sont pasvalides et controles avant tre envoyes au web service. Ce type dattaques ; et linstar de touts attaque base XML ; nest pas malheureusement trait par lespare-feu existants, suite leur inhabilit inspecter les contenus XML.Afin de remdier ce problme, les firewalls XML sont introduits comme solution

et extension aux firewalls existants. Ils se chargent danalyser les contenus XMLcontenu dans les messages SOAP et de les filtrer.

Lobjectif principal de notre travail est didentifier les diffrentes attaques parinjection contre les web services pouvant tre excutes travers les messagesSOAP, et de proposer un mcanisme de scurit qui permettra de dtecter cesattaques.

ContributionsNotre solution consiste utiliser un algorithme de calcul de similarit entre

chanes de caractres (distance de Khi2) comme un mcanisme pour dtcter lesattaques de type injection. cet algorithme compare un message entrant avec unensemble dj construit auparavant (un dataset) dans une phase dite phase dap-prentissage. Le rsultat de comparaison sera une dcision si le message est bon ou

1

Introduction Gnrale

malveillant.A travers cette solution nous visons crer un scnario dune plateforme base

sur un web service, ainsi que des scnarios dattaques sur cette plateforme ; pourenfin crer un model firewall XML pour scuriser les web services contre les at-taques par injection ; qui sera un middleware invisible pour les deux cots de lacommunication en web service (le web service lui-mme et ses clients).

Organisation du mmoireCe document est compos de trois parties :

Etude bibliographique :

Cette partie porte sur une tude dun tat de lart relatif notre problmatique, savoir, les diffrentes attaques auxquelles est confronte une plateforme basesur les web services. Elle comporte trois chapitres : Chapitre 1 intitul Les web services SOAP : qui prsente la technolo-gie de web services : les dfinitions donnes, les standards utiliss et leursarchitectures.

Chapitre 2 intitul Attaques par injection sur les web services : dansce chapitre nous abordons les attaques sur les web services et nous dtaillonsles attaques de type injection et leurs impacts sur les web services.

Chapitre 3 intitul Approches de scurisation des web services : nousprsentons ici les diffrents travaux effectus dans le domaine de scurisationdes web services, nous essayons par la fin de les synthtiser et montrer leurspoints forts et leurs insuffisances.

Conception :

Cette partie contient un seul chapitre : Chapitre 4 intitul Conception : qui portera sur ltude conceptuelle etla description de notre solution dveloppe, ainsi que les diffrents modules deson architecture, enfin nous prsenterons une tude dun cas rel sur laquellenous montrons le fonctionnement de notre solution et ce travers des scnariosde diffrents types dattaques par injection.

Ralisation et tests :

Cette partie est consacre aux dtails techniques de notre solution et ses perfor-mances. Elle comporte deux chapitres :

2

Chapitre 5 intitul Ralisation : on dtaillera ici la mise en uvre de lasolution propose dans la deuxime partie, en prsentant les outils utiliss etlimplmentation du firewall XML.

Chapitre 6 intitul Tests et Rsultats : dans ce chapitre nous effectuonsune srie de tests afin de montrer lfficacit de notre firewall, en lxecutantdans un environnement rel contenant une plateforme base de web service.A travers une srie de scnarios dattaques et de non-attaques nous testons lesperformances de cette solution, les rsultats ainsi obtenus seront intrprt etanalys et synthtis la fin pour en sortir avec une meilleure configurationde ce pare-feu.

En fin, nous allons conclure ce travail par une conclusion gnrale, et les perspec-tives envisages et les possibilits dextension de notre solution, et les ventuellesamliorations.

3

tude bibliographique

Once you stop learning, youstart dying "

(Albert EINSTEIN)

Chapitre 1

Les web services SOAP

1.1 IntroductionLes Web services sont devenus de plus en plus populaires, non seulement dans

les rseaux intranet, mais aussi dans les communications inter-entreprises ; et cegrce la manire dont ils dfinissent et traitent les donnes et les faire agir avecdautres applications.Les web services sont des applications base XML, mis la disposition de

dautres applications et systmes sur un rseau. Ils sont des complments auxprogrammes et applications existantes dveloppes laide des langages tel queC++, Java, Python . . . etc., qui assurent les communications des programmes entreeux.Alors cest quoi un web service ? Cest quoi XML? Et comment les web services

communiquent avec les autres applications ?

1.2 Dfinitions des Web ServicesIl existe plusieurs dfinitions des web services, cependant elles convergent toutes

vers le fait que les web services sont des programmes accessibles distance, quipeuvent tre dploys sur nimporte quel plateforme, et peuvent tre utiliss pardautres programmes y compris dautres web services. Il sagit dune forme de tech-nologie intergicielle (Middleware) qui sappuie sur des standards, principalementproposs par le World Wide Web Consortium (W3C), comme XML,WSDL.

1.2.1 Dfinition 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 byits description using SOAP messages, typically conveyed using HTTPwith an XML serialization in conjunction with other Web-related stan-dards. [Booth, 2004].

Traduction :

Un Web service est un systme logiciel conu pour soutenir linteraction in-teroprable machine--machine.Il dispose dune interface dcrite dans un formatlisible en machine (en particulier WSDL).Les systmes interagissent avec un service web travers la manire prescrite

par sa description en utilisant les messages SOAP, typiquement transmis via leprotocole HTTP avec une srialisation XML en conjonction avec dautres normeslies au Web.

1.2.2 Dfinition 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, calledits service descrption. It covers all the details necessary to interactwith 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 thehardware or software platform on which it is implemented and also in-dependently of the programming language in which it is written. Thisallows and encourages Web Services-based applications to be looselycoupled, Component-oriented, cross-tcehnology implementations. WebServices fulfill a specific task or a set of tasks. They can be used aloneor with other Web Services to carry out a complex aggregation or abusiness transaction [Kreger, 2001].

Traduction :

UnWeb Service est une interface qui dcrit une collection doprations accessibesvia rseau travers une messagerie XML standardise. Un Web Service est dcriten utilisant une notion de la norme XML, formelle, appele sa descrption de service.Elle (i.e la description du service) couvre tous les dtails ncessaires pour interagiravec le service, y compris les formats de messages (qui dtaillent les oprations),les protocoles de transport et lemplacement.

8

1.3 Caractristiques des Web services

Linterface masque les dtails du service, ce qui permet de lutiliser indpendam-ment de la plate-forme matrielle (hardware) ou logicielle (software) laquelle ilest mis en oeuvre et galement indpendamment du langage de programmationdans lequel il est crit ; ceci qui assure et encourage un faible couplement et desimplmentations inter-technologies.Les web services remplissent une tche spcifique ou une srie de tches. Ils

peuvent tre utiliss seuls ou avec dautres web services pour raliser une agrgationcomplexe ou une transaction commerciale.Ces deux dfinitions mettent en valeur les points suivants : Linterface du web service, interprtable par dautres machines, permettantaux applications daccder dune manire automatique au service.

Lutilisation des protocoles et langages indpendants des plateformes de d-ploiement qui renforcent linteroprabilit entre services.

Lutilisation des normes actuelles du Web permettant la ralisation des inter-actions faiblement couples et favorisant aussi linteroprabilit.

1.3 Caractristiques des Web servicesLes web services sont en gnrales caractrises par ces caractristiques [Hugo, 2002] : Interactions entre machines Accords dynamiques Pas de connaissance a priori des services avec lesquelles le programme est eninteraction.

Laccessibilit via le rseau. Son interface, permet aux applications daccder dune manire automatiqueau service

1.4 Technologies des Web ServicesAfin de rendre les web services interoprables, lorganisation WS-I a propos de

dfinir les web services en introduisant des profils.Lun de ces profils est le WS-IBasic qui est compos de quatre parties[Rabhi, 2012] : La description de linterface du service web grce au langage WSDL (WebServices Description Language).

La srialisation des messages transmis via le protocole SOAP(Simple ObjectAccess Protocol).

Lindexation des services Web dans des registres UDDI (Universal Description,DiscoveryIntegration).

9


La scurit des services Web, obtenue essentiellement grce des protocolesdauthentification et de cryptage XML.

1.4.1 XML (eXtensibleMarkupLanguage)1.4.1.1 Dfinition du W3C

Extensible Markup Language (XML) is a simple, very flexible textformat derived from SGML (ISO 8879). Originally designed to meetthe challenges of large-scale electronic publishing, XML is also playingan increasingly important role in the exchange of a wide variety of dataon the Web and elsewhere. [Bray, 1998].

1.4.1.1.1 Traduction

Extensible Markup Language (XML) est un format texte simple, trs soupledriv de SGML (ISO 8879). Initialement conu pour rpondre aux dfis de ldi-tion lectronique grand chelle, XML joue galement un rle de plus en plusimportant dans lchange dune grande varit de donnes sur le Web et ailleurs.

1.4.1.2 Autre dfinition

Les Web Services se fondent sur XML qui est un langage de bannires, permet-tant dcrire des contenus organiss de manire hirarchique. Le principal intrtdXML est que ce format de document permet de transmettre linformation, etles mtadonnes qui indiquent sa signification, et la structure de linformation changer[Rabhi, 2012].Ces deux dfinitions mettent en valeur les points suivants : XML est un langage de balisage driv du langage SGML. Sa syntaxe est extensible ce qui permet de dfinir des espaces de noms (names-paces) ; i.e des langages spcifiques avec leurs vocabulaires et grammaires.

Lobjectif initial du XML est de faciliter lchange automatis de contenuscomplexes entre systmes dinformations htrognes (interoprabilit) ; doson utilisation dans les web services.

1.4.2 WSDL (Web Services Description Language)WSDL fournit une description de linterface des Web Services. Il permet de

dcrire lensemble des oprations fournies par un Web Service. Les messages missont consomms par ces oprations, sans se proccuper de limplantation de celles-ci[Hassen, 2009].

10

1.4 Technologies des Web Services

le fichier WSDL est un fichier XML qui peut tre divis en deux parties, lapremire partie lentte qui est compose des dfinitions abstraites, et la secondepartie qui se compose de descriptions concrtes [Chollet, 2009]. Description abstraite : concerne linterface du service, les oprations sup-portes, ainsi les paramtres et les types de donnes.

Description concrte : concerne laccs au service (port, protocole spci-fique daccs, etc.).

La figure suivante (figure 1.4.1) montre bien la structure dun fichier WSDL :

Figure 1.4.1 : Structure gnrale dun fichier WSDL

1.4.3 SOAP(Simple Object Access Protocol)SOAP est construit comme tant un nouveau protocole pour les environnements

dcentraliss et distribus. Il utilise le rseau internet et XML pour changer lesinformations entre les nuds [Suda, 2003].

11


SOAP, dvelopp par IBM et Microsoft, est une recommandation W3C qui ledfinit comme tant un protocole de communication bas sur XML pour perme-ttre aux applications de schanger des informations via HTTP. Il permet ainsilaccs aux services web et linteroprabilit des applications travers le web. Ilest portable et donc indpendant de tous systme dexploitation et du type dor-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 requets SOAP-XML envelopps dans des requtes HTTP. De mme, les rponses du serveur sontdes rponses HTTP qui renferment des rponses SOAP-XML. Dans le processusclient, lappel de service est converti en une requte SOAP qui est ensuite enveloppdans une HTTP.

1.4.3.2 Messages SOAP du Cot Serveur

Cest lgrement plus compliqu car il requiert un processus listener correspon-dant au processus serveur en attente de connexion cliente. Le listener est souventimplment travers dun servlet qui sexcute et qui a comme tache lextractiondu message XML-SOPA partir de la requte HTTP, de le d-srialiser cest dire de sparer le nom de la mthode et les paramtres fournis puis invoquer lamthode du service en consquence. Le rsultat de la mthode est alors srialis,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 Technologies des Web Services

1.4.3.3 Caratristiques du protocole SOAP

SOAP repose sur le langage XML. Cest un protocole peu restrictif, qui laisse aux composants des Web Services lesoin de dfinir comment ils formateront le contenu du message [Dominique, 2008].

Le transport et le systme dopration sont indpendants, car il est construiten utilisant le protocole http et le langage de balisage XML [Suda, 2003].

SOAP est fondamentalement un modle de communication One-way, qui as-sure quun message cohrent est transfr de lexpditeur au destinataire, ycompris potentiellement les nuds intermdiaires, qui peuvent traiter unepartie, ou ajouter lunit de message.

1.4.3.4 Structure dun message SOAP

SOAP dfinit un format pour lenvoi des messages. Les messages SOAP sontstructur en un document XML et comporte 2 lments obligatoires : Une en-veloppe et un corps (une entte facultative).La structure dun message SOAP estla suivante [Rossberg, 2006] : SOAP Enveloppe : Cest llment racine du message SOAP, elle dfinit lecontexte du message, son destinataire et son contenu. Elle contient un lmentden-tte optionnel.

SOAP Header : Cest un bloc optionnel qui contient des informations den-ttes sur le message. SOAP Header donne des directives au destinataire, con-cernant le traitement du message. Ces directives concernent gnralement lascurit : dclaration dassertions, dclaration de signature, dclaration dechiffrement, information sur une cl cryptographique,. . . etc.

SOAP Body : Cest llment contenant les donnes utiles transmettre.Chacune de ses entres contient des informations applicatives que le desti-nataire doit traiter. Llment Body est galement utilis pour transmettreun message derreur dans le cas o une erreur survient. Il doit absolumenttre prsent dune manire unique dans chaque message, et tre contenu dansle bloc SOAP enveloppe.

Des attachements optionnels, tel que le SOAP Fault : Ce bloc est la seulestructure dfinie par SOAP dans le bloc Body, et sa prsence nest pas obli-gatoire. Il sert reporter des erreurs lors du traitement du message, ou lorsde son transport. Il ne peut apparatre quune 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 dun message SOAP pour une mthode de login ou les paramtressont le nom dutilsateur et le mot de passe.

Figure 1.4.4 : Exemple dun message SOAP

14

1.5 Fonctionnement des web services

1.4.4 UDDI (Universal Description Discovery and Integration) UDDI est la spcification rgissant linformation relative la publi-

cation, la dcouverte et lutilisation dun Web Service. En dautre termeUDDI dtermine comment nous devons prsenter lentreprise et le WebService quelle offre la communaut afin de permettre cette derniredy avoir accs. Do le concept UDDI est vu en deux aspects : len-registrement de linformation, et la dcouverte de cette information.En effet, UDDI est un annuaire (registre) web sous un format XML. [Michel, 2002].

UDDI est une spcification dannuaire qui propose denregistrer et de rechercherdes fichiers de description des Web Services, correspondant aux attentes dun client[Chollet, 2009].Il se comporte comme le DNS, la diffrence quil rsout le nom de service au

lieu des noms de domaines. Il nest pas affili avec le W3C, mais il a t soumis lorganisme de normalisation OASIS pour lexaminer. Comme le registre UDDIest un Web Service, il gagne tous les avantages du langage XML et du protocoleSOAP [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, lutilisateur dun Web Service peut rechercher un WebService spcifique en utilisant le registre UDDI [Radhamani, 2007].UDDI est un standard spcifi par OASIS (Organization for the Advancement of

Structured Information Standards), pour la publication et la dcouverte desweb services. UDDI est un annuaire de services bas sur XML qui permetdautomatiser les communications entre les fournisseurs du service web etclients.

1.5 Fonctionnement des web servicesLes web services sont des technologies qui permettent des applications de dia-

loguer via internet, par lchange des messages fonds sur des standards web. Troisacteurs principaux figurent dans lutilisation dun service web [Kreger, 2001] : Le fournisseur du service (provider). Le demandeur de service (requester). Lannuaire de service permettant la dcouverte du service web et son four-nisseur (registry).

Le schma suivant (figure 1.5.1) rsume lutilisation dun service web et ses acteursprincipaux :

15


Figure 1.5.1 : Les principaux acteurs dans un web service

16

1.6 Avantages dutilisation des web services

1.6 Avantages dutilisation des web servicesLes web services sont, de nos jours, utiliss grand chelle et ce grce aux

avantages quelles offrent :[Alkamari, 2008] Les web services rduisent le temps de mise en march des services offerts parles diverses entreprises.

Les web services utilisent des normes et protocoles ouverts (SOAP, XML,HTTP).

Les protocoles et les formats de donnes sont offerts, le plus possible, enformat texte pour que la comprhension du fonctionnement des changes soitplus intuitive.

Grce au protocole HTTP, les web services peuvent fonctionner malgr lespare-feu sans pour autant ncessiter des changements sur les critres de fil-trage.

Grce aux web services, les cots sont rduits par lautomatisation interne etexterne des processus commerciaux.

1.7 Inconvnients dutilisation des web servicesMalgr les avantages offerts par les web services, elles ont plusieurs inconvnients,

qui sont en premier lieu des problmes de scurit, tels que : Leurs vulnrabilits facilitant le contournement des mesures de scurit. Labsence des mcanismes didentification, dauthentification et de chiffragedans la technologie SOAP, la technologie principale des web services.

Les problmes de fiabilit : Il est difficile de sassurer de la fiabilit dunservice car on ne peut garantir, que ses fournisseurs ainsi que les personnesqui linvoquent travaillent dune faon fiable.

Les problmes de disponibilit : Les web services peuvent bien satisfaire unou plusieurs besoins du client [Alkamari, 2008].

1.8 ConclusionLa technologie des web services, est lune des technologies les plus connues et les

plus utilises. Elle est base sur le standard XML, permet de rendre disponiblesdans un annuaire UDDI des services dont les fonctionnalits sont dcrites dansdes fichiers WSDL. Le protocole SOAP permet aux consommateurs dinterrogerlannuaire et dinvoquer le service facilement travers un rseau.Dans le chapitre suivant nous allons voir en dtail, les attaques sur les web

services ; en gnral ; et les attaques par injection en particulier.

17

Chapitre 2

Attaques par injection sur les webservices

2.1 IntroductionUne plateforme base sur les web services est confronte plusieurs types dat-

taques et menaces dus des failles dans la communication (message SOAP) entreles web services. Ces attaques, souvent appeles XML-Based Attacks (les at-taque base XML), exploitent les vulnrabilits de XML tel que : XPath injection,XML-based denial of service (XDoS), XML injection,...etc.Dans ce chapitre nous allons prsent, les attaques par injection en gnral, Il

sagit bien des attaques XPath, XML, SQL et linjection de commandes systmes,on verra par la suite chaque attaque dans les web services, pour cel nous avonsutilis loutil SOAPUI pour tester ses injections sur des web service rels.

2.2 Les vulnrabilits dans les Web ServicesLes Web services sont devenus une partie importante du Web, grce aux avan-

tages quelles offrent, tel que lutilisation des protocoles standards comme XML,SOAP et HTTP. Toutefois, ces caractristiques les rendent vulnrables de nom-breuses menaces de scurit.En gnral, le processus dattaque sur une application consiste dcouvrir, tout

dabord, ses faiblesses et par la suite essayer dy pntrer ;le processus reste lemme pour les web services.Les pirates aujourdhui dcouvrent de nouvelles techniques dattaques, des

niveaux de donnes XML/SOAP. Entre autres, un attaquant peut nuire lascurit, et pntrer dans les systmes, en sappuyant sur la structure des mes-

19

Chapitre 2 Attaques par injection sur les web services

sages SOAP pour dvelopper un modle dattaque pour parvenir ses objectifs[Yaron, 2007].Nous allons voir dans ce qui suit les principales vulnrabilits SOAP/XML.

2.3 Attaques base XML sur les web servicesNous avons vu dans le paragraphe prcdent que les web services sont devenus

de plus en plus vulnrable. Cette vulnrabilit est due en gnral la maniredchange de donnes entre les web services par le protocole SOAP.Lchange de donnes entre web services se fait par le biais du protocole SOAP

qui est un protocole de type requte/rponse, et un mcanisme dchange de don-nes XML travers un protocole de communication http. Cependant SOAP nedfinit aucun mcanisme de scurit, ce qui fait que les messages SOAP sont vul-nrables tre capturs et modifis par un attaquant. Un autre point de moinscontre SOAP ; cest que la plupart des problmes ne concernent pas seulement leprotocole lui-mme mais dautres protocoles utiliss comme http et XML. Nousallons voir quelques problmes et attaques sur XML et SOAP ; dites les attaquesbases 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 dni de services XDOS

2.4 Les attaques de dni de services XDOSUne attaque de type dni de service en anglais Denial Of Service abrge

Dos est un type dattaque visant rendre les services ou les ressources duneorganisation indisponibles pendant un temps indtermin. Cette menace concerneen gnral le fournisseur de service. Il sagit la plupart du temps dattaques lencontre des serveurs dune entreprise, afin quils ne puissent tre utiliss et con-sults.Le principe de lattaque DOS consiste saturer le fournisseur de service, en lui

envoyant des messages XML non valides ; qui peuvent engendrer une rcursivitinfinie en les analysant par le fournisseur [Wells, 2007].Les attaques par dni de service sont un flau pouvant toucher tout serveur

dentreprise, ou tout particulier reli internet. Le but dune telle attaque nestpas de rcuprer ou daltrer des donnes, mais de nuire la rputation de socitsayant une prsence sur internet, et ventuellement de nuire leur fonctionnementsi leur activit repose sur un systme dinformation [CCM, 2014a].Cette classe regroupe les attaques suivantes : Attaque oversize / rcursive :Il sagit dune attaque dpuisement desressources. Cette attaque vise liminer la disponibilit dun service en puisantles ressources du systme du service, comme la mmoire, les ressources detraitement, ou la bande passante du rseau. Une faon classique pour ef-fectuer une telle attaque est dinterroger un service en utilisant un messageSOAP de grande taille [Jensen, 2009].

Attaque dite XML bombe : Une bombe XML est un message composet envoy avec lintention de la surcharge dun analyseur XML (gnralementde serveur HTTP). Les Bombes XML exploitent le fait que XML permet dedfinir des entits. Par exemple, dfinir lentit e1 tre dfinie par 20 entitse2, qui son tour est dfinie de 20 entit e3. Si nous continuons dans lemme schma jusqu e8, lanalyseur XML va analyser une occurrence dee1 et 1 280 000 000 entits e8 prenant 5 Gio de mmoire. Le but ultime decette attaque est de consommer les ressources de lanalyseur XML find decauser un dni de service [SoapUI, 2011].

Attaque par rfrence externe : Au lieu de dfinir des chanes de remplace-ment dentit en tant que constantes, il est galement possible de les dfinirde sorte que leurs valeurs sont extraites des URI externes par ex. < !ENTITYstockprice SYSTEM "http ://www.contoso.com/currentstockprice.ashx">. Lidela plus simple pour cette attaques est denvoyer le parser XML une ressourceexterne qui ne retourne jamais, lenvoyer par ex. une boucle infinie [Bryan, 2009].

Attaque par envoie massif de messages SOAP : Le but de cette attaqueest de surcharger le Web Service par lenvoi des messages SOAP rptitifs. Le

21


message SOAP lui-mme est valide, mais le serveur XML ne peut pas traitertous ces messages envoys en une priode courte, et cela peut provoquer lanon rception des messages SOAP des non attaquants par le Web Service[Radhamani, 2007] .

2.5 Les attaques par injectionLes attaques par injections reprsentent les attaques prdominantes contre les

web services aujourdhui. Ce type dattaque repose sur le problme quil nexisteaucune sparation stricte entre les instructions dun programme et les donnesquy saisit un utilisateur [Lackey, ]. Lorsque les donnes passent sans tre validescorrectement, un utilisateur malveillant peut injecter du code malicieux, dans lebut dextraire ou de modifier des donnes confidentielles.Pour raliser une attaque par injection, il faut russir placer, dans des saisies

classiques, des donnes interprtes comme des instructions. Le succs de lopra-tion repose sur trois lments [Lackey, ] : Identifier la technologie sur laquelle repose lapplication web. Les attaques parinjection dpendent beaucoup du langage de programmation ou du matrielimpliqu.

tablir la liste de toutes les saisies utilisateur possibles. Dans certains cas,elles seront videntes.

Trouver la saisie utilisateur vulnrable.Cette classe dattaques comprend les attaques suivantes ; les plus rpandues ; : Les injections XML Les injections XPath Les inejctions SQL Les injections de commandes systmesOn peut schmatiser la taxonomie des attaques par inejction par la figuresuivante (figure 2.5.1) :

22

2.5 Les attaques par injection

Figure 2.5.1 : Les attaques par injection

2.5.1 Injection XMLLes XML injections sont utiliss pour manipuler le contenu XML. Le but de

cette attaque est denvoyer au serveur des donnes en rentrant par exemple, desinformations didentification contenant des caractres spciaux, qui pourrait nepas tre prisent en charge par lapplication.Voici les diffrentes formes des injections XML :

2.5.1.1 Injection XML simple

Prenons le fichier XML suivant des utilisateurs pour une fonction dauthentifi-cation (login).Le fichier contient lentre suivante avec nom dutilisateur 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" ?>

AliceSecret

Afin dexploiter cette vulnrabilit, on fait entrer des donnes composes demtadonnes comme . La requte peut devenir alors :

Fichier XML des utilisateurs vulnrable < ?xml version="1.0" encoding="ISO-8859-1" ?>

Alice



AliceSecret

Afin dexploiter cette vulnrabilit, on va injecter les balises mal formes :

La requte peut devenir alors :Fichier XML des utilisateurs vulnrable < ?xml version="1.0" encoding="ISO-8859-1" ?>

AliceSecret

On a obtenu donc un code XML Malveillant. Le fait dinsrer les balises malformes bloque, comme dans le type vu prcdem-ment ; les analyseurs des fichiers XML (XML Parser) danalyser ce fichier la prochainefois en indiquant une erreur lors la lecture (error parsing xml).

2.5.1.3 Injection de balises XML automatiques

Il sagit du fait de rajouter une information que lon met soi-mme dans larequte en spcifiant par exemple manuellement son ID, alors quen temps normalil est gnr automatiquement [Stamos, 2005].Lutilisateur fait entrer les donnes de la manire suivante :

Username : Charly0Une fois insre le fichier XML sera de la forme :Injection de balises XML

Charly0Alice

25


Charly aura maintenant un ID de 0 qui pourrait par exemple reprsenter lesadministrateurs. On arrivait donc ajouter un utilisateur au groupe des adminis-trateurs, qui devrait normalement tre secrt.

2.5.1.4 Injection XML Persistante

Cest une simple attaque XML, la diffrence rside quelle est stocke sur le provider et excute par le serveur lorsque la requte est servie [Renaud, 2010].Soit le fichier XML suivant :Fichier XML des utilisateurs et leurs mots de passe< ?xml version="1.0" encoding="ISO-8859-1" ?>

[email protected] Bechar 08000

En utilisant la balisedinclusion xi pour inclure le fichier /etc/passwd desmots de passe des utilisateurs. Le fichier sera alors :


Alice [email protected] Bechar 08000

Aprs lanalyse (parsing) du fichier XML, on aura le rsultat suivant (tableau2.1) :

26


Balise Valeur retourneusername zsmahi

root :x :0 :0 :root :/root :/bin/bashpassword daemon :x :1 :1 :daemon :/usr/sbin :/bin/sh

bin :x :2 :2 :bin :/bin :/bin/shemail [email protected] Becharzip 08000

Table 2.1 : Rsultat danalyse 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 loutil John The Ripper par exemple , on aura tous les mots passe desutilisateurs du serveurs hbergeant ce fichier XML et le web service, y compris lesuper-utilisateur root.

2.5.1.5 Injection XML dans les messages SOAP

Linjection XML est prsente dans les web services qui utilisent un fichier XMLpour sauvegarder les donnes, ceci est un exemple (figure 2.5.2) illustrant un exploitvia un message SOAP :

27


Figure 2.5.2 : Injection XML dans un message SOAP

A travers cet exemple ; nous avons essay dinjecter un code XML mal formqui est : . La rponse ainsi sera la suivante (figure2.5.3) :

Figure 2.5.3 : Rponse du serveur au message SOAP envoy

28


Lanalysur a gnr une erreur lors de lanalyse (parsing) due la balise malforme injecte .

2.5.2 Injection XPathLes documents XML sont devenus de plus en plus compliqus et trop chargs,

cela a conduit dfinir un langage dinterrogation des fichiers XML. Le langagequi a t cr alors est XPath.XPath est un langage de requtes spcialis, qui joue un rle comparable celui

de SQL dans les contextes des bases de donnes. Mais malgr sa simplicit il poseaussi des problmes dinjection (voir Annexe A).Lorsquon choisit de stocker des donnes sensibles en XML plutt que dans

une base de donnes SQL, les attaquants peuvent sappuyer sur une injection deXPath pour contourner une authentification, comme pour inscrire des donnes surle systme distant [Lackey, ].

2.5.2.1 Injection XPath Simple

Le document XML suivant users.xml renferme les numros didentifiants, nomsdutilisateurs et mots de passe employs par un service web [OWASP, 2013b] :

Fichier XML dauthentification des utilisateurs< ?xml version="1.0" encoding="ISO-8859-1" ?>

1Admin xpathr00lz

2testusertest123

Un simple programme peut charger le document XML et recherche le numro di-dentifiant associ au nom dutilisateur et au mot de passe proposs. En supposantque ces valeurs soient respectivement admin et xpathr00lz , la requte XPath seprsenterait comme suit :

//users[username/text()=admin and password/text()=xpathr00lz]/id/ text()

29


On remarquera que cette saisie dutilisateur nest pas chappe dans le codesource de sorte quun attaquant pourra y insrer toute donne ou instruction XPathsouhaite. En choisissant pour mot de passe " or 1=1", la requte deviendraitainsi :

//users[username/text()=admin ]/id/text() and password/text()= or 1=1

Cette instruction renverra le numro correspondant lidentifiant admin et quien outre, soit dispose dun mot de passe vide (cas de figure hautement improbable),soit vrifie "un gale un" ce qui est toujours vrifi. Par consquent, linjection de or 1=1 renvoie lID de ladministrateur sans que lattaquant nait besoin denconnatre le mot de passe.Signalons que XPath est un sous-ensemble dun langage XML de requtes plus

large, appel XQuery. Comme XPath et SQL, ce dernier souffre de problmesdinjection comparables.Voici un exemple dun script perl vulnrable cette attaque (Algoritme 2.1) :

Algorithme 2.1 Script Perl vulnrable linjection XPath# !/usr/bin/perluse 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 successful\n" ; }else { print "Authentication failed\n" ; }

Ce script lis le nom dutilisateur et le mot de passe donns comme paramtres(ARGV[0] et ARGV[1]) et intrroge les fichier XML via une requte XPath, lavulnrabilit rside dans le fait quil est possbile dinjecter la chane vulnrable or 1 = 1 aprs le mot de passe, donc lexpression $expr va contenir la valeur :

//user[username=\$login\ and password=\$pass\ or 1 = 1]

le code sera excut et le rsultat sera vrai toujours ; cela permet de rcuprerles utilisateurs enregistrs comme dcrit prcdemment.

30


2.5.2.2 Dumping dun Document XML

Le Dumping se fait laide de loprateur| [Renaud, 2010].Cet oprateur est : Loprateur identique UNION mais plus flexible. Effectue des oprations squentielles. Exploite labsence de restrictions daccs aux parties dun document.

2.5.2.2.1 Utilisation dans une injection XPath

La requte de description dun 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 ncessite une connaissance pralable de lexpression.

2.5.2.3 Blind XPath Injection

Le Blind XPath Injection a t introduite pour la 1re fois en 2004 par AmitKLEIN [Klein, 2005], elle permet de rcuprer lintgralit du document XML,sans connaissance de lexpression XPath.

2.5.2.3.1 Mode opratoire

1. Trouver une injection standard2. Remplacer le prdicat 1=1 par une expression E dont le rsultat est binaire3. E est utilis pour valuer : Chaque bit du nom ou de la valeur dun lment Le nombre dlments de chaque type (lment, texte, PI etc.)

2.5.2.3.2 Contraintes

Lent (-la Brute Force) Dmontr mais pas dimplmentation disponible

2.5.2.4 Injection XQuery

XPath est un sous-ensemble dun langage de requte sous XML plus large, quiest XQuery, et que ce dernier lui aussi souffre dun grand problme de scurit etplus prcisment problme des injections [WEBAPPSEC, 2010].Linjection XQuery est une variante de la fameuse attaque injection SQL :

31


Elle utilise les mauvaises donnes passes une requte XQuery pour traverseset excuter les routines XQuery.

Elle peut tre utilise pour lister les lments dun environnement victime,injecter des commandes en local ou excuter des commander distance.

Un attaquant peut injecter des requtes XQuery dans un message SOAP pourmanipuler un document XML au niveau du fournisseur du service web.

Lexemple suivant montre comment interroger le fichier users.xml afin de rcuprerla liste des utilisateurs.

doc(users.xml)//user[name=*]

Il existe plusieurs formes des injections XQuery quon ne peut pas listes toutes,cependant elles sont toutes dues la non vrification des champs de saisie avantlenvoi de la requte.

2.5.2.5 Injection XPath dans les messages SOAP

Linjection XPath est prsente dans les web services qui utilisent un fichier XMLpour sauvegarder les donnes, ceci est un exemple (figure 2.5.4) illustrant un exploitvia un message SOAP ; o on a inject la chane vulnrable or 1 = 1 or a =a :

Figure 2.5.4 : Injection XPath dans un message SOAP

32


Le web service recevra ainsi une requte XPath malveillante de lister tous lesutilisateurs et leurs mots de passe, la rponse est la suivante (figure 2.5.5) :

Figure 2.5.5 : Rponse du service web : lister tous les (username,password)

2.5.3 Injection SQLLes injections SQL consistent insrer ou injecter du code SQL via des don-

nes entres par lutilisateur lapplication. un exploit russi dune injectionSQL peut lire donnes sensibles depuis la base de donnes, modifier ces donnes(Insertion/Mise--jour/Suppresion), xecuter des oprations dadministration de labase de donnes (ex. Arrter le SGBD), rcuprer le contenu dun fichier prsentdans le systme de fichiers du SGBD, ou dans certains cas xecute des commandesdu systme dexploitation [OWASP, 2014b].Les injections SQL sont un type dattaques par injection, dont cest le code SQL

qui est inject dans le champ de saisie fain dxecuter une commande SQL biendfinie.Il existe plusieurs formes dinjections SQL, qui sont :

2.5.3.1 Manipulation du SQL

Cest la forme la plus commune, lattaquant essaye de modifier le code SQLexistant en ajoutant des lments la clause WHERE ou tendre la requte SQLpar des oprations comme UNION, MINUS ou INTERSECT. Il existe bienvidemment dautres formats mais ceux sont les plus rpandus et les plus frquents[Scambray, 2006].

Exemple 01

La manipulation de SQL la plus classique est durant une fonction dauthentifi-cation login . Une application web ou un service web vrifie lauthentificationde lutilisateur en xecutant la requtes suivante et vrifiant si des lignes sontretournes ou pas.

Requte SQL pour authentificationSELECT * FROM usersWHERE username = zsmahi and password = mypassword

33


Lattaquant essayera alors de manipuler le code SQL pour lxecuter de cettefaon

Requte SQL pour authentificationSELECT * FROM usersWHERE username = zsmahi and password = mypassword or a = a

La clause WHERE est vraie pour chaque ligne et le pirate obtient laccs total lapplication.

Exemple 02

Loprateur UNION est souvent utilis dans les injections SQL. Le but est demanipuler SQO afin de retourner des enregistrement dune autre table. Un exempledune telle requete :

Requte SQL typiqueSELECT product_name FROM all_productsWHERE product_name like %Chairs%

un pirate tentera de manipuler SQL afin dxecuter cette requte :Requte SQL avec injection UNIONSELECT product_name FROM all_productsWHERE product_name like %Chairs%UNIONSELECT username FROM dba_usersWHERE username like %

Cette requte retourne non seulement les noms des produits mais aussi tous lesnoms dutilisateurs.

2.5.3.2 Injection de Code

Linjection de code essaye dajouter du code SQL ou bien des commandes au codecode SQL existant. Ce type dattaques est utilis frquement utilis contre le SGBDMicrosoft SQL Server et rarement avec Oracle. Linstruction EXECUTE dansSQL Server est une cible frquente des attaques par injection SQL [Kost, 2004].

Requte SQL avec injection UNIONSELECT * FROM usersWHERE username = zsmahi ans password = mypassword ; DELETEFROM users WHERE username =admin ;

Nota que cette faille nest disponible que dans un certains nombre de langagesde programmation et de API qui autorisent lxecution de plusieures requtes SQL la fois.

34


2.5.3.3 Injection des appels de fonctions

Linjection des appels de fonctions est linsertion des fonctions de la base de don-nes Oracle ou des fonctions spciales dans un code SQL vulnrable [Kost, 2004].Ces appels sont utiliss pour faire des appels systmes ou bien pour manipuler lesdonnes de la base.En utilisant les standards des fonctions Oracle, lattaquant peut envoyer des

informations depuis la base de donnes jusqu un Serveur (ou PC) distant ouxecuter dautres attaques depuis le serveur de la base de donnes. Plusieurs pa-quetages des base de donnes Oracle peuvent tre exploit par un attaquant. Cespaquetages peuvent inclure des fonctions pour changer les mots de passes ou f-fectuer dautres transactions sensibles.Le problme avec ce type dinjections est que nimporte quelle requte SQL

gnre automatiquement, mme la requte la plus simple peut tre exploite.Les dveloppeurs dapplications utilisent des fois des fonctions de bases de don-

nes au lieu du native code (ex. Java) pour effectuer des tches courantes. Unexemple trs courant et qui vient tout de suite lesprit cest bien la fonctionTRANSLATE qui na pas dquivalant en Java, donc le programmeur dcidedutiliser les requtes SQL la place.Lexemple suivant montre la fonction translate et comment on peut lutiliser

pour effecuter un exploit dinjection SQL :Requte SQL TRANSLATESELECT TRANSLATE(user input,0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ,0123456789)FROM dual ;

Cette requte nest pas vulnrable aus types vues prcdemment mais elle estfacilement manipule via une injection dappel de fonction, on peut la modifierpour xecuter le code suivant :

Injection dAppel de fonction dans la requte TRANSLATESELECT TRANSLATE(|| UTL_HTTP.REQUEST(http ://192.168.1.1/)|| ,0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ,0123456789)FROM dual ;

La nouvelle requte SQL va intrroger une page depuis un serveur web. Lat-taquant peut manipuler la chane et lURL pour inclure autres fonctions finde rechercher des informations utiles depuis le serveur de la base de donnes etlenvoyer au serveur web via lURL. Cette faille peut tre utilise pour attaquerdautres serveurs et web services dans le rseau interne.

35


Des fonctions particulires et les fonctions de paquetages particuliers peuventaussi tre xecutes. Un exemple est une application avec une fonction ADDUSER(ajouter utilisateur) dans le paquetage MYAPPADMIN. Le dveloppeur a mar-qu la fonction avec PRAGMA TRANSACTION une fonctionnalit des bases dedonnes Oracle qui permet lapplication dcrire la base de donnes mme avecune requte SQL.

Injection dAppel de fonctionSELECT TRANSLATE(|| myappadmin.adduser(admin,newpass)|| ,0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ,0123456789)FROM dual ;

Executer la requte prcdente permet mme dajouter un utilisateur admin avec le mot de passe newpass .

2.5.3.4 Blind SQL Injection

Le Blind SQL Inejction est un type dinjections SQL, qui intrroge la base dedonnes travers des requtes vrai/faux (true/false) et dtrmine la rponses basesur les rponses dapplication. Cette attaque figure souvent lorsquune applicationest configure pour afficher des messages derreurs gnriques et nindique pas quilya une vulnrabilit aux injections SQL [OWASP, 2013a].Quand un attaquant exploite une injection SQL, des fois le service web ; ou

lapplication web en gnral ; affiche des messages derreurs indiquant une erreurdans la syntaxe SQL. Le Blind SQL Injection est similaire linjection SQL simple ;la diffrence rside dans la manire que les donnes sont rcupres depuis la basede donnes.Une base de donnes qui naffiche pas les donnes dans une rponse (message

SOAP, page web, API ...etc.) force les pirates voler les donnes en interrogeantla base par une srie de questions vrai/faux, ceci met lexploit plus difficile maispas impossible.Il existe plusieurs formes de cette attaque,

2.5.3.4.1 Blind bas sur le contenu (Content-Based)

lURL http ://newspaper.com/items.php ?id=2 envoie la requte suivante :

SELECT title, description, body FROM items WHERE ID = 2

Le pirate essayera dinjecter une requte qui retourne false (faux) :

http ://newspaper.com/items.php ?id=2 and 1=2

36


Maintenat la requte est :

SELECT title, description, body FROM items WHERE ID = 2 and 1=2

Si lapplication est vulnrable aux injections SQL, alors il est probables quellene fait retourner rien. Pour sassurer le pirate tente dinjection une requte quiretourne true :

http ://newspaper.com/items.php ?id=2 and 1=1

Si le contenu de la page qui retourne true est diffrent de celui de false alorslattaquant est capable de distinguer quand la requt fait retourner vrai ou faux.Une fois vrifie, les seuls limitations sont les privilges faites par ladministrateurde la base de donne, la syntaxe SQL et limagination et le savoir-faire du pirate.

2.5.3.4.2 Blind bas sur le temps dattente (Time-Based)

Elle est base sur les appels dattente de chaque SGBD pour indiquer lxecutionavec succs de la requte. Lattaquant numre chaque lettre de la rponse dsireen suivant cette logique : Si la 1ere lettre du 1er nom de la base de donnes est A : pause de 10 sec. Si la 1ere lettre du 1er nom de la base de donnes 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 nest pas, en gnral, facile exploiter mais en mme temps il estpossible de lexploiter, tout dpendera de lexprimentation du pirate.

2.5.3.5 Injection SQL dans les messages SOAP

Linjection SQL est prsente dans les web services. Lexemple (figure 2.5.4) suiv-ant illustre comment lexploiter via un message SOAP : Voir figure suivante (figure2.5.6) o on a inject la chane vulnrable OR 1 = 1 :

37


Figure 2.5.6 : Injection SQL dans un message SOAP

Le web service recevra ainsi une requte SQL malveillante pour tout lister, larponse est la suivante (figure 2.5.7) :

Figure 2.5.7 : Rponse SOAP linjection SQL

38


2.5.4 Injection de commandes OSLinjection de commandes du systme (OS) ou plus communement linjection de

commande est un type dinjection ou lobjectif est dxecuter des commandes sur lamachine hte via une application vulnrable. Cette injection est possible lorsquuneapplication passe des donnes vulnrables entres par lutilisateur( cookies, en-ttesHTTP ...etc.) au shell du systme[Lackey, ]. Les commandes systmes envoyessont souvenet excutes avec les privilges de lapplication vulnrable. Linjectionde commande est due labsence ou linsuffisance de validation de donnes delinput [OWASP, 2014a].Ci-dessous un code en langage C qui est vulnrable cette injection

Algorithme 2.2 Code C vulnrable linjection de commandes#include #include 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 dautre quimprimer le contenu dun fichier pass comme1er argument en utilisant la commande cat de UNIX. On lxecute comme suit :

$ ./commandeCat fichier.txt

Le rsultat est :

Ceci est le contenu du fichier fichier.txt

xecutons le mme programme cette fois-ci en remplaons le paramtre fichier.txtpar fichier.txt ; ls ; rappelons que la commande ls sert lister le contenu dunrpertoire.Le rsultat sera alors cette fois-ci (tableau 2.2) :

RsulatCeci est le contenu du fichier fichier.txt fichier.txt ; unAutreFichier.txt ; unRepertoire

Table 2.2 : Exemple dinjection de commande

Linjection de commande est prsente frquement dans les services web qui pro-posent des services rseaux tel que le ping et le traceroute.

2.5.4.1 Injection de commandes OS dans les messages SOAP

Linjection de commandes est prsente dans les web services. Lexemple (figure2.5.8) suivant illustre comment lexploiter via un message SOAP dans un serviceweb qui propose des ping :

Figure 2.5.8 : Injection Commandes dans un message SOAP

40


On a inject la chane ; cat /etc/passwd pour lister le fichier des mots depasse des utilisateurs du serveur hbergeant le web service. La rponse a t lasuivante (figure 2.5.9) ; on a pu effectu le ping et en plus on a list le fichierpasswd :

Figure 2.5.9 : Injection Commandes dans un message SOAP

41


2.6 ConclusionLes Web Services sont de plus en plus dploys sur lInternet en raison de leurs

protocoles normaliss, et des techniques qui permettent lintgration efficace desapplications faiblement couples sur les rseaux. Toutefois, en raison de linterfaceouverte pour une architecture oriente services, les attaques contre les systmesaxs sur les Web Services sont plus compliques que les attaques classiques quipeuvent tre traites par des pare-feu traditionnels. Ainsi, il est ncessaire dintro-duire de nouveaux mcanismes de scurit pour protger les systmes axs sur lesWeb Services.Nous allons vois dans le chapitre suivant les principaux travaux qui ont t faites

afin de scuriser les web services contre les attaques par injection.

42

Chapitre 3

Approches de scurisation des webservices

3.1 IntroductionNous avons vu prcdemment que les web services sont confronts un certain

nombre dattaques qui visent les dtruire. Malheureusement ces attaques ne sontpas prises par les outils de protection, existants tel que les pare-feu.Pour assurer une protection effective et relle des web services, les pare-feu

XML ont t introduits comme extension des pare-feu actuels et comme approchede scurisation des web services.On verra dans cette section cest quoi un pare-feu XML et quels sont les recherches

effectues dans ce domaine ainsi les solutions proposes.

3.2 Firewall XMLLes pare-feu XML (XML firewall en anglais) est une nouvelle technologie intro-

duite afin de scuriser les web services contre les attaques. Avant dintroduire lanotion dun pare-feu XML, nous rappelons la notion de pare-feu.

3.2.1 Pare-feu (Firewall en anglais)Cest est un systme qui assure la protection dun ordinateur, ou un rseau

dordinateurs des incursions provenant dun rseau internet. Il sagit dun systmede filtrage des paquets de donnes changes avec le rseau[Xu, 2008].Les pare-feux sont gnralement mis en uvre pour bloquer et restreindre cer-

tains accs et implmenter les rgles de la politique de scurit [Cheswick, 2003].

43

Chapitre 3 Approches de scurisation des web services

3.2.2 Pare-feu XMLIl est particulirement appropri pour neutraliser les actes malveillants contre

les Web Services. Il utilise les informations de scurit contenues dans chaquemessage chang, pour scuriser les diffrentes parties dun message SOAP chang[Ayachit, 2006].Ainsi ; Il est compatible aux diffrents protocoles de transport, et renforce les in-

sertions de scurit des messages de services, de port ou dopration [CCM, 2014b].Actuellement, on a la tendance dutiliser le terme XML Security Gateway pour

les XML Firewall, car on attend de ces pare-feu un travail plus quun conventionnelpare-feu[Patterson, 2007].La figure suivante (figure 3.2.1) montre un systme bas sur les web services

protgs par un pare-feu XML[Xu, 2008] :

Figure 3.2.1 : Systme bas sur les web services protg par un pare-feu XML

3.3 Les approches de scurisation des web servicesAfin de scuriser un web service plusieurs travaux et recherches ont t effectues

proposant chacune une architecture dun systme de scurisation (XML Firewall).Nous allons dans cette section introduire les diffrentes approches et les mthodes.Avant dentammer les approches de scurit, rappelons la notion des expressions

rgulires et de la distance de Khi-2.

3.3.1 Les expressions rguliresUne expression rgulire ou rationnelle est une chane de caractres (appelle

parfois un motif ) qui dcrit un ensemble de chanes de caractres possibles selon

44

3.3 Les approches de scurisation des web services

une syntaxe prcise. Les expressions rgulires sont issues des thories mathma-tiques des langages formels des annes 1940. Leur puissance dcrire des ensemblesrguliers explique quelles se retrouvent dans plusieurs domaines scientifiques dansles annes daprs-guerre et justifie leur adoption en informatique. Les expressionsrationnelles sont aujourdhui utilises par les informaticiens dans ldition et lecontrle de texte ainsi que dans la manipulation des langues formelles que sont leslangages de linformatique[Desgraupes, 2008].

Exemples

Voici quelques exemples des expressions rgulires les plus utilises (tableau 3.1)[loribel, 2003] :

caractres Signification. nimporte quel caractre

(123.5 => 123.5, 12345...etc.)? le caractre prcdent ? est optionnel

(12 ?34 => 1234, 134...etc.)* le caractre prcdent * peut tre rpt 0 ou plusieurs fois

(12*34 => 134, 1234, 12234, 122234...etc)+ le caractre prcdent * peut tre rpt 1 ou plusieurs fois

12+34 => 1234, 12334, 12222234...etc. mais ne trouvera pas 134$ le carcatre est la fin dune ligne

toto$ => toute ligne finissant pas toto

Table 3.1 : Exemples expressions rgulires

3.3.2 Test du Khi-2 2

Le test du Khi2 (khi deux ou khi carr) fournit une mthode pour dterminerla nature dune rpartition, qui peut tre continue ou discrte. Il est utilis dansdiffrents domaines tels que la comparaison des chantillons, Recherche de liaisonentre les donnes ou Recherche de linfluence dune donne autre que celle tudie[Zerrouk, 2011].Principe : Formuler H0 (la distribution observe nest pas diffrente de la distributionsuppose daprs la loi que lon souhaite tester).

Rpartir les donnes en classes. Dterminer le nombre de degrs de libert partir du nombre de classes. Fixer un risque de se tromper (la valeur 5 % est souvent choisie par dfaut).

45


Calculer algbriquement la distance entre les ensembles dinformations com-parer.

Dterminer Khi-2 thorique (dduire la distance critique laide dune tablede 2 ).

Conclure si cette distance est suprieure la distance critique (on conclut quele rsultat nest pas d seulement aux fluctuations dchantillonnage).

Une statistique de khi-2 entre une distribution observe et une distribution atten-due se calcule comme celui-l (Algorithme 3.4) :

Algorithme 3.1 Distance de Khi-2D2(O,E)=Ni=1 (OiEi)2Ei

Dans cette formule D2(O,E) est la distance Khi-2 2 entre une distributionobserve O et un rsultat attendue E ( souvent un dataset extrait partir dunephase dapprentissage) et N-1 est le degr de libert du test de 2.La distance D2 calcul et le degr de libert N-1(cas dun test dajustement) sont

utiliss pour obtenir une valeur p de la table 2. La valeur p indique la probabilitde la distribution observe pour tre compatible avec la distribution attendue.La distance D2 est compare un seuil 2(,N-1) (( est gnralement pris 0.05

(ou erreur 95%) , 2(,N-1) est le seuil de dcision pour une distribution 2avec un degr de libert de N-1.) Deux hypothses sont poses alors H0 et sonalternative H1 : H0 : D2 > 2(,N-1) H1 : D2 2(,N-1)

H0= {les i chantillons sont issus dune seule population}Contre H1 = {les i chantillons sont issus de deux populations diffrentes}

Procdure de lecture partir de La table Khi-2

On calcule dabord la distance de Khi-2 (formule Algorithme 1.4). On cherche cette valeur dans la table (Figure 3.3.1) pour un degr de libertprcis ( les lignes de la table).

Une fois trouve (ou bien un voisinage de la valeur est trouv) on remonte la valeur trouv en colonne qui reprsente une valeur p de probabilit.

la valeur p est compare au seuil dfini au pralable et on dcide dadmettreou de rejet lhypothse nulle H0.

46

3.3 Les approches de scurisation des web services

Figure 3.3.1 : Table de Khi-2

47


3.3.3 Les approches base de signaturesCes approches sont les plus anciennes et les plus basiques. Elles consistent

rechercher dans les messages SOAP entrants les empreintes ou les signature dat-taques connues. Cette approches a t utilise dans les IDS (Intrusion DetectionSystem) et dans les antivirus.

3.3.3.1 Avantages :

Un firewall XML utilisant cette approche est facilement conu et dveloppeet maintenu par la suite.

Il permet galement une classification relativement facile de la criticit desattaques signales.

3.3.3.2 Inconvnients :

Lincovnient majeur de cette approche est quelle est limite, un firewallXML utilisant cette approche est purement ractif, il ne peut dtcter que lesattaques dont il possde dj la signature, de ce fait, il ncessite des mises jour quotidiennes.

Un autre inconvnient de cette approche est quelle est bonne que lest labase de signature, si les signatures sont errones ou incorrectement conues lesystmes est inefficace, cest pourquoi ces systmes sont souvent contournspar les pirates qui utilisent des techniques dvasion qui consistent camouflerles attaques utilises. Ces techniques de camouflage ont tendance faire varierles signatures des attaques qui ainsi ne sont par reconnues par le firewall XML.

Les signatures sont souvent reprsentes par des formats compacts tel que les ex-pressions rgulires. Ci-dessous (tableau 3.2) quelques expressions rgulires util-ises afin de bloquer quelques attaques par injection [Mookhey, 2004] :

Inejction Expression rgulires , ## /(\%27)|(\)|(\-\-)|(\%23)|(#)/ix or /\w*((\%27)|(\))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix exec /exec(\s|\+)+(s|x)p\w+/ix

Table 3.2 : Signature de quelques attaques par inejction (cas injection SQL)

3.3.4 Les approches probabilistesNous avons dfini prcdement ; la 1re approche utilise afin de scuriser les

web services contre les attaques par injection (lapproche par signature), et ses

48

Securisation des web services soap contre les attaques par injection

Documents

Transcript of Securisation des web services soap contre les attaques par injection