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

Chp5 - Sécurité des Services

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Chp5 - Sécurité des Services

E-ServicesChapitre 5 – Sécurité des Services

Dr. Lilia SFAXI

GL5 - 2013-2014

Institut National des Sciences Appliquées et de Technologie Tunisie

Page 2: Chp5 - Sécurité des Services

2

Plan du Chapitre

Sécurité des Services

Sécurité des Web Services

Page 3: Chp5 - Sécurité des Services

3

Plan

Sécurité des Services

Sécurité des Web Services

Page 4: Chp5 - Sécurité des Services

4

Besoins de la Sécurité

Services exposent des fonctions métier : besoin de protéger :

o Les règles métier

o Les données

o 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

Page 5: Chp5 - Sécurité des Services

5OWASPOpen 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 Enterprise Security API: bibliothèque de contrôle de la sécurité des applications web

o 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

Page 6: Chp5 - Sécurité des Services

6OWASPTop 10 des Risques de Sécurité des Applications (1/2)

A1 : Injection (SQL, OS, XPath, Hibernate…)

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

A2 : Violation de Gestion d’Authentification et de Session

o Compromettre les mots de passe, clés, jetons de session s’approprier les identités des utilisateurs

A3 : Cross-Site Scripting (XSS)

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

Page 7: Chp5 - Sécurité des Services

7OWASPTop 10 des Risques de Sécurité des Applications (2/2)

A6 : Exposition de données Sensibles

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.

A7 : Manque de contrôle d’accès au niveau fonctionnel

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

Page 8: Chp5 - Sécurité des Services

8

Plan

Sécurité des Services

Sécurité des Web Services

Page 9: Chp5 - Sécurité des Services

9

Web Services

Page 10: Chp5 - Sécurité des Services

10

Protocoles Utilisés

IP

HTTP/SMTP/FTP/…

XML-RPC/SOAP/XML

WSDL

UDDIDécouverte

Description

Message XML

Transport

Page 11: Chp5 - Sécurité des Services

11

Protocoles de Sécurité

IP - IPSec

TCP – SSL/TLS

HTTP – HTTP Authentication

XML – XML Signature / XML Encryption

SOAP – WS Security / SAML / WS Policy

Relations de confiance – WS Trust/WS Federation/Liberty Alliance

Sécurité Web Classique

Page 12: Chp5 - Sécurité des Services

12

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.

Page 13: Chp5 - Sécurité des Services

13

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

Page 14: Chp5 - Sécurité des Services

14

WS-Security

Standard OASIS, permet de sécuriser les services web

Objectifs

o Authentification & Autorisation

o Confidentialité des messages

o Intégrité des messages

Fondation d’autres standards

WS-Security

WS-Policy WS-Trust WS-Privacy

WS-Authorizatio

n

WS-Federation

WS-Secure Conversation

Page 15: Chp5 - Sécurité des Services

15

WS-Security

Extension de SOAP : Définition d’un Header SOAP contenant l’information de sécurité

Confidentialité des messages SOAP

o Utilisation de XML-Encryption pour un ou plusieurs éléments SOAP

o Utilisation d’une clef partagée

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

WS-Security

WS-Policy WS-Trust WS-Privacy

WS-Authorization

WS-Federation

WS-Secure Conversation

Page 16: Chp5 - Sécurité des Services

16

WS-Policy

Objectif: spécifier des informations et des exigences pour un WS

o Pour la sécurité, qualité de service…

o 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...)

WS-Security

WS-Policy WS-Trust WS-Privacy

WS-Authorization

WS-Federation

WS-Secure Conversation

Page 17: Chp5 - Sécurité des Services

17

WS-Trust

Extension à la WS-Security

Gérer la génération, le renouvellement et la validation de jetons de sécurité

Problèmes

o Émettre et obtenir des jetons de sécurité

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

WS-Security

WS-Policy WS-Trust WS-Privacy

WS-Authorization

WS-Federation

WS-Secure Conversation

Page 18: Chp5 - Sécurité des Services

18STSSecurity Token Service

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 Générer un jeton de sécurité basé sur des paramètres d’authentification

o Valider ou non un jeton de sécurité

o Renouveler ou annuler un jeton de sécurité

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

1. Client appelle STS pour s’authentifier, et obtient un jeton

2. Client transfère le jeton à Service

3. Service envoie le jeton au STS pour validation. (peut également le faire en local, ou l’envoyer à un autre STS)ServiceClient

STS

1

23

WS-Security

WS-Policy WS-Trust WS-Privacy

WS-Authorization

WS-Federation

WS-Secure Conversation

Page 19: Chp5 - Sécurité des Services

19

Délégation d’Identité

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. Client appelle STS pour s’authentifier, et obtient un jeton2. Client transfère le jeton à Service3. 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.

4. Service appelle Service1 en lui passant le jeton qu’il a reçu.

5. Service1 reconnait que Service agit au nom de Client, et lui donne donc les accès vers la ressource demandée.

6. Service transfère la réponse à Client

Service1ServiceClient

STS

1

2

6

34

5

WS-Security

WS-Policy WS-Trust WS-Privacy

WS-Authorization

WS-Federation

WS-Secure Conversation

Page 20: Chp5 - Sécurité des Services

20

WS-Privacy

Permet aux sites web de :

o Spécifier leurs politiques de confidentialité

o 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

WS-Security

WS-Policy WS-Trust WS-Privacy

WS-Authorization

WS-Federation

WS-Secure Conversation

Page 21: Chp5 - Sécurité des Services

21

WS-Secure Conversation

Spécification des services web, permettant la création et le partage de contextes de sécurité

Objectif:

o Établir des contextes de sécurité pour plusieurs échanges de messages SOAP, en réduisant le surcoût de l’établissement des clefs

Fournit une communication sécurisée entre les services web en utilisant les clefs de session

o 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

WS-Security

WS-Policy WS-Trust WS-Privacy

WS-Authorization

WS-Federation

WS-Secure Conversation

Page 22: Chp5 - Sécurité des Services

22

WS-Federation

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

WS-Security

WS-Policy WS-Trust WS-Privacy

WS-Authorization

WS-Federation

WS-Secure Conversation

Page 23: Chp5 - Sécurité des Services

23

WS-Authorization

Autorisation :

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

WS-Security

WS-Policy WS-Trust WS-Privacy

WS-Authorization

WS-Federation

WS-Secure Conversation

Page 24: Chp5 - Sécurité des Services

24SAML Service Assertion Markup Language

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 L’utilisateur

o Le fournisseur d’identité

o 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

WS-Security

WS-Policy WS-Trust WS-Privacy

WS-Authorization

WS-Federation

WS-Secure Conversation

Page 25: Chp5 - Sécurité des Services

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

Page 26: Chp5 - Sécurité des Services

26

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