Sec Des Services Web

Projet de semestre – Sécurité des services web

Jonathan Rod

Rapport Projet de semestre de Jonathan Rod, EIT6 Ecole d’ingénieurs du Canton de Vaud - 2003

Mandaté par : Contact :

e-Xpert Solutions SA Sylvain Marret

Professeur responsable : Chargé de cours responsable :

Stefano Ventura Christian Buchs

Page 1 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Table des matières : 1

INTRODUCTION ............................................................................................................................................ 5

2

MOTIVATIONS............................................................................................................................................... 5

3

DÉFINITIONS.................................................................................................................................................. 5 3.1 3.2 3.3

4

SÉCURITÉ .................................................................................................................................................... 5 SÉCURITÉ INFORMATIQUE ........................................................................................................................... 5 SERVICES WEB............................................................................................................................................. 5

SIMPLE OBJECT ACCESS PROTOCOL (SOAP).................................................................................... 6 4.1 4.2 4.3 4.4

5

AUTHENTIFICATION DU MESSAGE ............................................................................................................... 6 SIGNATURE DU MESSAGE ............................................................................................................................ 7 ENCRYPTION DU MESSAGE .......................................................................................................................... 7 APPLICATION............................................................................................................................................... 7

SERVICE WEB SOAP .................................................................................................................................... 8 5.1 SITUATION ................................................................................................................................................... 8 5.2 INFRASTRUCTURE ..................................................................................................................................... 11 5.3 SÉCURISATION .......................................................................................................................................... 11 5.3.1 « All-in-One »................................................................................................................................... 11 5.3.2 « Classique » .................................................................................................................................... 12 5.3.3 Election............................................................................................................................................. 13

6

PLATEFORMES............................................................................................................................................ 13 6.1 IPCOP ........................................................................................................................................................ 13 6.1.1 Introduction ...................................................................................................................................... 13 6.1.2 Motivation ........................................................................................................................................ 14 6.1.3 Installation........................................................................................................................................ 14 6.1.4 Configuration ................................................................................................................................... 14 6.1.5 Tests .................................................................................................................................................. 14 6.1.6 Vulnérabilité..................................................................................................................................... 14 6.1.7 Conclusion........................................................................................................................................ 14 6.2 APACHE ..................................................................................................................................................... 14 6.2.1 Introduction ...................................................................................................................................... 14 6.2.2 Motivation ........................................................................................................................................ 15 6.2.3 Installation........................................................................................................................................ 15 6.2.4 Configuration ................................................................................................................................... 15 6.2.5 Tests .................................................................................................................................................. 15 6.2.6 Conclusion........................................................................................................................................ 15

7

WEB SERVICE SECURITY ........................................................................................................................ 15

8

DESCRIPTION DU FIREWALL SOAP .................................................................................................... 16 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9

9 10

MOTIVATIONS ........................................................................................................................................... 16 BUTS.......................................................................................................................................................... 16 FONCTIONNALITÉS .................................................................................................................................... 16 IMPLÉMENTATION ..................................................................................................................................... 16 COMPORTEMENT ....................................................................................................................................... 16 SPÉCIFICATIONS ........................................................................................................................................ 18 POLITIQUE DE SÉCURITÉ............................................................................................................................ 18 CYCLE DE VIE ............................................................................................................................................ 18 CONCLUSION ............................................................................................................................................. 18

CONCLUSION ............................................................................................................................................... 19 BILAN.......................................................................................................................................................... 19

Page 2 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

11

RÉFÉRENCES ........................................................................................................................................... 20

12

ANNEXE 1 : SIMPLE OBJECT ACCESS PROTOCOL..................................................................... 21

12.1 DÉFINITION ............................................................................................................................................... 21 12.1.1 Services web ..................................................................................................................................... 21 12.1.2 Appel à distance de procédure......................................................................................................... 21 12.1.3 SOAP (Simple Object Access Protocol) .......................................................................................... 21 12.2 INTRODUCTION À SOAP ........................................................................................................................... 21 12.2.1 SOAP & XML ................................................................................................................................... 22 12.2.2 Messages SOAP................................................................................................................................ 22 12.2.3 Fautes SOAP .................................................................................................................................... 24 12.2.4 Modèle d’échange de message......................................................................................................... 24 12.2.5 Réaliser un service web « RPC »..................................................................................................... 25 12.2.6 Encodage des données - Terminologie ............................................................................................ 26 12.2.7 Types de donnée ............................................................................................................................... 28 12.2.8 Transport des messages SOAP ........................................................................................................ 28 12.3 CONCLUSION ............................................................................................................................................. 29 12.4 RÉFÉRENCE ............................................................................................................................................... 29 13

ANNEXE 2 : WS-SECURITY .................................................................................................................. 30

13.1 MOTIVATION ............................................................................................................................................. 30 13.2 INTRODUCTION .......................................................................................................................................... 30 13.3 APPLICATION DE WS-SECURITY ............................................................................................................... 30 13.4 ENTÊTE SOAP VERSION WS-SECURITY ................................................................................................... 31 13.5 PARAMÈTRES SUPPLÉMENTAIRES ............................................................................................................. 31 13.6 AUTHENTIFICATION .................................................................................................................................. 32 13.6.1 Username / password....................................................................................................................... 32 13.6.2 X.509 Certificats............................................................................................................................... 33 13.6.3 Kerberos ........................................................................................................................................... 33 13.7 SIGNATURE................................................................................................................................................ 33 13.8 ENCRYPTION ............................................................................................................................................. 34 13.9 CONCLUSION ............................................................................................................................................. 36 13.10 RÉFÉRENCE ........................................................................................................................................... 36 14

TUTORIAL : MISE EN PLACE D’UN SERVICE WEB SOAP ......................................................... 37

14.1 BUT ........................................................................................................................................................... 37 14.2 INTRODUCTION .......................................................................................................................................... 37 14.3 DEPLOIEMENT DE APACHE SOAP SUR UN SYSTEME WINDOWS XP ........................................................ 37 14.3.1 Serveur d’application : Tomcat ....................................................................................................... 37 14.3.2 Application web: SOAP ................................................................................................................... 39 14.3.3 Déploiement d’un service de démo.................................................................................................. 40 14.3.4 Ecoute du dialogue SOAP................................................................................................................ 42 14.4 MISE EN PLACE DU CLIENT ........................................................................................................................ 45 14.5 CONCLUSION ............................................................................................................................................. 45 14.6 RÉFÉRENCE ............................................................................................................................................... 45 15 PLANNING ET OBJECTIFS PROJET DE SEMESTRE & OBJECTIFS TRAVAIL DE DIPLÔME ............................................................................................................................................................... 46 15.1 15.2 15.3 16

PLANNING DU PROJET DE SEMESTRE ......................................................................................................... 46 OBJECTIFS DU PROJET DE SEMESTRE ......................................................................................................... 47 OBJECTIFS DU TRAVAIL DE DIPLÔME ........................................................................................................ 48 ANNEXE 3 : SÉCURITÉ DES APPLICATIONS WEB (AVORTÉ).................................................. 49

16.1 INTRODUCTION .......................................................................................................................................... 49 16.2 CAHIER DES CHARGES ............................................................................................................................... 49 16.3 ANALYSE DES MENACES SPECIFIQUES AUX APPLICATIONS WEB .............................................................. 49 16.3.1 Unvalidated Parameters (paramètres invalides) ............................................................................ 49 16.3.2 Broken Access Control (perte du contrôle d’accès)........................................................................ 50

Page 3 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

16.3.3 Broken Account And Session Management (perte de contrôle de la gestion des acomptes et des sessions) 50 16.3.4 Cross-Site Scripting (XSS) Flaws .................................................................................................... 50 16.3.5 Buffer Overflows (surcharge d’un tampon)..................................................................................... 51 16.3.6 Command Injection Flaws (Faille d’injection de commande)........................................................ 51 16.3.7 Error Handling Problems (problèmes de gestion d’erreur) ........................................................... 51 16.3.8 Insecure Use Of Cryptogrsphy (utilisation non-sécurisé de la cryptographie) ............................. 52 16.3.9 Remote Administration Flaws (contrôle à distance des outils d’administration) .......................... 52 16.3.10 Web And Application Server Misconfiguration (incohérence entre les configurations de l’application et du serveur) .............................................................................................................................. 52

Page 4 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

1 Introduction Le but de ce rapport est de fournir les prérequis pour permettre l’implémentation d’un firewall applicatif SOAP pour le protocole http durant un travail de diplôme. Les grandes étapes de cette préparation sont : - l’étude du Simple Object Access Protocol (SOAP) - la mise en place d’un service web SOAP (client, serveur) - la recherche de la plateforme pouvant accueillir le firewall - l’étude de Web Service Security Des résumés portant sur SOAP et WS-Security ainsi qu’un tutorial sur la mise en place d’un service SOAP ont été rédigé. Ils sont fournis en annexe de ce rapport.

2 Motivations Les services web prennent aujourd’hui une grande place dans le monde d’Internet. On pourrait dire qu’il s’agit d’une nouvelle mode en quelque sorte. Ils donnent la possibilité de relier un environnement informatique distribué, en assurant une communication totalement neutre entre les différentes entités du système. Leur premier but est donc d’introduire l’homogénéité entre applications. L’échange d’information de manière transparente et l’invocation de procédures distantes sont permis grâce à l’utilisation des services web. Dans ces deux cas, des données sensibles peuvent être transmises sur un réseau non sûr. Il est donc nécessaire d’introduire une politique de sécurité propre aux services web, afin de permettre leurs utilisations dans n’importent quel condition. Ce rapport porte donc sur l’établissement de la sécurité dans le monde des services web. En passant par la prise en main et la compréhension des différents protocoles et plateformes utilisés.

3 Définitions 3.1 Sécurité « Tranquillité d’esprit de celui qui pense qu’aucun danger n’est à craindre » (réf. Dictionnaire Hachette Encyclopédique, 1998)

3.2 Sécurité informatique Ensemble de mesures visant à assurer la sécurité des utilisateurs de matériel informatique. Les concepts de base dans ce domaine sont l’authentification, l’intégrité et la confidentialité.

3.3 Services web Un service web est une interface réseau permettant l’accès aux fonctionnalités d’une application via des technologies Internet. Autrement dit: si une application est accessible via un réseau utilisant des protocoles comme http, XML, SMTP, etc., il s’agit en fait d’un service web. Ces services web sont accessibles via des applications de service qui permettent de publier, gérer, et rechercher des informations. Ces mécanismes sont accessibles au travers de protocoles et de format de données standardisés comme http et html. La majorité des services web sont actuellement déployés sous la forme de site web html sur Internet. Le client du service web sera un simple utilisateur d’un navigateur qui reconnaisse les standards utilisés par le service. IBM et Microsoft ont déjà adopté le concept des services web. IBM intègre des supports de services web dans WebSphere, Tivoli, DB2, et Lotus. Alors que la nouvelle plateforme de développement .NET de Microsoft est basée sur les services web.

Page 5 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

4 Simple Object Access Protocol (SOAP) Le standard des services web qui concerne l’échange de message passe par le métalangage XML. Ce dernier a été formalisé et standardisé pour donner naissante au Simple Object Access Protocol (SOAP). Ce protocole a été définit pour permettre l’échange de documents et les appels de procédures distantes. Il utilise des protocoles de transport comme http, https, smtp, ftp, etc. Les messages SOAP sont construits de manière rigide. Les données à transmettre sont contenues dans le corps du message, alors que l’entête de ce dernier définira la manière dont le message doit être traité: transfert, encryptage, signature, etc. Voir résumé en annexe portant sur SOAP On voit tout de suite que SOAP peut nous permettre une grande rigueur dans l’application de la sécurité. Il est simple de fixer un gabarit de message « sécurisé » et de l’appliquer à toutes les communications faites par le service web et ses clients. Dans ce gabarit de message, on peut décider d’assurer : L’authentification et/ou l’intégrité et/ou la confidentialité

4.1 Authentification du message La façon la plus simple d’authentifier un message est d’ajouter à son entête un bloque contenant un nom d’utilisateur et un mot de passe (username + password). Il sera alors facile au récepteur de comparer ces informations avec celles contenues dans une base de données par exemple. Il est clair que cette solution est incomplète, puisque le mot de passe circule en clair sur le réseau. Il est donc relativement facile pour un hacker de se le procurer. Afin de résoudre ce problème, on peut faire transiter un hash du mot de passe. Le déroulement de cette opération sera le suivant : - l’envoyeur du message génère un hash de son mot de passe à l’aide d’une fonction de hachage - l’envoyeur met dans un bloque de l’entête de son message son nom d’utilisateur et le hash de son mot de passe - le message est envoyé - le récepteur recherche le mot de passe grâce au nom d’utilisateur reçu - le récepteur génère le hash du mot de passe trouvé - le récepteur compare les deux hashs Si le récepteur ne reconnaît pas le nom d’utilisateur ou si les hashs sont différents, alors le message est ignoré.

Envoyeur

Récepteur

Fonction de hachage XY

Fonction de hachage XY Msg SOAP

password

Entête - login - hash

hash (ex. 128bits) Corps

password trouvé hash (ex. 128bits) XOR

Si 0 msg ok

Figure 0 : authentification du message SOAP

Page 6 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Les conditions pour effectuer ce type d’authentification sont: - la même fonction de hachage doit être utilisée par l’envoyeur et le récepteur - la communication du mot de passe au récepteur doit être faite de manière sécurisée Cette solution pour l’authentification sera implémentée dans le firewall

4.2 Signature du message La même méthode que celle vue pour l’authentification peut être utilisée pour signer le message et ainsi garantir son intégrité. Dans ce cas, on hash le corps du message et on ajoute le résultat dans un bloque de l’entête du message. Le récepteur doit à nouveau générer un hash et le comparer à celui reçu.

4.3 Encryption du message Pour garantir la confidentialité du message, l’encryptage doit être utilisé. Pour faciliter cette étape, une solution d’encryptage symétrique paraît être la meilleure solution. Au lieu de transmettre les données en clair dans le message, on encrypte le corps du message. Le récepteur devra utiliser une clé secrète pour décrypter le message et ainsi avoir accès à son contenu. Comme pour l’authentification, une condition pour utiliser ce type d’encryptage (symétrique) est que la clé soit transmise au récepteur de manière sécurisée. Cette solution pour la confidentialité sera implémentée dans le firewall

4.4 Application La mise en place d’un service web utilisant SOAP paraît être la meilleure façon d’appliquer le protocole. L’infrastructure nécessaire est constituée d’un client et d’un serveur. Il est possible d’implanter les deux sur une même machine, toutefois l’utilisation de deux ordinateurs est nécessaire si l’on veut par la suite placer un firewall au milieu. Voir tutorial en annexe portant sur la mise en place d’un service web SOAP L’utilisation de ApacheSOAP et du serveur d’application Tomcat permet de gagner du temps pour la mise en place d’un service. De plus ApacheSOAP fournit des exemples de service qui permettent de tester facilement le fonctionnement du système complet. Il existe également un tunnel servant à visualiser les messages SOAP. Pour illustrer et vérifier le fonctionnement du firewall par la suite, il sera nécessaire de créer un service web qui utilise les solutions adoptées ci-dessus. Toutefois cette opération s’annonce longue et compliquée.

Page 7 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

5 Service web SOAP Ce chapitre présente les différents aspects d’un service web SOAP

5.1 Situation Diagramme représentant une problématique typique des services web

Utilisateur Client utilisant un navigateur Commande transport : Yverdon – New York

Agence de voyage Site web proposant des offres de voyage. Client de différents services web

Commande : Genève – New York

Commande transport : Yverdon - Genève

Compagnie aérienne (Swiss) Service web SOAP

Transport Ferroviaire (CFF) Service web SOAP

Figure 1 : problématique grossière

L’agence de voyage propose au client des offres de transport entre différentes villes. Elle dispose bien sûr d’une base de données contenant les conditions et tarifs de ces différentes offres, mais elle a également besoin d’accéder aux informations des compagnies avec lesquels elle travaille pour valider ces offres.

Page 8 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Voici le diagramme détaillé d’une partie de la figure 1:

Utilisateur

SGBD (Oracle)

Session Commande

Client SOAP

Produit

Agence de voyage

Internet

Compagnie aérienne

Serveur SOAP

Note : La partie interface entre l’utilisateur et l’agence de voyage n’est pas détaillée.

Gestion des vols

Figure 2 : problématique plus détaillée

Dans ce diagramme, on voit avec plus de précision dans quels mesures et conditions le service web SOAP va être mis à contribution.

Page 9 / 52

10/07/2003

SGBD (Oracle)

Projet de semestre – Sécurité des services web

Jonathan Rod

Voici maintenant le même diagramme avec l’incorporation d’un firewall SOAP :

Utilisateur

SGBD (Oracle)

Session Commande

Client SOAP

Produit

Agence de voyage

Internet

Compagnie aérienne

FW SOAP

Note : La partie interface entre l’utilisateur et l’agence de voyage n’est pas détaillée.

Serveur SOAP

Gestion des vols

Figure 2 : problématique plus détaillée

Cette incorporation d’un firewall est préliminaire à cette étape de l’établissement, mais elle permet une prévisualisation de la solution bientôt abordée.

Page 10 / 52

10/07/2003

SGBD Oracle

Projet de semestre – Sécurité des services web

Jonathan Rod

5.2 Infrastructure Exemple d’infrastructure (coté serveur) : (correspondant à l’infrastructure qui peut être mise en place en suivant le tutorial sur la mise en place d’un service web SOAP en annexe) Serveur d’application : Tomcat (en standalone) API Java de parsing XML : Xerces API SOAP d’Apache : ApacheSOAP

Tomcat Serveur web Client

Serveur d’application RPCRouterSrvlet

http

Services :

XML parser

Figure 3 : diagramme de l’infrastructure SOAP

Déroulement d’une invocation (hypothèse : le service demandé est déjà déployé): - le client construit une requête SOAP - le client envoi la requête SOAP en utilisant le protocole de transport http - le serveur web reçoit la requête SOAP, l’identifie comme tel, et le transmet au RPCRouterServlet - le RPCRouterServlet doit identifier le service invoquer par la requête SOAP, pour se faire il fait appel au XML parser - le RPCRouterServlet invoque le service demandé - le RPCRouterServlet génère la réponse SOAP à l’aide des informations fournies par le service - le RPCRouterServlet transmet la réponse SOAP au serveur web - le serveur web envoi la réponse SOAP au client en utilisant le protocole de transport http - le client reçoit la réponse SOAP, l’identifie comme tel

5.3 Sécurisation Dans la section « Situation » (figure 2), on a vu une notion de firewall apparaître. Ce firewall, dont les spécifications seront traitées plus loin, est là pour répondre aux motivations du chapitre 2. C'est-à-dire pour permettre aux services web d’échanger n’importe quelles données sans avoir à se soucier des problèmes de sécurité. Deux principales infrastructures sont à envisager pour mettre en place une notion de sécurisation du service web. La première est une solution à priori facile à mettre en place et économique. La deuxième est deux fois plus lourde en terme de matériel, mais est sans doute plus fiable.

5.3.1 « All-in-One »

5.3.1.1 Description de l’infrastructure coté serveur : Serveur web : Serveur d’application : API Java de parsing XML : API SOAP d’Apache :

Apache Tomcat Xerces ApacheSOAP

Page 11 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Client

http

Serveur web Apache

Jonathan Rod

Tomcat RPCRouterSrvlet

+ Module Firewall SOAP

Services :

XML parser

Figure 4 : diagramme de l’infrastructure « All-in-One »

5.3.1.2 Avantages -

pas besoin de machine supplémentaire économie de temps (pas besoin de configurer la machine supplémentaire)

5.3.1.3 Inconvénients -

besoin d’une machine puissante (faire tourner : un serveur web, un serveur d’application avec plusieurs services activés, un module firewall. Les deux derniers ayant besoin de faire du parsing) firewall et serveurs dans la même machine, si l’un tombe l’autre tombe aussi mauvais en terme de sécurité!

5.3.2 « Classique »

5.3.2.1 Description de l’infrastructure coté serveur : Serveur d’application : Tomcat (en standalone) API Java de parsing XML : Xerces API SOAP d’Apache : ApacheSOAP Plus une deuxième machine avec, comme proposition de plateforme : - un module firewall SOAP tournant sous un serveur web Apache OU - une fonctionnalité supplémentaire de firewall SOAP tournant sous un système complet dédié à la sécurité comme IpCop

Page 12 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Client

Serveur web Apache + Module Firewall SOAP

http

Jonathan Rod

Tomcat RPCRouterSrvlet Services :

OU IpCop

XML parser

Figure 5 : diagramme de l’infrastructure « Classique »

5.3.2.2 Avantages -

pas besoin de machine puissante chaque machine est indépendante

meilleure sécurité

5.3.2.3 Inconvénients -

besoin d’une machine supplémentaire configuration complète d’une nouvelle machine nécessaire

5.3.3 Election L’aspect « si l’un tombe l’autre tombe aussi » de la première solution suffit à l’éliminer d’office. La deuxième infrastructure sera donc choisie pour l’implémentation du firewall.

6 Plateformes L’implémentation du firewall devra se faire sur une plateforme existante. Le choix de cette dernière se fera selon les critères suivants : - possibilité d’extension de la plateforme - documentation sur le plateforme - utilisation de la plateforme sur le marché actuel

6.1 IpCop 6.1.1 Introduction « IPCop met en oeuvre des techniques existantes, des pratiques de programmation sûres et les concepts émergents pour en faire ‘la’ distribution Linux apte à protéger le simple ordinateur personnel jusqu'aux grands réseaux d'entreprises contre les intrusions et les attaques. Que ce soit pour votre habitation ou bien votre SOHO (Small Office/Home Office), IPCop s'adapte à vos besoins. » (réf. www.ipcop.org)

Page 13 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

6.1.2 Motivation Le choix de cette plateforme vient du fait que : • Le support (hardware) qu’elle demande est très léger • C’est un produit Open Source (basé sur Linux) • La documentation est disponible en quantité sur le site officiel d’IpCop • La plateforme propose déjà une palette de fonctionnalités typiques de firewall

6.1.3 Installation La dernière version disponible est la 1.3.0 avec deux correctifs à télécharger en plus. Cette version a pu être installée sur une machine de test (P166 CPU, 128M RAM, 2GB HDD), mais n’était hélas pas fonctionnelle (impossible de lancer le système). La version 1.2.0 (avec cinq correctifs) n’a posé aucun problème.

6.1.4 Configuration La configuration du firewall (et des autres fonctionnalités) se fait grâce à une interface html au travers de n’importe quel navigateur. Le protocole de transport utilisé est sécurisé, il s’agit de https.

6.1.5 Tests Toutes les fonctionnalités (NAT, ouverture / redirection de port, serveur DHCP, serveur SSH, proxy, etc.) ont été testées avec succès. La sécurité du système (firewall, IDS, etc.) est confirmée par différents tests disponibles via Internet, comme par exemple « Symantec Security Check » du logiciel Norton SystemWorks.

6.1.6 Vulnérabilité A priori (test à réaliser) une vulnérabilité pourrait venir de la génération des logs. IpCop garde tous les logs et ne les compresse qu’une fois par semaine. Il serait donc possible de littéralement remplir la partition du disque dur réservée aux logs pour faire tomber la machine entière.

6.1.7 Conclusion IpCop est une excellente solution pour les gens disposant d’un SOHO à protéger. Il offre une gamme de fonctionnalités réellement intéressante et ne demande qu’un ordinateur dédié. Toutefois, il serait beaucoup trop compliqué d’ajouter une fonctionnalité dans ce système. En plus de la rigueur de sa programmation, l’aspect interface de configuration le rend inabordable.

6.2 Apache 6.2.1 Introduction Apache est le serveur web le plus répandu sur Internet (plus de 50% du marché). Ses concurrents directs sont: Microsoft IIS, Microsoft PWS, Xitami, etc.. Fonctionnant à la base sur des systèmes Unix, il est aujourd’hui (depuis 1998) disponible sur une multitude de plateforme dont celles de Microsoft. Apache (prononcé à l’anglophone : « Apatchy ») a été mis au point sur la base d’une multitude de correctifs logiciels, afin d’en faire une solution très sûre. Le résultat est une application ayant très peu de failles connues, puisque dès qu’une faille ou d’un bug est décélé, celui-ci est rapidement corrigé par l’arrivée d’une nouvelle version.

Page 14 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

6.2.2 Motivation Le choix de cette plateforme vient du fait que : • Le support (hardware) qu’elle demande est très léger. • C’est un produit Open Source. • La documentation est disponible en quantité sur le site officiel de l’Apache Software Foundation. • L’application Apache est réputée très sûre • L’ajout de module est courant et bien documenté • L’écriture de ces modules est documentée

6.2.3 Installation Les versions 1.3.27 et 2.0.46 s’installent sans problème sur une machine sous Windows 2000. Le lancement du serveur se fait simplement grâce à un script créé lors de l’installation.

6.2.4 Configuration

6.2.4.1 Version 2.0.46 Cette version, pourtant réputée pour être la « ninth public release of Apache 2.0 », se révèle totalement inutilisable dès lors que l’on veut mettre en place des nouveaux modules (existants, mais pas activés). Après de nombreux essais et des recherches sur la résolution de ce problème, cette version a dû être abandonnée.

6.2.4.2 Version 1.3.27 Cette version, évidemment plus ancienne, a été sortie principalement pour corriger les bugs et les failles de sécurité Un module proxy a pu être mis en fonction sans aucune difficulté.

6.2.5 Tests Les tests réalisés sont quasiment nuls. On peut simplement dire que le serveur web fonctionne et le proxy aussi.

6.2.6 Conclusion Apache paraît être une meilleure solution. Il s’agit ici d’une simple application et non plus d’un système complet comme IpCop. De plus l’aspect modulaire pour l’ajout d’une fonction supplémentaire annonce des possibilités de « débuggage » facilités. L’argument ultime en sa faveur est tout simplement sa popularité. Puisque le nombre de personne susceptible de connaître et résoudre un éventuel problème est énorme.

7 Web Service Security La spécification WS-Security porte sur l’ensemble (ou presque) des assertions de sécurité qu’il est possible de faire avec SOAP, tout en utilisant les dernières technologies et standards du monde de la sécurité informatique. Cette spécification permet d’atteindre un niveau de sécurisation très élevé si elle est suivie dans son intégralité. Toutefois la lourdeur du système obtenu le rendrait sans doute inutilisable! Voir résumé en annexe portant sur WS-Security Il est très important de se souvenir que par la nature même de SOAP et des services web, WS-Security définit une sécurité « end-to-end ». Soit une sécurité d’utilisateur à utilisateur. Les solutions adoptées plus loin font toutes parties du WS-Security.

Page 15 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

8 Description du firewall SOAP L’infrastructure choisie pour l’implantation du firewall est celle de la figure 5. Une machine dédiée sur laquelle tournera un système d’exploitation (encore à définir: Windows 2000 ou Linux) et un serveur web Apache.

8.1 Motivations Une question : Pourquoi un firewall pour contrôler une sécurité « end-to-end » ??? Première raison : La sécurité « end-to-end » n’est plus une sécurité qui dépend d’une infrastructure figée mise à disposition. Elle dépend de chaque utilisateur ou client de cette infrastructure. Un portable ajouté à cette dernière, mais qui ne serait pas configuré selon les normes de sécurité en vigueur représenterait une menace (cas plutôt évident coté client). Pour éviter ce cas de figure, on empêche tout simplement les informations non conformes d’arriver jusqu’aux clients. Grâce par exemple à un « filtrage » effectué sur un firewall. protection du réseau contre ses propres utilisateurs (et leurs naïvetés) prévention Deuxième raison : La sécurité « end-to-end » peut se révéler lourde à gérer par un client. Dans ce cas, un firewall pourrait effectuer une partie du travail pour soulager le client. Ou simplement éviter que le client effectue un travail pour rien en faisant un contrôle préventif. soulagement du travail du client (serveur) Troisième raison : Il est plus simple de centraliser les correctifs et autres modifications de sécurité à une seule place au lieu de les appliquer à plusieurs endroits. Par exemple dans le cas où plusieurs serveurs seraient derrière un seul firewall. efficacité rapidité de mise en place d’une protection (sous la forme d’un update ou d’une règle supplémentaire)

8.2 Buts Assurer l’authenticité, l’intégrité et la confidentialité des messages SOAP Empêcher les attaques (flooding, pillage de données, etc.)

8.3 Fonctionnalités -

inspecter chaque requête pour sécuriser les transactions vérifier la conformité des messages par rapport à un schéma XML (gabarit) utiliser des informations (locales ou distantes) pour authentifier l’appelant, vérifier son authenticité et l’intégrité du message - détecter les schémas d’attaque (flooding, pillage de données, etc.) - blocage d’IP Note : dans le blocage d’IP, on peut soit bloquer des adresses identifiées comme dangereuses (réaction), soit autoriser uniquement les adresses connues (prévention).

8.4 Implémentation L’implémentation se fera sous la forme d’un module Apache. Ecrit en langage « C », ce module travaillera en « standalone » (pas d’accès distant à une base de données, etc.) et contiendra donc toutes les informations d’authentification, etc. dont il a besoin.

8.5 Comportement Le firewall devra accepter uniquement: - les requêtes jugées conformes - les messages correspondant au schéma XML fixé - les messages dont l’authentification ET l’intégrité ET la confidentialité seront confirmés - les messages dont le contenu sera jugé conforme Seuls les messages répondant à ces quatre critères seront transmis au service concerné, les autres seront rejetés (dénie par défaut).

Page 16 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Voici le diagramme qui illustre le comportement du firewall SOAP lors de la réception d’une requête:

Firewall SOAP Requête « POST /soap/servlet/rpcrouter HTTP/1.0 » Contrôle de la requête POST, Host, etc.

Enveloppe SOAP Entête du message SOAP Identité Username + hash (password)

Contrôle du schéma XML du message Authenfication (basée sur username ): Rechercher username dans BD locale Rechercher password dans BD locale Générer le hash du password trouvé si (hash reçu XOR hash généré) =0 alors Authenfitication OK

Signature hash (message) Encryption message - type d’encryption

Intégrité : Générer le hash du message reçu si (hash reçu XOR hash généré) =0 alors Intégrité du message OK

Corps du message SOAP

Confidentialité : Contrôler que le message a été encrypté Contrôle du contenu : Après décryptage (clé dans BD locale) Figure 6 : comportement lors de la réception d’une requête

Page 17 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

8.6 Spécifications En plus des sections sur le comportement, les fonctionnalités et l’implémentation ci-dessus, on peut ajouter qu’un firewall SOAP doit pouvoir monter rapidement en charge et y rester (plusieurs milliers de messages gérés par seconde). Ce ne sera bien sûr pas le cas du firewall qui va être implémenté par la suite (matériel peu performant, algorithmes non optimisés, etc.). On peut ajouter que la fonctionnalité de blocage d’IP sera sans doute implémentée en appliquant également une politique de dénie par défaut. Donc en autorisant dans un premier temps uniquement les adresses « reconnues » à accéder aux services.

8.7 Politique de sécurité Un service web met à disposition de l’information pure, contrairement à un site web qui lui la mélange avec de la présentation. Cette différence fait d’un service web une cible beaucoup plus intéressante pour un hacker. Lors de l’établissement de la politique de sécurité, on doit donc tenir compte de cette différence. D’ailleurs à ce stade, l’analyse de risque a déjà dû démontrer que les conséquences de l’intrusion d’un service web sont plus grandes que celles du serveur web en terme de confidentialité en tout cas.

8.8 Cycle de vie Comme tout composant dans le domaine de la sécurité de l’information, on ne peut pas l’installer et le laisser tourner sans s’en occuper. Une réévaluation de ses fonctionnalités et de sa capacité est nécessaire pour garantir une sécurité durable. Voici le cycle correspondant aux besoins du firewall :

Planifier

Réaliser

Contrôler

Agir

Figure 7 : cycle de vie du firewall SOAP

Toutefois, cette possibilité de mise à jour du firewall ne sera pas implémentée dans un premier temps pour des raisons de temps à disposition.

8.9 Conclusion L’implémentation de ce firewall et son incorporation dans un réseau sécurisé permettra effectivement d’augmenter le niveau de sécurité globale. En empêchant par exemple qu’un ordinateur n’échappe aux solutions de sécurité adoptée pour les services web SOAP. La charge de travail du serveur (client) se situant derrière le firewall ne sera pas diminuée, mais le risque de gaspillage de temps dû aux traitements de messages non autorisés disparaît. Hélas, la possibilité de mettre à jour le firewall rapidement grâce à l’installation d’update ou de patch ne sera pas mise en place. Car beaucoup trop lourd. Les buts du point de vue de la sécurité sont tous atteints, puisque : - l’authentification - l’intégrité - la confidentialité sont assurés par le firewall. L’aspect « identification » d’attaques et réaction se limitera dans un premier temps aux contrôles des requêtes et du contenu. Le message identifié comme « attaque » ne sera pas accepté.

Page 18 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

9 Conclusion Les services web sont une solution réelle et abordable pour résoudre les problèmes des systèmes distribués sur Internet. Le protocole SOAP permet de briser les limites fixées par les environnements en s’appuyant sur des standards fonctionnels et existants. La mise en place d’un service web SOAP complet est envisageable par une majorité d’informaticien. Puisque le langage clé, XML, fait déjà partie du bagage d’une majorité de gens dans cette profession. On peut donc déjà parier sur un développement considérable dans ce domaine. De plus le protocole SOAP permet une grande rigueur dans la conception des messages. On a donc à disposition un protocole permettant l’application « simplifiée » de la sécurité dans un domaine nouveau et voué à un avenir prometteur. Le firewall SOAP est une première solution pour fournir un niveau de sécurité élevé dans le domaine des services web. Son utilisation conjointe à celle d’une sécurité « end-to-end » donne un résultat très sécurisant. Les spécifications fixées par une note comme WS-Security sont lourdes et complexes à mettre en place. Les solutions adoptées dans ce rapport sont bien plus abordables, et de ce fait, envisageables pour la suite de ce projet. De plus le choix d’une application existante et vivante comme Apache pour la base d’implémentation rend ce projet raisonnable.

10 Bilan Ce projet de semestre m’a permis d’assimiler un grand nombre de concept clé de la télécommunication et de la sécurité des systèmes d’information. Concernant le travail fourni, je ne m’attendais pas à devoir passer autant de temps dans mon cours « Réseaux et télécommunications ». J’ai maintenant atteint un niveau suffisant pour assimiler certains concepts que j’avais dû prendre comme acquis lorsque j’ai commencé ce projet. Le cahier des charges fixé lors de la dernière rencontre avec Messieurs Buchs, Marret et Ventura sera respecté (reste la partie présentation à mettre en place). Travail manquant pour le travail de diplôme : - création d’un service web qui applique le schéma de message SOAP vu à la figure 6 - recherche des algorithmes de hachage et d’encryption qui vont être utilisé par le service web (et donc par le firewall) La recherche d’information sur Internet concernant la sécurité des services web donne un grand nombre de réponses. Toutefois, pour la suite de mon travail il serait sans doute préférable d’acheter un livre sur le sujet. Je propose : - « Web services security » de Mark O’Neil publié par McGraw-Hill Osborne Media en janvier 2003 (ISBN 0072224711) - « Professionnal Web Services Security » de Trivedi, Whitney, Galbraith, Janakinaman, etc. publié par Wrox Press inc en décembre 2002 (ISBN 1861007655) Concrètement, je crois être arrivé au bout de la problématique, en ciblant extrêmement mon travail sur SOAP. Et en restant très abstrait sur certains sujets qui m’auraient pourtant passionnés (XML Encryption, les fonctions de hachage, etc.). Vous trouverez le planning de ce projet et ces objectifs, ainsi que les objectifs du travail de diplôme en annexe de ce rapport. Vous y trouverez également un document portant sur la « Sécurité des applications web » que j’ai rédigé avant la répartition du travail sur ce projet, j’ai abandonné sa rédaction.

Page 19 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

11 Références Voir références des annexes http://www.builder.fr/ http://soapclient.com/ http://jakarta.apache.org/ http://www.commentcamarche.com/

Yverdon-les-bains, le 10 juillet 2003

Jonathan Rod, EIT6

Page 20 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

12 Annexe 1 : Simple Object Access Protocol 12.1 Définition Ce chapitre donne les différentes définitions pré requises pour aborder la suite de ce document.

12.1.1

Services web

Un service web est une interface réseau permettant l’accès aux fonctionnalités d’une application via des technologies Internet. Autrement dit: si une application est accessible via un réseau utilisant des protocoles comme http, XML, SMTP, etc., il s’agit en fait d’un service web. Ces services web sont accessibles via des applications de service qui permettent de publier, gérer, et rechercher des informations. Ces mécanismes sont accessibles au travers de protocoles et de format de données standardisés comme http et html. La majorité des services web sont actuellement déployés sous la forme de site web html sur Internet. Le client du service web sera un simple utilisateur d’un navigateur qui reconnaisse les standards utilisés par le service. IBM et Microsoft ont déjà adopté le concept des services web. IBM intègre des supports de services web dans WebSphere, Tivoli, DB2, et Lotus. Alors que la nouvelle plateforme de développement .NET de Microsoft est basée sur les services web.

12.1.2

Appel à distance de procédure

Il existe deux types de middleware pour les appels à distance de procédure: ORB & RPC. Ces deux systèmes de transmission de messages inter-programmes ont des spécificités bien différentes. - ORB (Object Request Broker): ce middleware, orienté objet, permet au client de faire appel à des méthodes mises à disposition par le serveur. Le problème de ce type d’implémentation est que le client attend durant le traitement de la méthode par le serveur. - RPC (Remote Procedure Call): un processus client envoie un message au serveur. L’application client continue à tourner, mais suspend le processus appelant. Une fois le traitement terminé, le serveur envoie un message au client pour réveiller le processus suspendu. SOAP est un middleware de ce type.

12.1.3

SOAP (Simple Object Access Protocol)

SOAP est un middleware qui permet l’invocation d’application sur des réseaux distribués et décentralisés. C’est un protocole d’échange sur lequel Microsoft a basé son architecture .NET. A la base SOAP est une note du consortium W3. Le but de SOAP est de permettre l’appel à distance de procédure (Remote Procedure Call), et donc de définir via des réseaux des services web. Les protocoles utilisés par SOAP sont http, SMTP ou encore POP3. Ils lui permettent d’effectuer une paire de message requête – réponse via un réseau. Les messages SOAP se base sur un langage de description des données qui n’est autre que XML. La spécification SOAP décrit une balise <envelope> Message SOAP = combinaison des balises dans un document

12.2 Introduction à SOAP Les spécifications de SOAP se limitent à définir une enveloppe (basée sur XML) pour les informations à transférer entre applications, ainsi qu’une série de règles qui permettent de traduire des données propres à une plateforme ou une application en XML. Nous allons maintenant voir ce que fait SOAP, et comment il le fait.

Page 21 / 52

10/07/2003

Projet de semestre – Sécurité des services web

12.2.1

Jonathan Rod

SOAP & XML

Du code SOAP est du code XML, autrement dit SOAP est une simple application des spécifications XML. Les définitions et les fonctions de SOAP sont basées sur des standards de XML comme « XML Schema » et « XML Namespaces » (cf. http://www.w3c.org).

12.2.1.1

Messages XML

Les messages XML sont la base même de SOAP. Ils permettent la communication entre 2 applications en utilisant des documents XML. Ses messages peuvent contenir des informations de toutes sortes: les résultats d’une recherche, une réservation d’hôtel, un ordre de paiement, etc. XML n’est pas propre à une application, un système d’application ou à un langage de programmation. Il peut donc être utilisé dans tous les environnements. On peut par exemple imaginer la création d’un document XML dans un programme basé autour d’une plateforme Unix. Puis sa récupération sous Windows pour utilisé les paramètres transmis. On peut utiliser les messages XML (SOAP) pour deux applications différentes: - RPC (Remote Procedure Call) pour transmettre des paramètres et des valeurs de retour de fonction. - EDI (Electronic Document Interchange) pour transmettre des ordres de paiement, etc.

12.2.1.2

Standard de représentation

XML permet une infinité de représentation pour chaque information (adresse, numéro de téléphone, nom, etc.). Deux applications voulant se communiquer des informations doivent donc définir un standard de représentation qui devra définir: - le type des informations échangées - comment elles seront exprimées en XML - comment envoyer cette information Ce standard de représentation permettra à deux applications de se comprendre. SOAP définit ce standard.

12.2.2

Messages SOAP

Les messages SOAP sont constitués de deux parties: - l’en-tête du message (SOAP header) elle contient des bloques (header block) qui définissent: le routage du message et des conditions de livraison, des assertions d'authentification ou d'autorisation, et des contextes de transaction. - le corps du message (SOAP body) il contient le message qui devra être effectivement délivré. SOAP envelope SOAP header Header block Header block

SOAP body Message body

Le standard pour la syntaxe des messages est décrit dans la note du W3C http://www.w3.org/2001/06/soapenvelope.

Page 22 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Ci-dessous, un exemple d’ordre de paiement correspond au style d’un document SOAP. <s:Envelope xmlns:s="http://www.w3.org/2001/06/soap-envelope"> <s:Header> <m:transaction xmlns:m="soap-transaction" s:mustUnderstand="true"> 1234 <s:Body> Christopher Robin <dept>Accounting Pooh Bear <dept>Honey 1 Pooh Stick

Cet exemple montre les différents composants de l’enveloppe SOAP.

12.2.2.1

Enveloppes SOAP

Une enveloppe SOAP ne peut contenir qu’un seul corps! L’entête n’est pas obligatoire et on ne peut en mettre qu’une par enveloppe.

12.2.2.2

Messages RPC

Les messages RPC (Remote Procedure Call) vont par pair. Le client produit les messages de type «Request » et le serveur les « Response ». Client SOAP

Server SOAP

Request Response Figure 3 : échange de message RPC

Voici l’exemple d’un message qui fait appel à un service déployé sur le serveur : POST /soap/servlet/rpcrouter HTTP/1.0 Host: bathory.mine.nu:6666 Content-Type: text/xml; charset=utf-8 Content-Length: 492 SOAPAction: "" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <ns1:getAddressFromName xmlns:ns1="urn:AddressFetcher" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> John B. Good Figure 4 : message RPC envoyé du client (request)

Page 23 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Et la réponse ci-dessous du serveur à la requête ci-dessus : HTTP/1.1 200 OK Set-Cookie: JSESSIONID=A45B8472165F47F39651C4F67E401D4F; Path=/soap Content-Type: text/xml; charset=utf-8 Content-Length: 946 Date: Thu, 01 May 2003 10:48:01 GMT Server: Apache Coyote/1.0 Connection: close <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <ns1:getAddressFromNameResponse xmlns:ns1="urn:AddressFetcher" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> Anytown <areaCode xsi:type="xsd:int">123 <exchange xsi:type="xsd:string">456 7890 <state xsi:type="xsd:string">NY <streetName xsi:type="xsd:string">Main Street <streetNum xsi:type="xsd:int">123 12345 Figure 5 : message RPC envoyé du serveur (response)

Ces messages ont été obtenus grâce à l’utilisation d’un tunnel fourni par ApacheSOAP.

12.2.3

Fautes SOAP

SOAP définit des types de messages qui n’ont pour but que de transmettre des informations concernant les erreurs. Ces messages contiennent : - Le code de la faute : identifie le type d’erreur. Attention, cette valeur n’aura de sens que dans le contexte d’un XML-NameSpace particulier. - La description de la faute : une explication de la faute - L’acteur : l’identifiant de la partie du message qui a créé la faute - Les détails : décrit la faute spécifique de l’application lorsque la faute vient du corps du message

12.2.3.1

Définition des fautes

Un service web peut définir ses propres fautes. Elles seront donc totalement inconnues du protocole SOAP. A n’utiliser que dans un cas où la précision des fautes prédéfinis est trop faible. Si un service ne comprend pas ces fautes, il agira de manière imprévisible et donc dangereuse.

12.2.4

Modèle d’échange de message

SOAP ne fait que définir une enveloppe pour le transport d’informations. Une fois les données réceptionnées et l’enveloppe enlevée, le modèle d’échange donne un gabarit qui nous permet de les gérer.

Page 24 / 52

10/07/2003

Projet de semestre – Sécurité des services web

12.2.4.1

Jonathan Rod

Routes et acteurs des messages

On peut voir une enveloppe SOAP comme un moyen de transport unidirectionnel entre un envoyeur et un receveur. Cette enveloppe peut passer au travers de différentes « escales » intermédiaires. La liste de ces escales nous donne la route du message. Chacune de ces escales est considérée comme un acteur. La construction de cette route n’est pas propre au protocole SOAP, mais elle dépend de chaque message. Pour « corriger » ce manque, Microsoft a écrit le SOAP Routing Protocol (WS-Routing). Prenons, un exemple. Si une revendeur reçoit une demande pour des marchandises dont le prix attend $1000.-, sous la forme d’un message SOAP sur son service web. Pour vérifier l’authentification et l’intégrité du message, il peut spécifier une route particulière pour ce type de message qui passe par un organe de contrôle externe. Cet organe devra vérifier le message et ajouter à son tour un certificat au message pour spécifier au revendeur que le message est intègre et authentique. Service web du revendeur

1) envoit de l’ordre de commande (avec sa signature digitale)

2. demande validation

Client : acheteur

Service web de validation des signatures digitales

3. passer commande

Figure 6 : exemple de route d’un message SOAP

Il est important de comprendre que SOAP ne définit comment le message doit passer par un acteur (service intermédiaire), il dit juste qu’il doit le faire. Microsoft a donc définit une entête standard dans son WS-Routing pour expliciter les informations sur la route.

12.2.5

Réaliser un service web « RPC »

Cette section montre comment les appels de procédures distantes sont codés et implantés dans le corps des messages SOAP.

12.2.5.1

Invocation

Il existe deux règles pour pouvoir implanter des requêtes RPC dans une enveloppe SOAP : - L’appel de la méthode distante doit être représenté en une simple structure. Avec les paramètres d’entrée ou d’entrée/sortie comme champs de cette structure - L’ordre et les noms des paramètres dans la requête doivent correspondre à l’ordre et aux noms des paramètres de la méthodes invoquée Exemple: invocation d’une méthode Java Signature de la méthode Java : String test (String code, String nbID); Arguments de l’invocation: result = test (‘myCode’, ‘myID’);

Page 25 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Enveloppe SOAP correspondante à l’invocation: <s:Envelope xmlns:s="..."> <s:Body> myCode <customerID xsi:type="string"> myID Figure 7 : enveloppe SOAP avec RPC à une méthode Java : invocation

12.2.5.2

Réponse

Les mêmes règles que pour l’invocation sont valables pour les réponses (structure simple contenant paramètres & même ordre et noms). Suite de l’exemple donné plus haut Enveloppe SOAP correspondante à la réponse: <s:Envelope xmlns:s="..."> <s:Body> myTest Figure 8 : enveloppe SOAP avec RPC à une méthode Java : invocation

Le nom « testResponse » n’est pas une obligation. Toutefois la convention veut qu’on utilise le nom de la méthode suivi de « Response ».

12.2.5.3

Rapport d’erreur

La convention SOAP veut qu’on retourne des fautes SOAP au client RPC en cas d’erreur. La partie détail du message d’erreur peut fournir les informations nécessaires à la compréhension de l’erreur. Dans des rares cas particuliers, le service web définira des erreurs propriétaires.

12.2.6

Encodage des données - Terminologie

Cette partie explique comment les données sont mappées et encodées dans un format XML lors de leurs insertions dans une enveloppe SOAP. L’encodage des données est complètement optionnel, heureusement vu la lourdeur qu’une telle manœuvre représente. Les enveloppes SOAP peuvent accueillir n’importe quel document XML, peut importe la tête du corps que l’on veut y placer. Toutefois un standard est définit par SOAP pour permettre à deux entités d’échanger des informations sans devoir en premier lieu s’entendre sur un standard propriétaire. On puit donc soit mettre n’importe quoi dans l’enveloppe, soit suivre les spécifications existantes. Deux termes doivent être définit avant d’aborder la suite de l’encodage : - value (valeur) - accessor (accesseur) Value Définition : Exemple :

représente soit une unité de données, soit plusieurs unités de données. nom d’une personne, température ambiante (en ce moment 30° au labo…)

Page 26 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Accessor Définition : Exemple : Compound Value :

Jonathan Rod

représente un élément qui contient ou donne accès à une value nom, prénom, température représente plusieurs value accessible depuis le même accessor. Il existe deux types de Compound Value (struct : accessor différents / array : accessor pareils)

Exemples (value & compound value): <prenom> Jonathan Figure 9 : value = Jonathan / accessor = prenom

<prenom> Jonathan <nom> Rod Figure 9bis : compound value : struct (accessor = nom)

<nom> Jean <nom> Rod Figure 9bis : compound value : array (accessor = nom)

SOAP définit qu’un accessor peut être « single-referenced » ou « multi-referenced ». Respectivement : soit un accessor sert à référencer, soit il sert à donner une valeur. Exemples (accessor « single-referenced » ou « multi-referenced »): 36 Rumine Lausanne Figure 10 : accessor single-referenced (ici adresse)

<street>36 Rumine Lausanne Figure 10bis : accessor multi-referenced (ici adresse)

Page 27 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

SOAP donne également d’utiliser un accessor externe Exemples (accessor externe): <nom = ‘Jonathan Rod’> Figure 10 : accessor externe

12.2.7

Types de donnée

Les types de données supportés par SOAP sont ceux définis par les « XML Schema data types » spécifications. Tous les types utilisés dans l’encodage SOAP doivent être tirés de ces spécifications ou directement dérivées de celles là. Il existe deux syntaxes pour exprimer un type de données dans une enveloppe SOAP : <SOAP-ENC:int>77 77 Figure 11 : syntaxes de déclaration de la valeur 77 de type entier

La première méthode, la plus répandue, se nomme « anonymous accessor » puisque le nom de l’accessor est le nom du type. La deuxième méthode vient de l’attribut « xsi:type » trouvés dans les spécifications de XML Schemas, je n’en parlerai pas ici.

12.2.7.1

Types composés: structuré, tableau, etc.

Nous avons déjà vu la différence entre type structuré et tableau. Les tableaux normaux sont indiqués comme étant des accessors du type « SOAP-ENC:Array » ou de type dérivé. Le type des éléments qui peuvent être contenu par le tableau est définit grâce à l’attribut « arraytype ». <some_array xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="se:string[2]"> <se:string>Jonathan <se:string>Jean Figure 12 : attribut « arrayType »

On remarquera la valeur entre crochets [] qui indique la taille du tableau. Ces crochets peuvent également être utilisés pour créer un offset dans le tableau afin de n’en transmettre qu’une partie. Des tableaux à plusieurs dimensions peuvent également être déclarés.

12.2.8

Transport des messages SOAP

SOAP se place au-dessus des protocoles de transport et de réseaux afin d’utiliser les standards déjà présents. Il permet de complètement faire abstraction des protocoles de transport et ainsi est extrêmement portable. Pour illustrer cette portabilité, on peut citer le service web de Pavel Kulchenko qui transmet les messages SOAP au travers des protocoles: http, ftp, raw TCP, SMTP, POP3, MQSeries et Jabber.

12.2.8.1

SOAP sur http

Le protocole http est extrêmement répandu sur Internet, et ça fait de lui le protocole le plus pratique pour l’échange des messages SOAP. Les deux protocoles correspondent naturellement puisqu’ils sont les deux basés sur un système de requête / réponse. La requête SOAP est « postée » au serveur grâce à la requête http, et la réponse SOAP est retournée par le serveur grâce à la réponse http.

Page 28 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Client http

http « POST »

SOAP request

http response

Jonathan Rod

Server http

SOAP response

Figure 13 : Utilisation du protocole http par SOAP

Ci-dessous, le code des requêtes / réponse http correspondantes POST /StockQuote HTTP/1.1 Content-Type: text/xml Content-Length: nnnn SOAPAction: "urn:StockQuote#GetQuote" <s:Envelope xmlns:s="http://www.w3.org/2001/06/soap-envelope"> ... Figure 14 : requête http contenant l’enveloppe SOAP

HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn <s:Envelope xmlns:s="http://www.w3.org/2001/06/soap-envelope"> ... Figure 14bis : réponse http contenant l’enveloppe SOAP

Une entête http nommée « SOAPAction » est définit par le protocole SOAP pour indiquer au serveur http l’intention de la requête. Sa valeur est arbitraire, mais elle doit annoncer au serveur le but de la requête SOAP avant que ce dernier décode le XML de l’enveloppe SOAP. Il faut tout de même noter que http n’est pas fait pour transporter du XML, et dans certaines situations http et SOAP ne se supportent pas mutuellement. Pour corriger cela, la nouvelle plateforme .Net de Microsoft utilise son protocole « Instant Messaging » pour faire transiter les messages SOAP.

12.3 Conclusion L’étape suivante serait l’écriture d’un service web SOAP. Le temps manque hélas pour sa réalisation. Les chapitres « Writing SOAP Web Services » et suivants du livre de référence utilisé vous fournirons si besoin les détails utiles pour cette réalisation. Les différents langages proposés pour l’écriture d’un service web sont : - Perl - Visual Basic - Java - .Net

12.4 Référence O’Reilly, « Programming Web Service with SOAP », First Edition 2001

Page 29 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

13 Annexe 2 : WS-Security 13.1 Motivation Avant d’expliquer ce qu’est WS-Security, il est important de comprendre pourquoi il existe. SOAP est un moyen d’échanger des messages par exemple en utilisant le protocole http. Mais ce dernier ne propose pas des solutions satisfaisantes au niveau de la sécurité (authentification, intégrité, confidentialité). Il se limite à compter sur la sécurité « poin-to-point » (par exemple firewall à firewall) existante. Alors que WSSecurity fixe une politique de sécurité « end-to-end » (utilisateur à utilisateur).

13.2 Introduction WS-Security est une spécification développée et promue par Microsoft, IBM et VeriSign. WS-Security définit un gabarit pour incorporer des standards déjà existants aux messages SOAP. L’utilisation des standards suivants est facultative. X.509 est utilisé pour l’authentification et utilise PKI pour la gestion des clés. « XML Encryption » et « XML Signature » sont utilisés pour encrypter et signer le contenu du message XML. Des mécanismes plus simples peuvent également être mis en place (authentification par mot de passe par exemple). Pour précisément, WS-Security définit l’entête du message SOAP (SOAP Header). Elle peut par exemple contenir une description de la manière avec laquelle le message a été signé grâce à « XML Signature ». WS-Security propose une solution de sécurité « end-to-end » en gardant toutes les informations de sécurité dans le message SOAP lui-même. Toutefois, un contrôle préalable des messages peut être effectué par un organisme (par exemple un firewall) afin d’assurer que ces derniers répondent bien aux exigences de sécurité mise en place. Les différents aspects de la sécurité abordés plus tard sont: o Authentification o Signature o Intégrité Attention: WS-Security définit une palette de possibilités pour assurer la sécurité des messages SOAP. Toutefois, rien n’est obligatoire!

13.3 Application de WS-Security Le message SOAP doit pouvoir nous permettre d’utiliser différentes informations. Dans l’ordre ces informations sont: o Identifier l’auteur du message o Prouver que l’auteur fait partie d’un groupe connu o Prouver que l’auteur a les bons droits o Prouver que le message reçu et le même que celui envoyé Toutes ces informations sont contenues dans un jeu d’entêtes SOAP attaché au message. WS-Security définit en premier lieu un « UsernameToken » dont le rôle sera de transmettre le login et le password (si le service web demande une authentification). Un « Security Token Service » pourra être utilisé pour l’obtention et la validation du Token. Ce dernier pourra être : un service Kerberos ou PKI, ou une simple base de données contrôlant un login et password. Lorsque le client a obtenu le Token, il doit l’incorporer à son message. Si le client utilise un UsernameToken pour l’authentification, il devra envoyer un hash de son password et signé le message avec son password. Le serveur peut alors contrôler la validité du message en comparant la signature qu’il génère avec celle contenu dans le message.

Page 30 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

On peut également utiliser des certificats X.509 pour signer le message. Dans ce cas, le message sera signer à l’aide de la clé privée. Et le certificat X.509 sera ajouté au message. Toutes entités possédant la clé publique sera donc en mesure de contrôler la signature du message.

1.Envoit de la requête pour l’obtention d’un Token

Web Service Client

Security Service Token

2.Reception du Token pour l’ajouter au message

4.Validation Token 3.Envoit du message signé (avec le Token)

Web Service

5.Réception de la réponse

Figure1 – Déroulement typique d’une transaction

Le diagramme ci-dessus illustre le déroulement d’une transaction avec l’utilisation des concepts explicités cidessus. Est-ce suffisant d’obtenir l’identité de l’auteur du message avec certitude? Non, puisqu’un pirate pourrait remplacer le corps d’un message (dont il sait que l’entête est valide) par un corps malveillant.

13.4 Entête SOAP version WS-Security Les entêtes SOAP sont basées autour des types suivants. Ces derniers sont nécessaires pour permettre à l’entête d’accueillir plusieurs « Token ». Namespace Xs Wsse Wsu Soap

Description Namespace URI XML Schema http://www.w3.org/2001/XMLSchema WS-Security http://schemas.xmlsoap.org/ws/2002/07/secext Utility elements http://schemas.xmlsoap.org/ws/2002/07/utility SOAP elements http://schemas.xmlsoap.org/soap/envelope/ Tableau 1 – XML Namespaces utilisés dans les entêtes SOAP

Un message SOAP peut contenir plusieurs bloques d’entête. Chaque bloque WS-Security est identifiée par un seul acteur. Cela pour rendre plus simple l’identification de quel bloque fait quoi. Chaque acteur est identifié de manière unique par un URI. C’est cet URI qui permettra d’identifier et de traiter le bloque WS-Security comme il se doit. Le service web doit définir le traitement pour chaque acteur.

13.5 Paramètres supplémentaires Certains paramètres fixés par WS-Security paraissent à priori hors de propos quand il s’agit du sujet de la sécurité. Toutefois, deux de ces paramètres attirent l’attention. wsu:ID Cet attribut a été ajouté pour faciliter au maximum le travail des « relais » des messages. La valeur de cet attribut peut être dupliquée n’importe où dans le document. Elle permet une identification claire des différents éléments ainsi nommés. wsu:Timestamp Cet attribut permet de connaître les dates importantes du message (la date de sa création, de son expiration et de sa réception). Chacune de ces dates est identifiée de manière unique grâce à un wsu:ID.

Page 31 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

En cas d’arrivée de deux messages identiques, leur « Timestamp » respectif peuvent permettre de choisir le bon message. La date d’expiration permet également de déterminer si un message est encore valable ou pas.

13.6 Authentification WS-Security propose de nombreuses méthodes pour permettre la validation d’un utilisateur. J’aborde ici trois de ces méthodes.

13.6.1

Username / password

Sans doute la manière d’authentification la plus répandue. Pour transmettre ces informations, WS-Security a définit le UsernameToken. Voici le schéma d’un UsernameToken: <xs:element name="UsernameToken"> <xs:complexType> <xs:sequence> <xs:element ref="Username"/> <xs:element ref="Password" minOccurs="0"/> <xs:attribute name="Id" type="xs:ID"/> <xs:anyAttribute namespace="##other"/> Figure 2 – schéma UsernameToken

Ci-dessous, on découvre deux nouveaux types: username & password. En particulier, on remarque l’attribut « Type » de password qui permet de définir la façon dont il est codé (plain text, digest format, etc.). Ici, le password passe en clair (plain text). <wsse:UsernameToken> <wsse:Username>scott <wsse:Password Type="wsse:PasswordText">password Figure 3 – UsernameToken dans un message SOAP (code XML) password en clair

Même UsernameToken, mais cette fois le password est hashé. <wsse:UsernameToken> <wsse:Username>scott <wsse:Password Type="wsse:PasswordDigest"> KE6QugOpkPyT3Eo0SEgT30W4Keg= <wsse:Nonce>5uW4ABku/m6/S5rnE+L7vg== <wsu:Created xmlns:wsu= "http://schemas.xmlsoap.org/ws/2002/07/utility"> 2002-08-19T00:44:02Z Figure 4 – UsernameToken dans un message SOAP (code XML) password hashé (algorithme SH1)

Dans le cas d’un passage du password hashé, le récepteur devra vérifier les données en récréant le hash à partir du password (qu’il doit évidemment connaître) et en le comparant au hash reçu.

Page 32 / 52

10/07/2003

Projet de semestre – Sécurité des services web

13.6.2

Jonathan Rod

X.509 Certificats

Lors de l’authenfication avec X.509, le certificat public est transmis sous la forme du schéma ci-dessous: un BinarySecurityToken: <xs:element name="BinarySecurityToken"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="Id" type="xs:ID" /> <xs:attribute name="ValueType" type="xs:QName" /> <xs:attribute name="EncodingType" type="xs:QName" /> <xs:anyAttribute namespace="##other" processContents="strict" /> Figure 5 – schéma BinarySecurityToken

Ce schéma contient: o Une chaîne de caractère o Un identifiant unique o Des informations sur le type des éléments contenus et comment ils sont encodés

13.6.3

Kerberos

Un utilisateur peut, s’il détient toutes les pièces (conditions) demandées, obtenir un TGT (ticket granting ticket). Ce TGT est une obscure partie de donnée que l’utilisateur ne peut pas lire (exploiter). Par contre l’utilisateur pourra utiliser ton TGT pour obtenir un ST (service ticket) et ainsi accéder aux services. Déroulement du système: o Un client s’authentifie auprès d’un distributeur de clés (KDC: Key Distribution Center) et obtient un TGT o Le client utilise son TGT pour accéder à un TGS (Ticket Granting Service) o Le client demande un ST pour une ressource réseau particulière. o Le TGS délivre le ST au client o Le client accède à la ressource réseau spécifiée avec les droits spécifiés en présentant son ST.

13.7 Signature La signature d’un message ne protège en aucun cas son contenu de la visualisation d’autrui, par contre elle permet d’assurer que le contenu reçu et bien celui envoyé. Intégrité: oui, confidentialité: non! Les trois méthodes d’authentification vues ci-dessus peuvent être utilisées pour signer le message et ainsi garantir son intégrité. o X.509 demande à l’envoyeur de signer son message avec sa clé privée. o Kerberos demande une « clé de session » que l’envoyeur crée et transmet avec son ticket. Et seul le destinateur de ce message peut lire le ticket, et ainsi retrouver la clé de session. Et vérifier l’authenticité de la signature. o UsernameToken demande que le message soit signé avec le password. La signature est générée en utilisant « XML Signature ». Il est important de comprendre que même pour signer un message « Hello World », il est nécessaire de signer chaque élément individuellement.

Page 33 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

13.8 Encryption L’intégrité est importante, mais la confidentialité l’est également. C’est pourquoi WS-Security met en place des systèmes d’encryption. Deux grandes familles peuvent être utilisées pour l’encryptage de données: l’encryption symétrique ou asymétrique. L’encryption symétrique demande que le secret (la clé de décryptage) soit connu par l’envoyeur et le destinataire. Puisque la clé sert à la fois à encrypter et à décrypter les données. Intuitivement, on peut dire que l’utilisation de l’encryption symétrique est réservée aux cas où : - on contrôle le système entier (end-to-end) - l’application et/ou le client utilisant la clé sont connus (et dignes de confiance) Le problème de l’encryption symétrique est le passage de la clé entre les futurs utilisateurs. On ne peut pas imaginer envoyer la clé « en clair » dans un mail avant de l’utiliser pour encrypter les transmissions suivantes. Les solutions envisagées sont très diverses, allant du colis postal contenant un disc sur lequel le mot de passe est enregistré à la correspondance téléphonique. L’encryption asymétrique ne pose pas ces problèmes, puisque la clé publique (servant à l’encryption) peut être diffusée à n’importe qui. Cela est envisageable, puisqu’un message ne pourra être décrypté que grâce à la clé privée. L’utilisateur voulant recevoir des données encryptées n’aura donc qu’à garder sa clé privée secrète pour garantir la confidentialité.

Page 34 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Voici un exemple de message encrypté avec un algorithme symétrique. Il contient les informations sur les données contenues dans le message, ainsi que sur la manière dont le message a été encrypté. <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <soap:Header xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"> <wsu:Timestamp> <wsu:Created wsu:Id="Id-3beeb885-16a4-4b65-b14c-0cfe6ad26800" >2002-08-22T00:26:15Z <wsu:Expires wsu:Id="Id-10c46143-cb53-4a8e-9e83-ef374e40aa54" >2002-08-22T00:31:15Z <wsse:Security soap:mustUnderstand="1" > <xenc:ReferenceList> <xenc:DataReference URI="#EncryptedContent-f6f50b24-3458-41d3-aac4-390f476f2e51" /> <xenc:ReferenceList> <xenc:DataReference URI="#EncryptedContent-666b184a-a388-46cc-a9e3-06583b9d43b6" /> <soap:Body> <xenc:EncryptedData Id="EncryptedContent-f6f50b24-3458-41d3-aac4-390f476f2e51" Type="http://www.w3.org/2001/04/xmlenc#Content"> <xenc:EncryptionMethod Algorithm= "http://www.w3.org/2001/04/xmlenc#tripledes-cbc" /> Symmetric Key <xenc:CipherData> <xenc:CipherValue >InmSSXQcBV5UiT... Y7RVZQqnPpZYMg== Figure 6 – message SOAP avec encryption symétrique réalisée

Page 35 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

13.9 Conclusion WS-Security nous offre les moyens de : - identifier l’envoyeur du message - signer le message - encrypter les données contenues dans le message dans les échanges SOAP.

Authentification Intégrité Confidentialité

WS-Security met bien en place une solution de sécurité « end-to-end ». Dans ce cas l’application de cette solution dépend donc des clients (utilisateurs ou applications) et non plus de l’infrastructure réseau elle-même. On pourrait par exemple imaginer que des messages SOAP non conformes seraient reçus par une personne utilisant un portable au saint d’une entreprise qui applique WS-Security. Les conséquences pourraient être l’affaiblissement de la sécurité de l’entreprise. Pour garantir l’application de WS-Security, il est donc nécessaire que la sécurité « point-to-point » soit mise à contribution. Typiquement en faisant contrôler par un firewall le contenu de l’entête des messages SOAP dès leurs arrivées dans le réseau d’entreprise (SOHO). Le firewall pourra ainsi laisser passer, par exemple, uniquement les messages dont l’entête signalera qu’ils sont signés et encryptés. Le firewall pourrait même participer à l’authentification de l’envoyeur du message au travers d’une base de données locale ou distante. On constate que l’application de WS-Security est nécessaire afin que le protocole SOAP soit sécurisé, et ainsi utilisable pour des échanges d’informations sensibles. Dans des entreprises telles que: banques, assurances, ventes par correspondance par carte de crédit, etc.

13.10Référence http://msdn.microsoft.com/

Page 36 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

14 Tutorial : mise en place d’un service web SOAP 14.1 But Construire et fournir des services web sur la base de Apache SOAP

14.2 Introduction Apache SOAP Apache SOAP se compose d’un servlet qui écoute les requêtes SOAP, de classes Java correspondantes pour la traduction des requêtes en code Java, et de classes Java pour la génération de la réponse SOAP. Il tourne sur des serveurs d’application, comme par exemple: Tomcat, IBM Websphere, BCA Weblogic, Allaire JRun, etc. Tomcat Tomcat est un serveur d’application qui peut soit tourner sous un serveur web comme par exemple Apache, soit tourner indépendamment. En utilisant Apache SOAP, nous allons mettre en place un service web SOAP. D’abord le fournisseur de service web (serveur) au chapitre 3 puis le consommateur (client) au chapitre 4. Attention! Ce tutorial aboutit à la mise en place d’un service web fonctionnel. Toutefois cette fonctionnalité n’a été testée qu’avec une version de chaque composant.

14.3 Déploiement de Apache SOAP sur un système Windows XP 14.3.1

Serveur d’application : Tomcat

14.3.1.1

Java

14.3.1.1.1

Télécharger Java

http://java.sun.com/j2se/downloads.html Version: 1.4.1_02 Note: ne pas prendre de version antérieure à 1.3

14.3.1.1.2

Installer Java

Exécuter le fichier d’installation et suivre les instructions Répertoire par défaut: C:\j2sdk1.4.1_02

14.3.1.1.3

Editer la variable d’environnement JAVA_HOME

Note: pour éviter de refaire manuellement chaque étape par la suite, créer un script

Page 37 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

startTC.bat set JAVA_HOME=C:\j2sdk1.4.1_02 Figure 1 : code du script startTC.bat

14.3.1.2

Tomcat

14.3.1.2.1

Télécharger Tomcat

http://jakarta.apache.org/site/binindex.cgi Version: 4.1.24 Note: prendre une version sous « Release Builds », et télécharger le .zip correspondant

14.3.1.2.2

Extraire Tomcat

A l’aide d’un utilitaire de décompression (Winzip, etc.) C:\soap\jakarta_tomcat_4.1 Note: ne pas mettre d’espace dans le nom du répertoire

14.3.1.2.3

Editer la variable d’environnement CATALINA_HOME

Modifier le script startTC.bat set JAVA_HOME=C:\j2sdk1.4.1_02 set CATALINA_HOME=C:\soap\jakarta_tomcat_4.1 %CATALINA_HOME%\bin\startup.bat Figure 2 : code du script startTC.bat

14.3.1.2.4

Lancer Tomcat

Exécuter le script « startTC.bat »

14.3.1.2.5

Test du serveur

Pour vérifier le fonctionnement du serveur, taper http://localhost:8080 dans la barre d’adresse de votre navigateur. La page d’accueil de Tomcat doit apparaître. La page d’accueil de Tomcat vous propose différents tests à effectuer pour vérifier le fonctionnement des SSPs et des servlets. Lancer un exemple SSP (SSP Examples) Lancer une servlet (Servlet Examples) Si les tests ci-dessus réussissent, votre serveur d’application est installé et fonctionnel! Sinon recommencez en contrôlant que vous suivez bien les rubriques « Note » de chaque étape.

Page 38 / 52

10/07/2003

Projet de semestre – Sécurité des services web

14.3.2

Application web: SOAP

14.3.2.1

Apache SOAP

14.3.2.1.1

Télécharger Apache SOAP

Jonathan Rod

http://xml.apache.org/dist/soap/ Version: 2.3.1 Note: télécharger le .zip correspondant

14.3.2.1.2

Extraire Apache SOAP

A l’aide d’un utilitaire de décompression (Winzip, etc.) C:\soap\soap-2_3_1 Note: ne pas mettre d’espace dans le nom du répertoire

14.3.2.2

Bibliothèques

Apache SOAP pour Java nécessite l'API JavaMail qui dépend elle-même du Framework Java Activation (JAF). Apache SOAP a également besoin du package Xerces (parser XML), donc nous devons le télécharger et l'installer.

14.3.2.2.1

Javamail

Télécharger Javamail http://java.sun.com/products/javamail/ Version: 1.2 Note: section « JavaMail API » Extraire dans C:\soap\javamail-1.2

14.3.2.2.2

Javabeans

Télécharger Javabeans Version: 1.2 Extraire dans

14.3.2.2.3

http://java.sun.com/products/javabeans/glasgow/jaf.html C:\soap\jaf-1.0.2

Xerces

Télécharger Xerces Version: 1.2 Extraire dans

http://xml.apache.org/dist/xerces-j/old_xerces1/ C:\soap\xerces-1_2_3

14.3.2.3

SOAP vers Tomcat

14.3.2.3.1

Copie des modules SOAP pour Tomcat

C:\soap\soap-2_3_1\webapps\soap.war

C:\soap\jakarta_tomcat_4.1\webapps\soap.war

Page 39 / 52

10/07/2003

Projet de semestre – Sécurité des services web

14.3.2.3.2

Jonathan Rod

Accès aux fichiers .jar SOAP pour Tomcat

Modifier le script : startTC.bat set JAVA_HOME=C:\j2sdk1.4.1_02 set CATALINA_HOME=C:\soap\jakarta_tomcat_4.1 set CLASSPATH=C:\soap\soap-2_3_1\lib\soap.jar set CLASSPATH=%CLASSPATH%;C:\soap\javamail-1.2\mail.jar set CLASSPATH=%CLASSPATH%;C:\soap\jaf-1.0.2\activation.jar set CLASSPATH=%CLASSPATH%;C:\soap\xerces-1_2_3\xerces.jar %CATALINA_HOME%\bin\startup.bat Figure 3 : code du script startTC.bat

14.3.2.4

Test de Apache SOAP

Pour vérifier le fonctionnement du serveur, taper http://localhost:8080/soap/servlet/rpcrouter dans la barre d’adresse de votre navigateur. Le message suivant doit apparaître :

1 SOAP RPC Router Sorry, I don't speak via HTTP GET- you have to use HTTP POST to talk to me. Figure 4 : résultat attendu

Si le test ci-dessus réussit, votre application SOAP est installée et fonctionnelle! Sinon recommencez en contrôlant que vous suivez bien les rubriques « Note » de chaque étape.

14.3.3

Déploiement d’un service de démo

Un utilitaire java (java org.apache.soap.server.ServiceManagerClient) est fourni par Apache SOAP pour nous permettre de faire appelle à un script de déploiement. Les paramètres de ce script sont : - L’URL du servlet SOAP - Un fichier XML décrivant le service (descripteur de déploiement) Apache SOAP fournis des services de démo dans le répertoire: C:\soap\soap-2_3_1\samples

Page 40 / 52

10/07/2003

Projet de semestre – Sécurité des services web

14.3.3.1

Jonathan Rod

Création du script de déploiement

deployerTC.bat set JAVA_HOME=C:\j2sdk1.4.1_02 set CLASSPATH=C:\soap\soap-2_3_1\lib\soap.jar set CLASSPATH=%CLASSPATH%;C:\soap\javamail-1.2\mail.jar set CLASSPATH=%CLASSPATH%;C:\soap\jaf-1.0.2\activation.jar set CLASSPATH=%CLASSPATH%;C:\soap\xerces-1_2_3\xerces.jar java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter deploy %1 pause Figure 5 : code du script deployerTC.bat

14.3.3.2

Modification du script de démarrage de Tomcat

startTC.bat set JAVA_HOME=C:\j2sdk1.4.1_02 set CATALINA_HOME=C:\soap\jakarta_tomcat_4.1 set CLASSPATH=C:\soap\soap-2_3_1\lib\soap.jar set CLASSPATH=%CLASSPATH%;C:\soap\javamail-1.2\mail.jar set CLASSPATH=%CLASSPATH%;C:\soap\jaf-1.0.2\activation.jar set CLASSPATH=%CLASSPATH%;C:\soap\xerces-1_2_3\xerces.jar set CLASSPATH=%CLASSPATH%;C:\soap\soap-2_3_1 %CATALINA_HOME%\bin\startup.bat Figure 6 : code du script startTC.bat

Note: il faut arrêter puis redémarrer Tomcat pour que le nouveau CLASS_PATH soit pris en compte.

14.3.3.3

Déploiement du service de démo

>deployerTC.bat C:\soap\soap-2_3_1\samples\addressbook\DeploymentDescriptor.xml

14.3.3.4

Contrôle du déploiement du service

Pour contrôler le déploiement du service, taper http://localhost:8080/soap/admin/index.html dans la barre d’adresse de votre navigateur. Sous la rubrique List vous trouverez la ligne « urn:AddressFetcher » correspondant à votre service.

14.3.3.5

Contrôle du fonctionnement du service

Puisque le client SOAP n’existe pas encore, nous allons utiliser le client fournit par Apache SOAP. Il se contentera d’appeler la méthode getAddressFormName du service.

Page 41 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Création du script client : getAddressFormName.bat set CLASSPATH=C:\soap\soap-2_3_1\lib\soap.jar set CLASSPATH=%CLASSPATH%;C:\soap\javamail-1.2\mail.jar set CLASSPATH=%CLASSPATH%;C:\soap\jaf-1.0.2\activation.jar set CLASSPATH=%CLASSPATH%;C:\soap\xerces-1_2_3\xerces.jar set CLASSPATH=%CLASSPATH%;C:\soap\soap-2_3_1\ java samples.addressbook.GetAddress http://localhost:8080/soap/servlet/rpcrouter "John B. Good" pause Figure 7 : code du script getAddressFormName.bat

Pour vérifier le fonctionnement du service,exécuter le script. Le message suivant doit apparaître : 123 Main Street Anytown, NY 12345 (123) 456-7890 Figure 8 : résultat attendu

14.3.4

Ecoute du dialogue SOAP

Un tunnel (TcpTunnelGui inclus dans le package soap.jar) est fourni par Apache SOAP pour nous permettre de regarder le dialogue SOAP entre le client et le serveur.

14.3.4.1

Principe de TcpTunnelGui

Le tunnel écoute les requêtes TCP/IP sur un certain port, les affichent à l’écran, puis les réexpédient vers le port qui traite les requêtes. Même démarche pour les réponses.

14.3.4.2

Création du script de démarrage du tunnel

tunnelSOAP.bat set CLASSPATH=C:\soap\soap-2_3_1\lib\soap.jar java org.apache.soap.util.net.TcpTunnelGui 6666 localhost 8080 Figure 9 : code du script tunnelSOAP.bat

Page 42 / 52

10/07/2003

Projet de semestre – Sécurité des services web

14.3.4.3

Jonathan Rod

Modification du script du client

getAddressFormName.bat set CLASSPATH=C:\soap\soap-2_3_1\lib\soap.jar set CLASSPATH=%CLASSPATH%;C:\soap\javamail-1.2\mail.jar set CLASSPATH=%CLASSPATH%;C:\soap\jaf-1.0.2\activation.jar set CLASSPATH=%CLASSPATH%;C:\soap\xerces-1_2_3\xerces.jar set CLASSPATH=%CLASSPATH%;C:\soap\soap-2_3_1\ java samples.addressbook.GetAddress http://localhost:6666/soap/servlet/rpcrouter "John B. Good" pause Figure 10 : modification du script getAddressFormName.bat

14.3.4.4

Affichage du dialogue SOAP

Après avoir lancé le tunnel en exécutant le script tunnelSOAP.bat, lancer le client en exécutant le script getAddressFormName.bat. L’interface graphique vous montre le dialogue SOAP client-serveur.

Figure 11 : interface utilisateur du tunnel SOAP

Page 43 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Détail des messages : Du client : POST /soap/servlet/rpcrouter HTTP/1.0 Host: localhost:6666 Content-Type: text/xml; charset=utf-8 Content-Length: 492 SOAPAction: "" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <ns1:getAddressFromName xmlns:ns1="urn:AddressFetcher" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> John B. Good Figure 12 : code du message SOAP envoyé par le client : requête

Du serveur : HTTP/1.1 200 OK Set-Cookie: JSESSIONID=A45B8472165F47F39651C4F67E401D4F; Path=/soap Content-Type: text/xml; charset=utf-8 Content-Length: 946 Date: Thu, 01 May 2003 10:48:01 GMT Server: Apache Coyote/1.0 Connection: close <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <ns1:getAddressFromNameResponse xmlns:ns1="urn:AddressFetcher" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> Anytown <areaCode xsi:type="xsd:int">123 <exchange xsi:type="xsd:string">456 7890 <state xsi:type="xsd:string">NY <streetName xsi:type="xsd:string">Main Street <streetNum xsi:type="xsd:int">123 12345 Figure 13 : code du message SOAP envoyé par le serveur : réponse

Page 44 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

14.4 Mise en place du client A ce stade là, la manière la plus simple et rapide de créer un client distant et de : • installer Java sur la machine client (voir section 3.1) • faire une copie du répertoire c:\soap du serveur dans un répertoire équivalent sur le client • récupérer le script créé pour le test du serveur (getAddressFormName.bat) et faire la modification indiquée ci-dessous. getAddressFormName.bat set CLASSPATH=C:\soap\soap-2_3_1\lib\soap.jar set CLASSPATH=%CLASSPATH%;C:\soap\javamail-1.2\mail.jar set CLASSPATH=%CLASSPATH%;C:\soap\jaf-1.0.2\activation.jar set CLASSPATH=%CLASSPATH%;C:\soap\xerces-1_2_3\xerces.jar set CLASSPATH=%CLASSPATH%;C:\soap\soap-2_3_1\ java samples.addressbook.GetAddress http://serveurName:8080/soap/servlet/rpcrouter "John B. Good" pause Figure 14 : code du script getAddressFormName.bat coté client

Pour vérifier le fonctionnement du client, exécuter le script. Le message suivant doit apparaître : 123 Main Street Anytown, NY 12345 (123) 456-7890 Figure 15 : résultat attendu

14.5 Conclusion Si vous avez suivi les indications ci-dessus, vous disposez maintenant d’un service web SOAP fonctionnel composé d’un client et d’un serveur. Il existe de nombreux exemples de services web disponibles sur Internet, par exemple sur le site de référence nommé ci-dessous.

14.6 Référence http://www.soapuser.com/

Page 45 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

15 Planning et objectifs projet de semestre & objectifs travail de diplôme 15.1 Planning du projet de semestre 13 mars 2003 Apprentissage de XML : recherche de documentation sur Internet et à la bibliothèque 20 mars 2003 Analyse des menaces spécifiques aux applications Web. Edition d’un résumé sur la base du document The Ten Most Critical Web Application Security Vulnerabilities publié par OWASP. 27 mars 2003 Discussion avec Messieurs Maret et Buchs pour la mise au point du cahier des charges. Edition du planning du projet. Apprentissage de XML : lecture de différents cours sur le sujet, dont celui de M. Jaton 3 avril 2003 Apprentissage de XML : pratique (parsing, etc.). 10 et 17 avril 2003 Etude et édition d’un résumé portant sur SOAP. 1, 8 et 22 mai 2003 Recherche des outils et des APIs (par exemple pour Java). Recherche des outils pour la mise en place du FW. Edition d’un tutorial sur la mise en place d’un banc de test pour l’étude des communications SOAP. Mise en place d’un banc de test pour l’étude des communications XML / SOAP. Utilisation de ApacheSOAP, d’un tunnel pour la visualisation des messages SOAP. 12 juin 2003 Réception de l’infrastructure mise à disposition par l’Eivd. Réunion et présentation du bilan intermédiaire. Etude des communications (requêtes, réponses, etc.). 19 juin 2003 Mise en place d’un serveur Apache sous Windows 2000. Configuration d’un module proxy sous Apache. 26 juin 2003 Test de l’infrastructure complète (client, serveur, serveur Apache) à l’aide d’un service web. 3 et 10 juillet 2003 Etude et édition d’un résumé sur WS-Security. Etude sur les menaces spécifiques aux services Web SOAP. Rendre le dossier contenant le rapport du projet ainsi que les annexes.

Page 46 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

17 juillet 2003 Présentation du projet. Modification du cahier des charges pour le travail de diplôme si besoin.

15.2 Objectifs du projet de semestre Rendre mon rapport sur les services web Rendre comme annexe de mon dossier: Le résumé sur SOAP Le tutorial sur la mise en place d’un service web Le résumé sur WS-Security Le résumé sur la sécurité des applications web (avorté) Avoir à disposition une infrastructure complète présentant un service web, contenant: Le serveur Le client La plateforme pouvant accueillir le FW Présenter le fonctionnement du service web: La partie Client La partie Serveur Le FW

Page 47 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

15.3 Objectifs du travail de diplôme (avec planning en pourcentage des 60 jours à disposition

1.66% = 1 jour )

Installation d’Apache sous Linux Recherche d’informations sur le sujet Installation de Linux Installation et configuration d’Apache Note: je pense qu’il est plus simple d’utiliser une plate-forme Linux pour les tests et la mise en place d’un module sous Apache. C’est pourquoi je me tourne ici vers Linux. 5% Module Apache Apprentissage des modules Apache au travers de l’étude d’un module déjà existant Révision du langage C Ecriture d’un module basique (typiquement un exemple) 10% Module Firewall SOAP Réalisation d’un firewall applicatif SOAP pour le protocole http sous la forme d’un module spécifique pour Apache. Les fonctionnalités du firewall se limiteront dans un premier temps à un contrôle des en-têtes des enveloppes SOAP et à un contrôle de leurs contenus (corps de l’enveloppe). 50% Test de l’infrastructure complète Fonctionnalité Résistance aux attaques Evolution possible du module suite aux résultats des tests 35%

Page 48 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

16 Annexe 3 : sécurité des applications web (avorté) 16.1 Introduction Etudier la problématique de sécurité des applications Web dans le cadre d’un travail de semestre.

16.2 Cahier des charges (défini par Sylvain Marret) Dans un premier temps, cette étude comportera l'analyse des menaces spécifiques aux applications Web et plus spécifiquement les échanges Soap transitant par http ou https. Cette étude analysera les mécanismes actuels d'authentification, d'intégrité des échanges, de la confidentialité et enfin de la signature des transactions. · XML · XML-Signature · XML-Encryption · SOAP · SAML · WS-Security · PKI- X509 Puis dans une deuxième phase, cette étude se focalisera sur les outils à mettre en œuvre pour la protection des services Web et plus spécifiquement la sécurisation des messages Soap à l'aide de firewall. Pour mettre en pratique cette problématique, cette étude devra mettre en œuvre un service web utilisant des échanges de messages Soap à travers le protocole http. L'étape suivante sera de réaliser un firewall applicatif Soap pour le protocole http. L'idée étant d'utiliser le server Apache comme base de travail et d'implémenter le firewall Soap en tant que module Apache.

16.3 Analyse des menaces spécifiques aux applications Web Cette étude se base dans un premier temps sur un article publié par l’organisation OWASP (Open Web Application Security Project) pour approcher la problématique des menaces spécifiques aux services Web d’une manière générale. Vous trouverez ci-dessous une liste des menaces les plus répandues dans les applications Web.

16.3.1

Unvalidated Parameters (paramètres invalides)

Des informations sont transmisses depuis le Web jusqu’aux applications Web. Si la validité de ces dernières n’est pas contrôlée avant la transmission, cela créer une vulnérabilité. Un Hacker peut attaquer les composants de l’application via cette faille.

Page 49 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Chaque partie de la requête HTTP doit être contrôlée avant la validation de cette dernière. La modification de l’URL, de l’en-tête de la requête, etc. pourrait suffire au Hacker pour outrepasser le mécanisme de sécurité. Protection : tous les paramètres doivent être validés selon un typage stricte (type de donnée, longueur des données, paramètre null accepté, paramètres dupliqués, etc.) fixé par exemple par une librairie centrale.

16.3.2

Broken Access Control (perte du contrôle d’accès)

La définition des restrictions propres à un utilisateur authentifié par un système n’est pas correctement spécifiée. Un Hacker peut accéder à des acomptes, des fichiers ou des fonctionnalités grâce à ce manque de rigidité. Une mauvaise mise en place des droits (ou des restrictions) impartis à un utilisateur peut créer un flou dans la vision globale de la problématique. Ceci rend pratiquement impossible toute mise à jour propre et contrôlée des restrictions. Un Hacker peut trouver une incohérence dans cette politique et ainsi accéder à des niveaux de privilège dangereux pour le système. Protection : établir une politique globale de sécurité. Puis tirer toutes les mesures de sécurité de cette dernière afin de garder en tout temps une vision intégrale de la problématique. Note : sans documentation sur la politique de sécurité globale, les mesures indépendantes à chaque application sont inefficaces.

16.3.3 Broken Account And Session Management (perte de contrôle de la gestion des acomptes et des sessions) La protection des acomptes et des sessions n’est pas correctement assurée. Un Hacker peut accéder aux passeports, aux cookies, aux clés, etc. des autres utilisateurs, et ainsi prendre leurs identités. Si par exemple une application doit garder une trace de toutes les requêtes d’un même utilisateur, elle sera alors obligée de créer elle-même un moyen d’authentification de chaque utilisateur. Pour se faire, l’application crée des "jetons" propres à un utilisateur pour marquer une session en cours. Ce jeton permet à l’application d’authentifier ce dernier. Si un Hacker récupère ce jeton, il peut alors se faire passer pour un utilisateur authentifié aux yeux de l’application. Il peut également essayer de décrypter le contenu du jeton pour en créer des nouveaux. Protection : les passeports doivent être changés régulièrement par tous les utilisateurs. Un nombre minimum de caractères doit être défini pour la taille de ces derniers. Toujours encrypter les données de "login" avant de les transmettre.

16.3.4

Cross-Site Scripting (XSS) Flaws

Page 50 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

Cette vulnérabilité vise directement la machine de l’utilisateur final. Le Hacker se sert de l’application Web pour transporter son mécanisme d’attaque (par exemple : JavaScript). Certaines applications font transiter des informations sans les filtrer. Par exemple une entrée directement redirigée sur une sortie. Puisque le récepteur reçoit l’information d’une application (typiquement un serveur) il considère cette dernière comme sans danger. Un Hacker peut donc profiter de cette "non-méfiance" pour attaquer une machine finale du réseau. Protection : certains caractères (<, >, (, ), #, &) transitant par l’application doivent être modifiés pour améliorer la sécurité.

16.3.5

Buffer Overflows (surcharge d’un tampon)

Une application Web peut être écrite dans un langage qui ne gère pas la validité des paramètres d’entrées, typiquement leurs longueurs (Le problème peut aussi venir de la manière de coder du programmeur de l’application). Un Hacker peut soit rentrer un paramètre très long pour faire planter l’application, soit chercher la taille limite du tampon afin de découvrir le contenu adjacent au tampon en mémoire centrale. L’écriture d’un tampon disproportionné par rapport à la taille mémoire allouée à ce dernier, permet au Hacker d’écraser une partie adjacente de la mémoire par son propre code. Et ainsi de faire exécuter son code. Protection : analyser chaque partie de code qui accepte des entrée venant qu’une requête HTTP et vérifier si les limitations sont bien respectées. Il existe également des scanners qui recherche cette faille sur un site Web complet.

16.3.6

Command Injection Flaws (Faille d’injection de commande)

Les applications Web passent des paramètres lors d’accès soit à un système externe, soit au système d’exploitation. Un Hacker peut modifier ces paramètres et ainsi faire exécuter ces commandes en lieu et place de celles de l’application Web. Même des appels systèmes peuvent être remplacés lors d’une "injection". Des scripts écrits en Python, Perl, etc. sont généralement utilisés pour réaliser cette attaque. Protection : interdire tous les appels systèmes qui ne sont pas nécessaires à notre application. Pour les autres, mettre en place un système de validation pour éviter l’exécution d’un code interdit.

16.3.7

Error Handling Problems (problèmes de gestion d’erreur)

Les exceptions levées durant l’exécution normale d’une application Web peuvent être mal gérées. Un Hacker peut trouver la marche à suivre pour générer ces exceptions. En observant

Page 51 / 52

10/07/2003

Projet de semestre – Sécurité des services web

Jonathan Rod

le comportement de l’application, il peut en déduire des informations sur le système. Ou simplement faire planter l’application.

16.3.8 Insecure Use Of Cryptogrsphy (utilisation non-sécurisé de la cryptographie) Les applications Web utilisent la cryptographie pour protéger la confidentialité des informations. Mais les fonctions de cryptage ont souvent des failles connues qui corrompent la sécurité de la confidentialité.

16.3.9 Remote Administration Flaws (contrôle à distance des outils d’administration) Les applications Web offrent souvent la possibilité de se faire gérer via le Web. Un Hacker qui accède à la configuration de l’application peut ainsi s’attribuer un accès complet à la configuration du site.

16.3.10 Web And Application Server Misconfiguration (incohérence entre les configurations de l’application et du serveur) Une configuration trop lourde du serveur est critique pour la sécurité de l’application Web.

Travail avorté après réunion avec M. Maret, Buchs et Ventura

Page 52 / 52

10/07/2003