1. Introduction a la sécurité des
WebServices
CONFOO – Montréal
Québec - Canada
10 Mars 2011
Sébastien Gioria (French Chapter Leader & OWASP Global
Education Committee Member)
sebastien.gioria@owasp.org
Copyright © 2009 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License.
The OWASP Foundation
© 2011 - S.Gioria
http://www.owasp.org

2. Agenda
 Introduction
 Démystification des technologies
 Les attaques sur les WebServices
 Top10 OWASP && WebServices
 Top10 WebServices ?
© 2011 - S.Gioria

3. Consultant Sécurité Sénior au Twitter :@SPoint
sein du cabinet d’audit
OWASP France Leader - Evangéliste -
OWASP Global Education Comittee
Member (sebastien.gioria@owasp.org)
CISA && ISO 27005 Risk Manager
q Expérience en Sécurité des Systèmes d’Information > 0x0D années
q Différents postes de manager SSI dans la banque, l’assurance et les
télécoms
q Expertise Technique
ü Gestion du risque, Architectures fonctionnelles, Audits
ü S-SDLC : Secure-Software Development LifeCycle.
ü PenTesting, Digital Forensics
ü Consulting et Formation en Réseaux et Sécurité
q Domaines de prédilection :
ü Web, WebServices, Insécurité du Web. © 2011 - S.Gioria

4. Un peu d’histoire…
 1990 : DCE/RPC – Distributed Computing Environment
 1992 : CORBA – Common Object Request Broker
Architecture
 1990-1993 : Microsoft’s DCOM -- Distributed Component
Object Model
 Pour arriver à une standardisation (toujours en cours)
des protocoles, outils, langages et interfaces
WebServices
© 2011 - S.Gioria

5. La base
© 2011 - S.Gioria

6. Qu’est-ce qu’un WebService ?
• D’après Wikipédia :
http://fr.wikipedia.org/wiki/Web_service
Un service web est un programme informatique permettant la communication et
l'échange de données entre applications et systèmes hétérogènes dans des
environnements distribués. Il s'agit donc d'un ensemble de fonctionnalités exposées
sur internet ou sur un intranet, par et pour des applications ou machines, sans
intervention humaine, et en temps réel
© 2011 - S.Gioria

7. Qu’est-ce qu’un WebService ?
 Mais d’autres technologies existent
Requêteur Fournisseur
XML-RPC
POST/GET
Requêteur Fournisseur
text/xml
 Un WebService doit :
 Pouvoir être découvrable
 Pouvoir être auto-suffisant
© 2011 - S.Gioria

8. Qu’est-ce qu’un WebService ?
 Les acteurs :
 L’utilisateur : la personne qui accède à un portail permettant
d’interroger un WebService
 Le requêteur : l’application cliente du service Web
 L’intermédiaire : un élément qui peut gérer une partie de la
requête
 Le fournisseur : l’application serveur qui effectuera le traitement
 Le registre : l’annuaire des services et des points d’accès
 La coordination : il existe deux modes de
fonctionnement des WebServices :
 Le mode direct : principe du client/serveur.
 Le mode « orchestré » : principe de la requête via un tiers.
© 2011 - S.Gioria

9. Chorégraphie
WS1
WS5
WS2
WS3 WS4
© 2011 - S.Gioria

10. Orchestration
WS1
WS2 WS5
WS3
WS4
© 2011 - S.Gioria

11. Les ingrédients
© 2011 - S.Gioria

12. Démystification des technologies
• Languages
• XML : La base
• xPath, xQuery : équivalent à SQL
• WSDL : Descripteur de Services
• Protocoles
• Transport : HTTP
• Message : SOAP (SOAP = HTTP + XML)
• Autres éléments :
• SAML : Security Assertion Markup Language
• WS-Security : Web Services Security
© 2011 - S.Gioria

13. Démystification des protocoles
 XML : eXtensible Markup Language
 Standard d’échanges de données basé sur des balises.
<?xml version="1.0" encoding="UTF-8"?>
<!-- '''Commentaire''' -->
<element-document xmlns="http://exemple.org/" xml:lang=";fr">
<elément>Texte</element>
<élément>un second élément </element>
…..
<element attribut="valeur"></element>
</element-document>
© 2011 - S.Gioria

14. XPath
<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<account>admin</account>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<account>guest</account>
</user>
</users>
//username => Renvoi tous les username
//user[username = 'gandalf’]/account => Renvoi le champ
account du compte gandalf
© 2011 - S.Gioria

15. Démystification des protocoles
 SOAP : Simple Object Access Protocol
 Permet l’envoi de messages XML
Enveloppe SOAP
Entête SOAP
Directives de Traitement
Corps SOAP
(Message XML de requête ou de réponse)
© 2011 - S.Gioria

16. SOAP - Type de communication
q RPC
 Le document XML transmis dans la requête SOAP est
calqué sur la syntaxe de la méthode invoquée
 Traitement synchrone
q Document
 Le document XML transmis dans la requête SOAP est
traité par le serveur, qui renvoie un document XML en
retour
 Le Client ne sait pas comment le service est
implémenté, ni comment le message est traité
 Traitement asynchrone
© 2011 - S.Gioria

17. SOAP – Exemple
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<addition xmlns="http://addition.example.com"> Requête
<a>6</a>
<b>9</b>
</addition>
</soapenv:Body>
</soapenv:Envelope>
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/
soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
Réponse <additionResponse xmlns="http://addition.example.com">
<multReturn>15</multReturn>
</additionResponse>
</soapenv:Body>
</soapenv:Envelope> © 2011 - S.Gioria

18. Démystification des protocoles
Découverte UDDI
Description WSDL
Message XML XML-RPC/SOAP/XML
Transport HTTP/SMTP/FTP/…
IP
© 2011 - S.Gioria

19. Démystification des protocoles
Relations de confiance – WS Trust/WS Federation/
LibertyAlliance
SOAP – WS Security / SAML /WS Policy
XML – XML Encryption
XML – Xml Signature
HTTP – HTTP Authentification
TCP – SSL /TLS
IP - IPSec
Securité Web Classique © 2011 - S.Gioria

20. XML Signature
 Objectif: signature numérique d’un document XML
 Garantir l’authenticité et l’intégrité du document
 Signature de tout ou partie du document XML
 Recommandation W3C: XML Signature Syntax and
Processing
 http://www.w3.org/TR/xmldsig-core/
 Types de signature S
Enveloppante
1. Enveloppante (‘enveloping’) S
O
2. Enveloppée (‘enveloped’)
Enveloppée S
3. Détachée (‘detached’)
S S
O S Détachée
© 2011 - S.Gioria

21. Xml Encryption
 Objectif: chiffrement d’un document XML
 Garantir la confidentialité de bout en bout du
document
 Recommandation W3C: XML Encryption
Syntax and Processing
 http://www.w3.org/TR/xmlenc-core/
 Flexible
 Possibilité d’encrypter tout ou partie du
document, avec 1 ou différentes clés
© 2011 - S.Gioria

22. XMLencryption
 Chiffrement symétrique
 Quid de la clé?
 Clé connue des deux parties
 Plusieurs clés communes et identifiant de la clé
utilisée transmis
 Transmission de la clé partagée encryptée avec la clé
publique du correspondant
© 2011 - S.Gioria

23. Xml Encryption
 Chiffrement XML
1. Choix d’un algorithme (3DES ou AES)
2. Obtention ou génération de la clé
3. Sérialisation des données à encrypter
4. Chiffrement
 Déchiffrement
1. Identifier l’algorithme et la clé utilisés
2. Obtenir la clé
3. Déchiffrer les données
4. Intégrer les données déchiffrées dans le document
© 2011 - S.Gioria

24. WS-Security
 Objectifs
 Authentification
 Confidentialité des messages
 Intégrité des messages
 Fondation d’autres standards
© 2011 - S.Gioria

25. WS-Security
 Notion de jeton de sécurité (security
token)
 Pour l’authentification ou l’autorisation
§ Ex: username/password, certificat X509, …
 Extension de SOAP
 Définition d’un header SOAP contenant l’information
de sécurité
§ Jetons de sécurité
§ Signatures numériques
§ Élements encryptés
© 2011 - S.Gioria

26. WS-Security
§ Confidentialité des messages SOAP
§ Utilisation de XML-Encryption
§ Encryption d’un ou plusieurs éléments du message SOAP
§ Référence vers les éléments encryptés dans le header
§ Clé partagée
§ Possibilité d’encrypter différents éléments
avec des clés différentes
© 2011 - S.Gioria

27. WS-Policy
§ Objectif: spécifier des
informations et des exigences
pour un WS
§ S’applique aussi bien au serveur qu’au client
§ Exemples:
§ utilisation d’une version spécifique de SOAP
§ Exigence de signature
§ Information sur le format de la réponse (encrypté,
signée…)
© 2011 - S.Gioria

28. WS-Trust
§ Modèles de confiance nombreux et
variés
§ Et transorganisations
§ Problèmes
§ Émettre et obtenir des jetons de sécurité
§ Etablir et valider des relations de confiance
§ Définition d’un Security Token Service
§ Émet, valide ou échange un jeton de sécurité
© 2011 - S.Gioria

29. Les parseurs XML
 2 grandes familles :
 SAX :
§ Simplistes
§ Analyse du document en fonction des événements
§ Appel de fonction lorsque des nœuds sont trouvés
 DOM :
§ Plus complexes et utiles
§ Basés sur des principes d’arbres pour créer des hiérarchies du
document
§ Compatibles xPath !
© 2011 - S.Gioria

30. Les attaques sur les WebServices
© 2011 - S.Gioria

31. XML Bomb :
 Trivial à effectuer :
§ Référence récursive à une entité du même document :
<?xml …
….
<!entity owasp0 « Owasp »>
<!entity owasp1 « &owasp0;&owasp0>
….
….
<!entity owasp424242
« &owasp424241;&owasp424241 »>
<owasptest>&owasp424242;</owasptest>
 Peut provoquer un déni de service !
© 2011 - S.Gioria

32. Injection XML entity
 La possibilité d’injecter du code XML de type entity system peut être
catastrophique
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>
Crash du système
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>
Obtention des mots de passe
© 2011 - S.Gioria

33. Injection XML
DTD :
<!DOCTYPE users [
<!ELEMENT users (user+) >
<!ELEMENT user (username,password,userid,mail+) >
<!ELEMENT username (#PCDATA) >
<!ELEMENT password (#PCDATA) >
<!ELEMENT userid (#PCDATA) >
<!ELEMENT mail (#PCDATA) >
]>
http://www.example.com/addUser.jsp?
username=tony&password=Un6R34kb!e</password><!--&email=--
><userid>0</userid><mail>s4tan@hell.com
Résultat :
<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><!--</password>
<userid>500</userid>
<mail>--><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users>
© 2011 - S.Gioria

34. Injection CDATA
Le contenu des élément CDATA est éliminé lors du parsing.
Soit :
<html>
$HTMLCode
</html>
$HTMLCode = <![CDATA[<]]>script<![CDATA[>]]>alert('xss')<!
[CDATA[<]]>/script<![CDATA[>]]>
Avant analyse du parser:
<html>
<![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<!
[CDATA[>]]>
</html>
Après Analyse:
<html>
<script>alert('XSS')</script>
</html>
© 2011 - S.Gioria

35. Injection xPath
Imaginons la base d’authentification Xml suivante
La chaine de recherche étant :
<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user> string(//user[username/text()='gandalf' and
<username>gandalf</username> password/text()='!c3']/account/text())
<password>!c3</password>
<account>admin</account>
</user>
<user>
<username>Stefan0</username>
Si l’utilisateur entre :
<password>w1s3c</password>
<account>guest</account> Username: ' or '1' = '1
</user> Password: ' or '1' = '1
</users>
string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())
© 2011 - S.Gioria

36. Injection xPath - dump XML
Le dump d’un document XML est rendu possible via le caractère |
Soit le descriptif d’un champ
//item[itemID=‘$id’]/description/text()
Si l’utilisateur entre :
$itemID=chaine’] | /* | //item[itemID=‘chaine
//item[itemID=‘chaine’] | /* | //item[itemID=‘chaine’]/description/text()
Match de tous les nœuds !!!!!
© 2011 - S.Gioria

37. Rejeu des messages SOAP
 SOAP est un protocole d’échanges
 SOAP ne dispose pas d’un mécanisme de
sessions :
 Aucune relation entre les messages
 Rejeu possible très facilement :
§ Authentification
§ Messages
§ DOS…
© 2011 - S.Gioria

38. Les WebServices et le Top10
 A1: Cross Site Scripting (XSS)
 Facilité d’effectuer du XSS persistent via les injections
XML
 A2: Failles d’injection
 Injections XML/Xpath, SQL, …
 A3: Execution de fichier malicieux
 Via les références et les tags <!entity>
 A4: Référence directe non sécurisée à un objet
 Mêmes problèmes que pour le mode Web.
© 2011 - S.Gioria

39. Les WebServices et le Top10
 A5: Falsification de requête inter-site (CSRF)
 Cf XSS
 A6: Fuite d’information et traitement d’erreur incorrect
 Différents mécanismes sont disponible via SOAP pour obtenir les
informations sur les méthodes disponibles
 A7: Violation de gestion de session ou de
l’authentification
 Aucune fonction disponible dans les protocoles, même problèmes
qu’en « Web Standard »
 A8: Stockage cryptographique non sécurisé
 Rien de différent qu’en Web.
 A9: Communications non sécurisées
 SOAP n’est pas sécurisé par conception
 A10: Manque de restriction d’accès à une URL
 Rien de différent qu’en Web. © 2011 - S.Gioria

40. Proposition d’un Top 10 WebServices
© 2011 - S.Gioria

41. © 2011 - S.Gioria

42. A1 – Manque d’authentification
 But :
 Rejeu des transactions
 Elevation de privilèges
 Principe :
 Envoie d’un message SOAP au point d’accès
 Dangerosité :
 Faible à Forte
 Protection :
 Utilisation de SSL
 Utilisation des couches WS-Security
 Mettre en place des principes d’unicité des transactions
© 2011 - S.Gioria

43. A2 – Manque d’habilitation
 But :
 Premier => modifier des fichiers/données
 Final => Elevation de privilèges
 Principe :
 Envoie d’un message SOAP au point d’accès contenant des
identifiants valide
 Dangerosité :
 Faible à Forte
 Protection :
 Mise en place d’une habilitation dans le code
 Protéger les fichiers de politiques et des DTDs
 Ne pas se contenter d’URLs non publiées
© 2011 - S.Gioria

44. A3 – Manque de trace d’audit
 Constat :
 Les framework de WebServices ont peu de traces des
événements.
 Il devient quasi-impossible de pouvoir tracer correctement les
flux dans le cas d’orchestration complexes.
 Protection :
 Mettre en place des traces d’audit dans le code en particulier des
appels :
§ D’authentification
§ Changement dans le système(creation/destruction/modification)
§ Dépassement des limites
§ Lancement, arret de fonctions
§ …….
© 2011 - S.Gioria

45. A4 – Manque de politique de sécurité
 Constat :
 Du à la conception des WebServices, il est très difficile de
disposer d’une politique globale.
 De base les framework ne comportent pas de contrôle d’accès
 Dangerosité :
 Faible à Forte
 Protection :
 Mettre en place une politique de sécurité des WebServices :
§ Sur les protocoles de communication (HTTP/HTTPS/…)
§ Sur l’échange des messages
§ Sur la gestion des clefs de chiffrement
§ Sur la protection contre les rejeux
§ ….
 Mettre en place les tags WS-SecurityPolicy © 2011 - S.Gioria

46. A5 – Défaillance XML
 But :
 Abuser les parseurs XML pour obtenir :
§ Des informations
§ Des privilèges
§ ….
 Dangerosite :
 Forte
 Protection :
 Vérifier que les parseurs XML utiliser sont immunes aux problèmes
d’injection de type DOS/Entité, ….
 Vérifier la taille des documents XML lors des utilisations
 Vérifier que l’intégralité du document est signé par juste une partie
(dans le cas d’utilisation des signatures)
 Vérifier le document XML via le schéma le plus strict
 Ne pas faire confiance à une pré-validation des données de l’expéditeur.
© 2011 - S.Gioria

47. A6 – Détournement d’identité
 Constat :
 Les WebServices utilisent l’identité de l’appelant dans :
§ Le contrôle d’accès
§ Les décisions de routage des appels
§ La logique métier
 Les frameworks ne disposent pas de fonctions de protection de
l’identité
 But :
 Elevation de privilèges
 Obtention d’informations
 Dangerosite :
 Forte
 Protection :
 Mettre en place WS-Security, les assertions SAML
 Vérifier les signatures des messages
 Utiliser l’authentification forte © 2011 - S.Gioria

48. A7 – Faiblesse des clefs
 Constat :
 Il n’existe pas de protection des messages et de l’authentification
en XML et HTTP.
 Le standard WS-Security ne suffit pas à protéger les clefs d’accès
car les données sont passées en clair.
 But :
 Elevation de privilèges
 Obtention d’informations
 Dangerosite :
 Forte
 Protection :
 Mettre en place du chiffrement de bout en bout (SSL/IPSec)
 Utiliser des authentifications fortes (certificats X509, OTP, ..)
 Mettre en place des mécanismes anti-rejeu
© 2011 - S.Gioria
 Ne pas autoriser d’authentification en clair

49. A8/A9/A10
 Ces différentes failles sont à lier au Top10
OWASP classique, mais appliqué aux
WebServices.
© 2011 - S.Gioria

50. A voir
 http://www.soaspecs.com/ws.php
 NIST Guide : Securing Web Services :
 http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf
 Article du CERT :
 https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/
assembly/639-BSI.html
 Gunnar Peterson
 http://arctecgroup.net/pdf/WebServicesSecurityChecklist.pdf
 Blog : http://1raindrop.typepad.com/
 WebCast SANS : https://www.sans.org/webcasts/security-web-
services-soa-91958
© 2011 - S.Gioria