Professional Documents
Culture Documents
Rapport
Projet de semestre de Jonathan Rod, EIT6
Ecole d’ingénieurs du Canton de Vaud - 2003
Page 1 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
2 MOTIVATIONS............................................................................................................................................... 5
3 DÉFINITIONS.................................................................................................................................................. 5
3.1 SÉCURITÉ .................................................................................................................................................... 5
3.2 SÉCURITÉ INFORMATIQUE ........................................................................................................................... 5
3.3 SERVICES WEB............................................................................................................................................. 5
4 SIMPLE OBJECT ACCESS PROTOCOL (SOAP).................................................................................... 6
4.1 AUTHENTIFICATION DU MESSAGE ............................................................................................................... 6
4.2 SIGNATURE DU MESSAGE ............................................................................................................................ 7
4.3 ENCRYPTION DU MESSAGE .......................................................................................................................... 7
4.4 APPLICATION............................................................................................................................................... 7
5 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
10 BILAN.......................................................................................................................................................... 19
Page 2 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
11 RÉFÉRENCES ........................................................................................................................................... 20
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.
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)
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.
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.
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.
Envoyeur Récepteur
Fonction de hachage Fonction de hachage
XY XY
Msg SOAP
Entête password
password - login trouvé
- hash
hash (ex. 128bits)
hash (ex. 128bits)
Corps
Si 0
XOR msg ok
Page 6 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
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.
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.
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.1 Situation
Diagramme représentant une problématique typique des services web
Utilisateur
Client utilisant Compagnie
un navigateur aérienne
Commande : (Swiss)
Commande Genève – Service web
transport : New York SOAP
Yverdon –
New York
Transport
Commande transport : Ferroviaire
Agence de voyage Yverdon - Genève (CFF)
Site web proposant des offres de Service web
voyage. SOAP
Client de différents services web
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
Session SGBD
(Oracle)
Commande
Client
Produit
SOAP
Internet
Agence de voyage
Compagnie aérienne
SGBD
Serveur (Oracle)
SOAP
Note :
La partie interface entre l’utilisateur et l’agence de
Gestion des vols
voyage n’est pas détaillée.
Page 9 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
Voici maintenant le même diagramme avec l’incorporation d’un firewall SOAP :
Utilisateur
Session SGBD
(Oracle)
Commande
Client
Produit
SOAP
Internet
Agence de voyage
Compagnie aérienne
FW SGBD
SOAP Serveur Oracle
SOAP
Note :
La partie interface entre l’utilisateur et l’agence de
Gestion des vols
voyage n’est pas détaillée.
Page 10 / 52 10/07/2003
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
Services :
XML parser
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 »
Page 11 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
Serveur Tomcat
web
http Apache RPCRouterSrvlet
Client
+
Services :
Module
Firewall
SOAP
XML parser
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 »
Page 12 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
Serveur Tomcat
web
http Apache RPCRouterSrvlet
Client +
Module
Firewall Services :
SOAP
OU
IpCop XML parser
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.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.
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!
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.
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
Enveloppe SOAP POST, Host, etc.
Entête du message SOAP
Identité Contrôle du schéma XML du message
Username + hash (password)
Authenfication (basée sur username ):
Rechercher username dans BD locale
Signature Rechercher password dans BD locale
hash (message) Générer le hash du password trouvé
si (hash reçu XOR hash généré) =0 alors
Authenfitication OK
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
Corps du message SOAP Intégrité du message OK
Confidentialité :
Contrôler que le message a été encrypté
Contrôle du contenu :
Après décryptage (clé dans BD locale)
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.
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.
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.
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).
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/
Page 20 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
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.
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.
Page 21 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
12.2.1 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).
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.
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/soap-
envelope.
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">
<transactionID>1234</transactionID>
</m:transaction>
</s:Header>
<s:Body>
<n:purchaseOrder xmlns:n="urn:OrderService">
<from><person>Christopher Robin</person>
<dept>Accounting</dept></from>
<to><person>Pooh Bear</person>
<dept>Honey</dept></to>
<order><quantity>1</quantity>
<item>Pooh Stick</item></order>
</n:purchaseOrder>
</s:Body>
</s:Envelope>
Response
Voici l’exemple d’un message qui fait appel à un service déployé sur le serveur :
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:Body>
</SOAP-ENV:Envelope>
Ces messages ont été obtenus grâce à l’utilisation d’un tunnel fourni par ApacheSOAP.
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.
Page 24 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
12.2.4.1 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
2. demande validation de validation
des signatures
digitales
3. passer commande
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.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
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>
<test xmlns="..."
s:encodingStyle="http://www.w3.org/2001/06/soap-encoding">
<orderCode xsi:type="string">myCode</orderCode>
<customerID xsi:type="string">
myID
</customerID>
</test>
</s:Body>
</s:Envelope>
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).
Le nom « testResponse » n’est pas une obligation. Toutefois la convention veut qu’on utilise le nom de la
méthode suivi de « Response ».
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.
Value
Définition : représente soit une unité de données, soit plusieurs unités de données.
Exemple : 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 Jonathan Rod
Accessor
Définition : représente un élément qui contient ou donne accès à une value
Exemple : nom, prénom, température
Compound Value : représente plusieurs value accessible depuis le même accessor. Il existe deux types de
Compound Value (struct : accessor différents / array : accessor pareils)
<personne>
<prenom> Jonathan </prenom>
<nom> Rod </nom>
</personne>
Figure 9bis : compound value : struct (accessor = nom)
<personnes>
<nom> Jean </nom>
<nom> Rod </nom>
</personnes>
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.
<peuple>
<personne nom='Jonathan Rod'>
<addresse href='#address-1'
</personne>
<personne nom='Jean Reymond'>
<addresse href='#address-1'
</personne>
</peuple>
<addresse id='address-1'>
<street>36 Rumine</street>
<city>Lausanne</city>
</addresse>
Page 27 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
SOAP donne également d’utiliser un accessor externe
Il existe deux syntaxes pour exprimer un type de données dans une enveloppe SOAP :
<SOAP-ENC:int>77</ SOAP-ENC:int>
<value xsi:type=”xsd:int”>77</value>
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.
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>
<se:string>Jean</se:string>
</some_array>
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.
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 Jonathan Rod
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnnn
<s:Envelope xmlns:s="http://www.w3.org/2001/06/soap-envelope">
...
</s: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 WS-
Security 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.
Attention: WS-Security définit une palette de possibilités pour assurer la sécurité des messages SOAP.
Toutefois, rien n’est obligatoire!
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.
4.Validation Token
5.Réception de la réponse
Le diagramme ci-dessus illustre le déroulement d’une transaction avec l’utilisation des concepts explicités ci-
dessus.
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.
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.
<xs:element name="UsernameToken">
<xs:complexType>
<xs:sequence>
<xs:element ref="Username"/>
<xs:element ref="Password" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Id" type="xs:ID"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
</xs:element>
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:Username>
<wsse:Password Type="wsse:PasswordText">password</wsse:Password>
</wsse:UsernameToken>
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 Jonathan Rod
<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" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
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é.
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 Authentification
- signer le message Intégrité
- encrypter les données contenues dans le message Confidentialité
dans les échanges SOAP.
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.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.1.1 Java
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
14.3.1.2 Tomcat
startTC.bat
set JAVA_HOME=C:\j2sdk1.4.1_02
set CATALINA_HOME=C:\soap\jakarta_tomcat_4.1
%CATALINA_HOME%\bin\startup.bat
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 Jonathan Rod
14.3.2 Application web: SOAP
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 http://java.sun.com/products/javabeans/glasgow/jaf.html
Version: 1.2
Extraire dans C:\soap\jaf-1.0.2
14.3.2.2.3 Xerces
Télécharger Xerces http://xml.apache.org/dist/xerces-j/old_xerces1/
Version: 1.2
Extraire dans C:\soap\xerces-1_2_3
Page 39 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
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
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.
Page 40 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
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
pause
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
Note: il faut arrêter puis redémarrer Tomcat pour que le nouveau CLASS_PATH soit pris en
compte.
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\
pause
Page 42 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
pause
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: ""
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:Body>
</SOAP-ENV:Envelope>
Page 44 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
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\
pause
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
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.
Page 47 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
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%
Page 48 / 52 10/07/2003
Projet de semestre – Sécurité des services web Jonathan Rod
Etudier la problématique de sécurité des applications Web dans le cadre d’un travail de
semestre.
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.
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.
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.
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.
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.
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é.
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.
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.
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.
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.
Une configuration trop lourde du serveur est critique pour la sécurité de l’application Web.
Page 52 / 52 10/07/2003