Chp5 - Sécurité des Services

  • 493 views
Uploaded on

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

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

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
493
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
21
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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