Visitez http://liliasfaxi.wix.com/liliasfaxi

1. Institut National des Sciences Appliquées et de Technologie Tunisie
E-Services
Chapitre 5 – Sécurité des Services
Dr. Lilia SFAXI
GL5 - 2013-2014

2. 1
Plan du Chapitre

Sécurité des Services

Sécurité des Web Services

3. 2
Plan

Sécurité des Services

Sécurité des Web Services

4. 3
Besoins de la Sécurité

Services exposent des fonctions métier : besoin de protéger :
o
o
Les données
o

Les règles métier
Les fonctionnalités
Problèmes de sécurité recouvrent plusieurs domaines
o
Protection des données sensibles
o
Authentification
o
Autorisation des utilisateurs
o
Protection contre les attaques de code et utilisateurs malveillants
o
Audit et journalisation des évènements et de l’activité des utilisateurs

5. OWASP
4
Open Web Applications Security Project

Organisation à but non lucratif, visant à améliorer la sécurité des logiciels

Permet de:
o
Rendre la sécurité des logiciels visible
o
Aider les organisations à prendre les décisions sur les risques de sécurité

Indépendant des vendeur, ne recommande pas de produits commerciaux

Plusieurs projets, par exemple:
o
o

Enterprise Security API: bibliothèque de contrôle de la sécurité des applications web
WebGoat: application web délibérément non sécurisée, permettant d’enseigner des leçons de
sécurité aux concepteurs d’applications (version J2EE, ASP.NET)
Définition d’un top 10 des risques des applications

6. OWASP
5
Top 10 des Risques de Sécurité des Applications (1/2)

A1 : Injection (SQL, OS, XPath, Hibernate…)
o

A2 : Violation de Gestion d’Authentification et de Session
o

Quand une application accepte des données non fiables et les envoie à un browser web sans validation
appropriée  permet aux attaquants d’exécuter du script dans le navigateur de la victime afin de
détourner des sessions utilisateur, défigurer des sites web ou rediriger les utilisateurs vers des sites
malveillants
A4 : Références directes non sécurisées à un objet
o

Compromettre les mots de passe, clés, jetons de session  s’approprier les identités des utilisateurs
A3 : Cross-Site Scripting (XSS)
o

Donnée non fiable est envoyée à un interpréteur en tant qu’élément d’une commande ou requête 
des commandes fortuites peuvent être exécutées, et des données non autorisées peuvent être accédées
Quand un développeur expose une référence vers un fichier, dossier, enregistrement de BD ou clé.
A5 : Mauvaise configuration de sécurité
o
Nécessité de mise en œuvre de paramètres de sécurité pour l’application, les serveurs et la plateforme

7. OWASP
6
Top 10 des Risques de Sécurité des Applications (2/2)

A6 : Exposition de données Sensibles
o

A7 : Manque de contrôle d’accès au niveau fonctionnel
o

L’application force le navigateur de la victime à envoyer une requête HTTP contenant le cookie de
session à une application web vulnérable.
A9 : Utilisation de composants avec des vulnérabilités connues
o

Les vérifications de contrôle d’accès doivent être faites sur le serveur lors de l’accès à chaque fonction.
A8 : Falsification de requête intersite (CSRF: Cross-Site Reference Forgery)
o

Nécessité de protéger les données sensibles telles que les num de cartes de crédit, informations
d’authentification… Possibilité de vol d’identité sinon.
Utilisation de bibliothèques, contextes et autres modules logiciels qui peuvent causer des pertes de
données sérieuses ou une prise de contrôle du serveur.
A10 : Redirections et renvois non validés
o
Redirection vers d’autres pages et sites sans validation: peuvent être des sites de fishing ou malware.

8. 7
Plan

Sécurité des Services

Sécurité des Web Services

9. 8
Web Services

10. 9
Protocoles Utilisés
Découverte
UDDI
Description
WSDL
Message XML
Transport
XML-RPC/SOAP/XML
HTTP/SMTP/FTP/…
IP

11. 10
Protocoles de Sécurité
Relations de confiance – WS Trust/WS Federation/Liberty
Alliance
SOAP – WS Security / SAML / WS Policy
XML – XML Signature / XML Encryption
HTTP – HTTP Authentication
TCP – SSL/TLS
IP - IPSec
Sécurité Web Classique

12. 11
XML Signature

Objectif: signature numérique d’un document XML
o
Garantir l’authenticité et l’intégrité du document
o
Signature de tout ou partie du document XML

Recommendation W3C: XML Signature Syntax and Processing

Peut être:
o
Enveloppante : La signature contient l’élément à signer dans une balise Object
o
Enveloppée : La signature est un élément du contenu qu’elle signe.
o
Détachée : La signature est dans un élément externe à l’objet signé, dans le même
document ou dans un document externe.

13. 12
XML Encryption

Objectif : chiffrement d’un document XML
o
Garantir la confidentialité de bout en bout du document

Recommendation W3C : XML Encryption Syntax and Processing

Possibilité d’encrypter tout ou partie du document, avec 1 ou différentes clés

Chiffrement symétrique
o
Clé connue des deux parties
o
Plusieurs clés communes et identifiant de la clé utilisée transmis
o
Transmission de la clé partagée encryptée avec la clef publique du correspondant

14. 13
WS-Security

Standard OASIS, permet de sécuriser les services web

Objectifs
o
o
Confidentialité des messages
o

Authentification & Autorisation
Intégrité des messages
Fondation d’autres standards
WS-Secure
Conversation
WSFederation
WSAuthorization
WS-Policy
WS-Trust
WS-Privacy
WS-Security

15. WS-Secure
Conversation
WS-Security
WSFederation
WSAuthorization
WS-Policy
WS-Trust
14
WS-Privacy
WS-Security

Extension de SOAP : Définition d’un Header SOAP contenant l’information de sécurité

Confidentialité des messages SOAP
o
o
Utilisation d’une clef partagée
o

Utilisation de XML-Encryption pour un ou plusieurs éléments SOAP
Possibilité d’encrypter des éléments différents avec des clefs différentes
Intégrité des messages SOAP
o

Utilisation de XML-Signature
Authentification ou Autorisation
o
Utilisation des jetons de sécurité (Security Tokens) : login/mdp, certificat X509…

16. WS-Secure
Conversation
WS-Policy

WSAuthorization
WS-Policy
WS-Trust
WS-Privacy
WS-Security
Objectif: spécifier des informations et des exigences pour un WS
o
Pour la sécurité, qualité de service…
o

WSFederation
S’applique aussi bien au serveur qu’au client
Exemples:
o
Utilisation d’une version spécifique de SOAP
o
Exigence de signature
o
Information sur le format de la réponse (encryptée, signée...)
15

17. WS-Secure
Conversation
WS-Trust
WSFederation
WSAuthorization
WS-Policy
WS-Trust
WS-Privacy
WS-Security

Extension à la WS-Security

Gérer la génération, le renouvellement et la validation de jetons de sécurité

Problèmes
o
o

Émettre et obtenir des jetons de sécurité
Etablir et valider des relations de confiance
Permet de définir :
o
Les formats des messages permettant de demander des jetons ainsi que leurs réponses
o
Les mécanismes d’échange de clefs
o
Le concept de STS (Security Token Service)
o
Le principe de Délégation d’identité
16

18. WS-Secure
Conversation
Security Token Service

WSAuthorization
WS-Policy
STS
WSFederation
WS-Trust
17
WS-Privacy
WS-Security
Autorité en qui le client et le serveur ont confiance
o
Utilisé si le client et service sont dans des domaines de sécurité différents

Service web qui émet, valide ou échange un jeton de sécurité

Permet de :
o
o
Valider ou non un jeton de sécurité
o
Renouveler ou annuler un jeton de sécurité
o

Générer un jeton de sécurité basé sur des paramètres d’authentification
Transformer un jeton en un autre de type différent
Une demande de jeton de sécurité est envoyée par le client au STS via une requête RST (Request Security Token)
STS
1
2
Client
3
Service
1.
Client appelle STS pour s’authentifier, et obtient un jeton
1.
Client transfère le jeton à Service
1.
Service envoie le jeton au STS pour validation. (peut
également le faire en local, ou l’envoyer à un autre STS)

19. WS-Secure
Conversation
WSAuthorization
WS-Policy
Délégation d’Identité
WSFederation
WS-Trust
18
WS-Privacy
WS-Security

Utilisée si un service veut accéder à un autre service au nom du client

Extension du RST pour indiquer la délégation et le transfert des besoins
o
Utilisation par exemple de l’élément <wst:ActAs>
o
Demander au STS d’inclure dans le jeton de sécurité que ce service peut agir au nom de ce
client
1.
2.
3.
STS
1
2
Client
3
4
Service1
Service
6
5
4.
5.
6.
Client appelle STS pour s’authentifier, et obtient un jeton
Client transfère le jeton à Service
Service appelle STS pour s’authentifier en ajoutant un ActAs
à son RTS, référençant Client. Il obtient un jeton dont le sujet
est Client et contenant un ActAs référençant Service.
Service appelle Service1 en lui passant le jeton qu’il a reçu.
Service1 reconnait que Service agit au nom de Client, et lui
donne donc les accès vers la ressource demandée.
Service transfère la réponse à Client

20. WS-Secure
Conversation
WS-Privacy

WSFederation
WSAuthorization
WS-Policy
WS-Trust
WS-Privacy
WS-Security
Permet aux sites web de :
o
Spécifier leurs politiques de confidentialité
o

19
Vérifier que les requêtes entrantes respectent ces politiques
Décrire comment les politiques d’accès à un service web sont spécifiées et gérées

21. WS-Secure
Conversation
WS-Secure Conversation
WSFederation
WSAuthorization
WS-Policy
WS-Trust
20
WS-Privacy
WS-Security

Spécification des services web, permettant la création et le partage de contextes de
sécurité

Objectif:
o

Fournit une communication sécurisée entre les services web en utilisant les clefs de session
o

Établir des contextes de sécurité pour plusieurs échanges de messages SOAP, en réduisant le
surcoût de l’établissement des clefs
Clef de session: partagée par deux ou plusieurs entités dans un même contexte de sécurité
Établissement d’un nouveau contexte : génération d’un jeton de sécurité pour le contexte:
o
Par un STS (WS-Trust)
o
Par une des parties communicantes, il sera propagé ensuite par un message
o
Suite à une négociation

22. WS-Secure
Conversation
WS-Federation
WSFederation
WSAuthorization
WS-Policy
WS-Trust
21
WS-Privacy
WS-Security

Fédération : Ensemble de domaines ayant établi une relation de confiance

Spécification qui définit des mécanismes de fédération d’espaces de confiance
hétérogènes

Objectif:
o
SSO à travers des domaines de confiance en utilisant les identités de ces domaines

Extension de WS-Trust, s’appuie sur WS-Security, WS-Policy et WS-SecureConversation

Description de règles de confiance entre des environnements hétérogènes
o
Permet donc l’authentification mutuelle d’applications utilisant des mécanismes de sécurité
hétérogènes, comme Kerberos et X509

23. WS-Secure
Conversation
WS-Authorization

WS-Policy
WS-Trust
22
WS-Privacy
WS-Security
Vérifier qu’une requête reçue (SOAP Request) est une requête que l’envoyeur est autorisé à
émettre, donc que le service est autorisé à y répondre
WS-Authorization
o

WSAuthorization
Autorisation :
o

WSFederation
Spécification qui décrit comment gérer les données et les politiques d’autorisation
Comment définir les demandes d’accès dans les jetons de sécurité?
o
Utilisation (entre autres) des Assertions : SAML

24. WS-Secure
Conversation
Service Assertion Markup Language
WSAuthorization
WS-Policy
SAML
WSFederation
WS-Trust
WS-Privacy
WS-Security

Standard informatique définissant un protocole d’échange d’informations de sécurité

Propose une solution pour le problème de SSO (Single Sign On)

Utilise la XML-Encryption et XML-Signature

Principalement 3 rôles
o
o
Le fournisseur d’identité
o

L’utilisateur
Le fournisseur de service
Protocole de communication :
o
L’utilisateur envoie une requête au fournisseur de service
o
Le fournisseur de service demande une assertion d’identité au fournisseur d’identité (SAML)

Selon cette assertion, une décision de contrôle d’accès est prise
23

25. OWASP
Top 10 des Risques de Sécurité des Services Web

A1 : Manque d’authentification

A2 : Manque d’habilitation

A3 : Manque de trace d’audit

A4 : Manque de politique de sécurité

A5 : Défaillance XML

A6 : Détournement d’identité

A7 : Faiblesse de clefs

A8 : Stockage cryptographique non sécurisé

A9 : Communications non sécurisées

A10 : Manque de restriction d’accès à une URL
24

26. 25
Sources

Sites Web


OWASP web site : https://www.owasp.org/index.php/Main_Page, consulté le 24/11/13
Présentations
o
Sébastien Gioria: Introduction à la sécurité des Web
Services, CONFOO, Montréal, Canada, 10 Mars 2011