Mémoire de fin d’études 
Pour l’obtention du diplôme d’Ingénieur d’Etat en Informatique 
Option : Systèmes Informatiques (...
Dédicaces 
À ceux qui ont sacrifié une partie de leur vie pour me voir grandir et 
réussir, ceux qui m’ont toujours souten...
Remerciements 
Au terme de ce travail je tiens tout d’abord à remercier Allah le tout 
puissant de m’avoir donné la foi, l...
Résumé 
Les Web Services sont des applications basées sur XML qui fournissent une 
infrastructure pour décrire (WSDL), déc...
Abstract 
Web Services are XML-based applications that provide infrastructure for de-scribing 
(WSDL), discovering (UDDI) ...
Table des matières 
Dédicaces i 
Remerciements iii 
Résumé v 
Abstract vii 
Table des matières ix 
Table des figures xv 
L...
TABLE DES MATIÈRES 
1.4 Technologies des Web Services . . . . . . . . . . . . . . . . . . . . . 9 
1.4.1 XML (eXtensibleMa...
TABLE DES MATIÈRES 
2.5.4 Injection de commandes OS . . . . . . . . . . . . . . . . . . 39 
2.5.4.1 Injection de commandes...
TABLE DES MATIÈRES 
4.6 Fichier de configuration . . . . . . . . . . . . . . . . . . . . . . . . 71 
4.7 Journal des évène...
TABLE DES MATIÈRES 
5.4.4.2 Interface globale du Panneau d’administration . . . 93 
5.4.4.3 Interface Profils des web serv...
TABLE DES MATIÈRES 
Annexes 127 
A Le langage XPath 129 
A.1 La forme d’une expression XPath . . . . . . . . . . . . . . ....
Table des figures 
1.4.1 Structure générale d’un fichier WSDL . . . . . . . . . . . . . . . . 11 
1.4.2 Description du fon...
TABLE DES FIGURES 
4.7.1 Structure d’un fichier journal . . . . . . . . . . . . . . . . . . . . . 72 
4.7.2 Structure d’un...
Liste des tableaux 
2.1 Résultat d’analyse du fichier XML . . . . . . . . . . . . . . . . . . 27 
2.2 Exemple d’injection ...
LISTE DES TABLEAUX 
6.20 AUC méthode subscribe cas 10000 messages . . . . . . . . . . . . 113 
D.1 Injections SQL les plus...
Liste des algorithmes 
2.1 Script Perl vulnérable à l’injection XPath . . . . . . . . . . . . . . . 30 
2.2 Code C vulnéra...
Liste des abréviations 
API Application Programming Interface 
AUC Area Under Curve 
DNS Domain Name System 
FW FireWall 
...
Introduction Générale 
Cadre général et objectifs 
Un web service est un composant applicatif mis à la disposition d’autre...
Introduction Générale 
malveillant. 
A travers cette solution nous visons à créer un scénario d’une plateforme basée 
sur ...
– Chapitre 5 intitulé « Réalisation » : on détaillera ici la mise en oeuvre de la 
solution proposée dans la deuxième part...
É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 seuleme...
Chapitre 1 Les web services SOAP 
terface described in a machine-processable format (specifically WSDL). 
Other systems in...
1.3 Caractéristiques des Web services 
L’interface masque les détails du service, ce qui permet de l’utiliser indépendam-m...
Chapitre 1 Les web services SOAP 
– La sécurité des services Web, obtenue essentiellement grâce à des protocoles 
d’authen...
1.4 Technologies des Web Services 
le fichier WSDL est un fichier XML qui peut être divisé en deux parties, la 
première p...
Chapitre 1 Les web services SOAP 
SOAP, développé par IBM et Microsoft, est une recommandation W3C qui le 
définit comme é...
1.4 Technologies des Web Services 
1.4.3.3 Caratéristiques du protocole SOAP 
– SOAP repose sur le langage XML. 
– C’est u...
Chapitre 1 Les web services SOAP 
Figure 1.4.3 : Structure du message SOAP 
Voici un exemple d’un message SOAP pour une mé...
1.5 Fonctionnement des web services 
1.4.4 UDDI (Universal Description Discovery and Integration) 
« UDDI est la spécifica...
Chapitre 1 Les web services SOAP 
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 ...
Chapitre 2 
Attaques par injection sur les web 
services 
2.1 Introduction 
Une plateforme basée sur les web services est ...
Chapitre 2 Attaques par injection sur les web services 
sages SOAP pour développer un modèle d’attaque pour parvenir à ses...
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 servic...
Chapitre 2 Attaques par injection sur les web services 
message SOAP lui-même est valide, mais le serveur XML ne peut pas ...
2.5 Les attaques par injection 
Figure 2.5.1 : Les attaques par injection 
2.5.1 Injection XML 
Les XML injections sont ut...
Chapitre 2 Attaques par injection sur les web services 
Fichier XML des utilisateurs et leurs mots de passe 
?xml version=...
2.5 Les attaques par injection 
Fichier XML des utilisateurs et leurs mots de passe 
?xml version=1.0 encoding=ISO-8859-1 ...
Chapitre 2 Attaques par injection sur les web services 
Charly aura maintenant un ID de 0 qui pourrait par exemple représe...
2.5 Les attaques par injection 
Balise Valeur retournée 
username zsmahi 
root :x :0 :0 :root :/root :/bin/bash 
password ...
Chapitre 2 Attaques par injection sur les web services 
Figure 2.5.2 : Injection XML dans un message SOAP 
A travers cet e...
2.5 Les attaques par injection 
L’analysur a généré une erreur lors de l’analyse (parsing) due à la balise mal 
formée inj...
Chapitre 2 Attaques par injection sur les web services 
On remarquera que cette saisie d’utilisateur n’est pas échappée da...
2.5 Les attaques par injection 
2.5.2.2 Dumping d’un Document XML 
Le Dumping se fait à l’aide de l’opérateur‘|’ [Renaud, ...
Chapitre 2 Attaques par injection sur les web services 
– Elle utilise les mauvaises données passées à une requête XQuery ...
2.5 Les attaques par injection 
Le web service recevra ainsi une requête XPath malveillante de lister tous les 
utilisateu...
Chapitre 2 Attaques par injection sur les web services 
L’attaquant essayera alors de manipuler le code SQL pour l’éxecute...
2.5 Les attaques par injection 
2.5.3.3 Injection des appels de fonctions 
L’injection des appels de fonctions est l’inser...
Chapitre 2 Attaques par injection sur les web services 
Des fonctions particuliéres et les fonctions de paquetages particu...
2.5 Les attaques par injection 
Maintenat la requête est : 
SELECT title, description, body FROM items WHERE ID = 2 and 1=...
Chapitre 2 Attaques par injection sur les web services 
Figure 2.5.6 : Injection SQL dans un message SOAP 
Le web service ...
2.5 Les attaques par injection 
2.5.4 Injection de commandes OS 
L’injection de commandes du système (OS) ou plus communem...
Chapitre 2 Attaques par injection sur les web services 
Ce code ne fait rien d’autre qu’imprimer le contenu d’un fichier p...
2.5 Les attaques par injection 
On a injecté la chaîne « ; cat /etc/passwd » pour lister le fichier des mots de 
passe des...
Chapitre 2 Attaques par injection sur les web services 
2.6 Conclusion 
Les Web Services sont de plus en plus déployés sur...
Chapitre 3 
Approches de sécurisation des web 
services 
3.1 Introduction 
Nous avons vu précédemment que les web services...
Chapitre 3 Approches de sécurisation des web services 
3.2.2 Pare-feu XML 
Il est particulièrement approprié pour neutrali...
3.3 Les approches de sécurisation des web services 
une syntaxe précise. Les expressions régulières sont issues des théori...
Chapitre 3 Approches de sécurisation des web services 
– Calculer algébriquement la distance entre les ensembles d’informa...
3.3 Les approches de sécurisation des web services 
Figure 3.3.1 : Table de Khi-2 
47
Chapitre 3 Approches de sécurisation des web services 
3.3.3 Les approches à base de signatures 
Ces approches sont les pl...
3.3 Les approches de sécurisation des web services 
insuffisances. Dans cette section nous présentons une autre approche q...
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Securisation des web services soap contre les attaques par injection
Prochain SlideShare
Chargement dans…5
×

Securisation des web services soap contre les attaques par injection

1 624 vues

Publié le

Securisation des web services soap contre les attaques par injection

0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 624
Sur SlideShare
0
Issues des intégrations
0
Intégrations
12
Actions
Partages
0
Téléchargements
122
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Securisation des web services soap contre les attaques par injection

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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.3 Graphe de variations de FP et FN cas 5000 messages . . . . . . . 106 6.4.4 Courbe de ROC pour la méthode login cas 5000 messages . . . . . 106 6.4.5 Graphe de variations de FP et FN cas 10000 messages . . . . . . . 108 6.4.6 Courbe de ROC pour la méthode login cas 10000 messages . . . . 108 6.4.7 Graphe de variations de FP et FN cas 1000 messages . . . . . . . 110 6.4.8 Courbe de ROC pour la méthode subscribe cas 1000 messages . . 110 6.4.9 Graphe de variations de FP et FN cas 5000 messages . . . . . . . 112 6.4.10 Courbe de ROC pour la méthode subscribe cas 5000 messages . . 112 6.4.11 Graphe de variations de FP et FN cas 10000 messages . . . . . . . 114 6.4.12 Courbe de ROC pour la méthode subscribe cas 10000 messages . . 114 A.1 Le modèle XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 xvi
  14. 14. 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.6 Taille et Temps Génération du Vecteur moyen cas 5000 messages . 105 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.12 Taille et Temps Génération du Vecteur moyen cas 1000 messages . 109 6.13 Taux de F.Ps et F.Ns cas 1000 messages . . . . . . . . . . . . . . . 109 6.14 AUC méthode subscribe cas 1000 messages . . . . . . . . . . . . . 109 6.15 Taille et Temps Génération du Vecteur moyen cas 5000 messages . 111 6.16 Taux de F.Ps et F.Ns cas 5000 messages . . . . . . . . . . . . . . . 111 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. – 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
  21. 21. Étude bibliographique « Once you stop learning, you start dying » (Albert EINSTEIN)
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. Chapitre 1 Les web services SOAP – 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
  26. 26. 1.4 Technologies des Web Services 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
  27. 27. Chapitre 1 Les web services SOAP 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
  28. 28. 1.4 Technologies des Web Services 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
  29. 29. Chapitre 1 Les web services SOAP 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
  30. 30. 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
  31. 31. Chapitre 1 Les web services SOAP Figure 1.5.1 : Les principaux acteurs dans un web service 16
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. Chapitre 2 Attaques par injection sur les web services 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
  37. 37. 2.5 Les attaques par injection 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
  38. 38. Chapitre 2 Attaques par injection sur les web services 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 » ?xml version=1.0 encoding=ISO-8859-1 ? users user usernameAlice/username passwordSecret/password /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
  39. 39. 2.5 Les attaques par injection 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 va injecter les balises mal formées : xmljoke/xml/joke La requête peut devenir alors : Fichier XML des utilisateurs « vulnérable » ?xml version=1.0 encoding=ISO-8859-1 ? users user usernameAlicexmljoke/xml/joke/username passwordSecret/password /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 ?xml version=1.0 encoding=ISO-8859-1 ? users user usernameCharly/usernameID0/IDusernameAlice/username /user /users 25
  40. 40. Chapitre 2 Attaques par injection sur les web services 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 : Fichier XML des utilisateurs et leurs mots de passe ?xml version=1.0 encoding=ISO-8859-1 ? users user usernameAlice/username passwordSecret/password 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 : Fichier XML des utilisateurs et leurs mots de passe ?xml version=1.0 encoding=ISO-8859-1 ? users user usernameAlice/username 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
  41. 41. 2.5 Les attaques par injection 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
  42. 42. Chapitre 2 Attaques par injection sur les web services 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
  43. 43. 2.5 Les attaques par injection 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 ?xml version=1.0 encoding=ISO-8859-1 ? 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
  44. 44. Chapitre 2 Attaques par injection sur les web services 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
  45. 45. 2.5 Les attaques par injection 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
  46. 46. Chapitre 2 Attaques par injection sur les web services – 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
  47. 47. 2.5 Les attaques par injection 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
  48. 48. Chapitre 2 Attaques par injection sur les web services 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
  49. 49. 2.5 Les attaques par injection 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/’)|| ’, ’0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ’, ’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
  50. 50. Chapitre 2 Attaques par injection sur les web services 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’)|| ’, ’0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ’, ’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
  51. 51. 2.5 Les attaques par injection 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
  52. 52. Chapitre 2 Attaques par injection sur les web services 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
  53. 53. 2.5 Les attaques par injection 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
  54. 54. Chapitre 2 Attaques par injection sur les web services 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
  55. 55. 2.5 Les attaques par injection 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
  56. 56. Chapitre 2 Attaques par injection sur les web services 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
  57. 57. 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
  58. 58. 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
  59. 59. 3.3 Les approches de sécurisation des web services 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
  60. 60. Chapitre 3 Approches de sécurisation des web services – 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
  61. 61. 3.3 Les approches de sécurisation des web services Figure 3.3.1 : Table de Khi-2 47
  62. 62. Chapitre 3 Approches de sécurisation des web services 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
  63. 63. 3.3 Les approches de sécurisation des web services 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

×