introduction à la sécurité des webservices

© 2011 - S.Gioria

CONFOO – Montréal Québec - Canada

10 Mars 2011

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 http://www.owasp.org

Sébastien Gioria (French Chapter Leader & OWASP Global Education Committee Member) [email protected]

Introduction a la sécurité des WebServices

© 2011 - S.Gioria

Agenda

 Introduction  Démystification des technologies  Les attaques sur les WebServices  Top10 OWASP && WebServices  Top10 WebServices ?

© 2011 - S.Gioria

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é

OWASP France Leader - Evangéliste -

OWASP Global Education Comittee Member ([email protected])

CISA && ISO 27005 Risk Manager

q  Domaines de prédilection : ü  Web, WebServices, Insécurité du Web.

Twitter :@SPoint Consultant Sécurité Sénior au sein du cabinet d’audit

© 2011 - S.Gioria

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

La base

© 2011 - S.Gioria

Qu’est-ce qu’un WebService ?

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

• D’après Wikipédia : http://fr.wikipedia.org/wiki/Web_service

© 2011 - S.Gioria


 Mais d’autres technologies existent

 Un WebService doit :  Pouvoir être découvrable  Pouvoir être auto-suffisant

Fournisseur

XML-RPC

POST/GET

text/xml Requêteur

Requêteur Fournisseur

© 2011 - S.Gioria


 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

Chorégraphie

WS2

WS3 WS4

WS5

WS1

© 2011 - S.Gioria

Orchestration

WS2

WS3 WS4

WS5

WS1

© 2011 - S.Gioria

Les ingrédients

© 2011 - S.Gioria

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

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"?>  <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

XPath

//username => Renvoi tous les username

//user[username = 'gandalf’]/account => Renvoi le champ account du compte gandalf

<?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>

© 2011 - S.Gioria


 SOAP : Simple Object Access Protocol  Permet l’envoi de messages XML

Entête SOAP Directives de Traitement

Corps SOAP (Message XML de requête ou de réponse)

Enveloppe SOAP

© 2011 - S.Gioria

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

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">

<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> <additionResponse xmlns="http://addition.example.com"> <multReturn>15</multReturn> </additionResponse> </soapenv:Body> </soapenv:Envelope>

Requête

Réponse

© 2011 - S.Gioria


IP

HTTP/SMTP/FTP/…

XML-RPC/SOAP/XML

WSDL

UDDI

Transport

Message XML

Description

Découverte

© 2011 - S.Gioria

Securité Web Classique


IP - IPSec

TCP – SSL /TLS

HTTP – HTTP Authentification

XML – Xml Signature

XML – XML Encryption

SOAP – WS Security / SAML /WS Policy

Relations de confiance – WS Trust/WS Federation/ LibertyAlliance

© 2011 - S.Gioria

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

1.  Enveloppante (‘enveloping’)

2.  Enveloppée (‘enveloped’)

3.  Détachée (‘detached’)

S O

S S

O

S

S S

Enveloppante

Enveloppée

Détachée

© 2011 - S.Gioria

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

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

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

WS-Security

 Objectifs   Authentification   Confidentialité des messages   Intégrité des messages

  Fondation d’autres standards

© 2011 - S.Gioria

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

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

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

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

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

Les attaques sur les WebServices

© 2011 - S.Gioria

XML Bomb :

 Trivial à effectuer : §  Référence récursive à une entité du même document :

 Peut provoquer un déni de service !

<?xml … …. <!entity owasp0 « Owasp »> <!entity owasp1 « &owasp0;&owasp0> …. …. <!entity owasp424242 « &owasp424241;&owasp424241 »> <owasptest>&owasp424242;</owasptest>

© 2011 - S.Gioria

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>

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

Crash du système

Obtention des mots de passe

© 2011 - S.Gioria

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><userid>0</userid><mail>[email protected]

Résultat : <?xml version="1.0" encoding="ISO-8859-1"?> <users>

<user> <username>tony</username> <password>Un6R34kb!e</password><userid>0</userid><mail>[email protected]</mail> </user>

</users>

© 2011 - S.Gioria

Injection CDATA

<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>

Le contenu des élément CDATA est éliminé lors du parsing. Soit :

Après Analyse: <html> <script>alert('XSS')</script> </html>

© 2011 - S.Gioria

Injection 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>

Imaginons la base d’authentification Xml suivante La chaine de recherche étant :

string(//user[username/text()='gandalf' and password/text()='!c3']/account/text())

Username: ' or '1' = '1 Password: ' or '1' = '1

Si l’utilisateur entre :

string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())

© 2011 - S.Gioria

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()

$itemID=chaine’] | /* | //item[itemID=‘chaine

Si l’utilisateur entre :

//item[itemID=‘chaine’] | /* | //item[itemID=‘chaine’]/description/text()

Match de tous les nœuds !!!!!

© 2011 - S.Gioria

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

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

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

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

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


 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

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

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


 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

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

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

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  Ne pas autoriser d’authentification en clair

© 2011 - S.Gioria

A8/A9/A10

 Ces différentes failles sont à lier au Top10 OWASP classique, mais appliqué aux WebServices.

© 2011 - S.Gioria

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

introduction à la sécurité des webservices

Documents