Chapitre 2- Sécurité Informatique 1 Responsable du cours : Héla Hachicha Année Universitaire : 2011 - 2012.

Présentation au sujet: "Chapitre 2- Sécurité Informatique 1 Responsable du cours : Héla Hachicha Année Universitaire : 2011 - 2012."— Transcription de la présentation:

1 Chapitre 2- Sécurité Informatique 1 Responsable du cours : Héla Hachicha Année Universitaire : 2011 - 2012

2 Sommaire  Types de menaces et solutions  Sept besoins pour la sécurité  Services Web : besoins pour la sécurité  Sécurité des services web: Vulnérabilités  Vulnérabilités : Cross Site Scripting (XSS)  Vulnérabilités : Injection XML  Vulnérabilités : Attaques SOAP  Sécurité des services web 2

3 Types de menaces et solutions Les applications qu’elles soient ou non constituées de services Web, doivent faire face à un certain nombre de menaces, qui sont :  Viol d’identité (Spoofing identity) : un utilisateur non accrédité s'approprier l’identité d’un utilisateur valide de l’application ;  Falsification des données (Tampering with data) : un utilisateur détruit ou modifie les informations sans autorisation ;  Répudiabilité (Repudiability) : la possibilité qu’un utilisateur puisse nier avoir effectué telle ou telle opération ;  Divulgation d'informations (Information disclosure ) : des données confidentielles sont rendues visibles à des utilisateurs non accrédités ;  Dénie de service (Denial of service) : l’application est rendue indisponible ;  Élévation de privilèges (Elevation of privilege ) : un utilisateur dispose un niveau d’accès à l’application supérieur à celui qui devrait lui être accessible. 3

4 Types de menaces et solutions Pour se prémunir de ces menaces, différentes techniques liées à la mise en œuvre de la sécurité sont envisageables :  Authentification : Identification des applications clientes d’un service Web. Les mécanismes d’authentification permettent de se prémunir contre l’usurpation d’identité (signature).  Autorisation : Définition des droits d’un client authentifié vis-à-vis d’une application. Les mécanismes de gestion des autorisations permettent d’éviter l’altération des données et la diffusion d’informations sensibles  Identité : Il est parfois nécessaire de véhiculer le contexte de sécurité de l’utilisateur authentifié via de multiples ressources du système d’information.  Sécurité des communications (Intégrité des messages) : il faut faire en sorte que les messages circulant sur le réseau restent privés (chiffrement) et non altérés (signature du message).  Audit : enregistrement des actions de l’application cliente, qu’elles soient autorisées ou non, pour garantir la non-répudiation. 4

5 Sept besoins pour la sécurité 5  identification: qui êtes vous?  authentification: comment fait-je pour savoir que votre identité est vraie?  autorisation: êtes vous autorisé pour effectuer cette transaction?  intégrité: est-ce que la donnée envoyée est la même que celle reçue?  confidentialité: Êtes vous sur que personne ne lit la donnée envoyée?  audit: enregistrement de toutes les transactions pour investiguer les problèmes de sécurité après les faits  non-répudiation: à la fois envoyeur et destinataire peuvent fournir une preuve légale pour une tierce partie qui atteste que :  L’envoyeur a effectivement envoyé la transaction  Le destinataire a reçu une transaction identique

6 Services Web :besoins pour la sécurité 6 Les points importants à prendre en compte, en ce qui concerne les Services Web, sont essentiellement :  l'authenticité : le client et le serveur sont ceux qu'ils affirment être,  la discrétion : les requêtes et les réponses ne sont pas écoutées par des personnes non autorisées,  l'intégrité : ces requêtes et réponses ne sont pas altérées,  la non-répudiation : le client et le serveur peuvent prouver, chacun pour sa partie en cas de contestation, que la transaction a réellement été effectuée.

7 Sécurité des services web: Vulnérabilités 7  Il existe plusieurs sortes de vulnérabilité que l'on peut rencontrer dans les services Web. La sécurité dans les services Web est quelque chose qui n'est pas encore bien en place et qui n'occupe pas encore une part importante des applications actuelles.  Aujourd'hui, grâce à l'utilisation du protocole SSL par exemple ou encore l'utilisation de signature XML, le risque de vol d'identité, d'interception des données ou encore l'atteinte à l'intégrité et à la confidentialité des données est donc diminué.  Mais ces mesures de sécurité n'apportent rien pour la minimisation des risques d'intrusions dans les applications. Une application dont le contrôle a été acquis pourra être corrompue.

8 Vulnérabilités : Cross Site Scripting (XSS) 8  Le Cross Site Scripting est une faille de sécurité que l'on rencontre dans les applications Web qui permet à un utilisateur malveillant d'afficher des pages web avec du code douteux.  Le principe est d'injecter des données au site Web par l'intermédiaire de paramètres par exemple et si les données sont transmise au site Web sans avoir été au préalable contrôlées, alors on peut en déduire qu'une faille de ce type est présente.  L'exploitation de ce type de faille permet à un intrus de réaliser les opérations suivantes :  Affichage d'un contenu non-interne au site (publicités, faux articles,…)  Redirection de l'utilisateur de manière transparente  Vol d'informations  Actions sur le site à l'insu de la victime  Plantage de la page ou du navigateur  Pour se prémunir de ce type de faille, il faut donc bien vérifier les informations qui sont transmise au site de façon à contrôler qu'elles ne soient pas potentiellement dangereuses.

9 Vulnérabilités : Injection XML 9  Le but de l'attaque par injection XML va donc être d'envoyer au serveur des données, simplement en rentrant des informations d'identification par exemple, mais en envoyant des caractères spéciaux qui pourrait ne pas être pris en charge par l'application et donc de porter atteinte à celle-ci.

10 Vulnérabilités : Attaques SOAP 10  Une requête SOAP, est décrite par un fichier WSDL qui indique la structure de la requête et ensuite, le message SOAP se compose d'un en-tête et d'un corps.  Lorsqu'on envoie une requête SOAP, on envoie des paramètres à l'application et celle-ci nous répond en nous renvoyant un message SOAP contenant les réponses aux requêtes.  Par exemple, une entreprise avec un système de gestion des stocks. On interroge la base de données par une requête SOAP en indiquant par exemple la référence de l'objet à recherche. L'application nous renvoie ensuite des informations comme par exemple le nom de l'objet.

11 Sécurité des services web Il y’a aujourd’hui de nombreuses applications en production mettant en œuvre des services Web. Ces applications sont sécurisées concrètement, en exploitant les mécanismes standards liés aux protocoles de transport sous-jacents :  SSL ( Secure Socket Layer ) : protocole conçu pour assurer la confidentialité des échanges entre un client et un serveur Web, sur différents protocoles de transport (en général, HTTP). 11

12 Sécurité des services web  IPSec ( IP Security Protocol ) : protocole de sécurité réseau faisant partie intégrante de la pile IP utilisé entre deux serveurs ou deux « passerelles de sécurité » (tout système intermédiaire qui implémente IPSec) ou entre un serveur et une passerelle afin de sécuriser les sessions en offrant des mécanismes d’authentification, d’intégrité et de confidentialité des données.  IPSec est implémenté sur Windows 2000, XP, 2003 Server et peut être utilisé par tout protocole de niveau supérieur : TCP (Transport Control Protocol), UDP (User Datagram Protocol ), ICMP (Internet Control Message Protocol), BGP (Border Gateway Protocol ). 12

13  Ce modèle de sécurité est un modèle simple, adapté aux solutions pour lesquelles les mécanismes de transport et la configuration des points de terminaison sont complètement maîtrisés (notamment sur les scénarios de type intranet). Cependant, quelles sont les limites d’une telle approche pour garantir l’intégrité et la confidentialité des messages ? Sécurité des services web 13

14 HTTPS permet le chiffrement et la signature du message, ainsi que l’authentification de l’appelant, ce qui permet de garantir la non répudiation, la confidentialité et l’intégrité des informations échangées. Mais dans certains contextes, cela se révèle insuffisant pour plusieurs raisons :  Le protocole SOAP n’est pas exclusivement lié au protocole HTTP  Il peut résulter une dépendance vis-à-vis de la plate-forme et du fournisseur de service de sécurité (NTLM, Kerberos...)  La topologie d’une solution distribuée fondée sur les services Web peut inclure de nombreux périphériques ou systèmes intermédiaires. Il est donc primordial de pouvoir sécuriser les échanges entre application et services transitant entre ces nœuds intermédiaires. Dans ce type de configuration, le protocole HTTPS ne gère qu’une sécurité de point à point (avec potentiellement une clé de session modifiée à chaque étape), pas de bout en bout. Comment faire alors pour maintenir le contexte de sécurité sur la globalité de la chaîne ? Une fausse bonne idée : HTTPS 14

15 Une fausse bonne idée : TLS 15 Protocole TLS  TLS= Transport Level Security  TLS permettent d’assurer l’intégrité et la confidentialité d’échanges de messages  Avantages  garanti la confidentialité point-à-point et pas application à application  garanti l’authentification point-à-point  garanti l’intégrité du message  Inconvénients :  Confidentialité = messages opaques  Pour avoir plusieurs serveurs de certificats TLS, il faut plusieurs ports d’écoute  Impossible d’utiliser un firewall HTTP  Impossible pour un relai d’annoter un message  peu adapté aux interactions complexes  Tous les routeurs SOAP doivent être sûrs

16 Principe d'un pare-feu XML 16  Un pare-feu traditionnel est inefficace pour éradiquer les menaces sur les services web.  Un pare-feu XML se déploie en aval du pare-feu traditionnel pour parer à ces vulnérabilités.  Un pare-feu XML est conçu spécifiquement pour inspecter les flux XML et SOAP sur protocoles de base HTTP/HTTPS et éventuellement sur des protocoles tiers.  Le pare-feu XML est déployé en tant que proxy du périmètre réseau : il masque l’adresse des équipements internes et accepte les requêtes vers des points périphériques extérieurs ou “virtuels”.  Les fonctionnalités de sécurité mises en œuvre se dimensionnent compte tenu du risque d’entreprise. Elles portent notamment sur :  la validation des messages,  la détection des exceptions,  la détection des intrusions,  le routage selon le type de contenu,  la transition de protocoles  la sécurité au niveau de la couche de message.

17 Contrôler l'information 17  Vérifier l’intégrité des requêtes et des réponses en validant la structure et la légitimité de tous les messages échangés.  Le pare-feu XML examine la syntaxe des messages SOAP pour détecter la présence de logiciels malveillants, qui s’immiscent dans les documents SOAP sous forme d’un fichier joint binaire.  Le pare-feu XML est adopté pour mieux maîtriser le degré de vulnérabilité aux spywares, vers, virus et autres programmes malveillants.  Les contrats de services web exposent de plus en plus des données essentielles d’entreprise.  Dans les pare-feu XML, de nouvelles fonctionnalités sont proposées :  détection de l’utilisation inappropriée des ressources et des privilèges  surveillance des flux d’informations confidentielles  détermination précise des conséquences d’évènements en utilisant les techniques d’analyse comportementale ou d’analyse statistique (taux, intensités, seuils et écarts).

18 Pare-feu traditionnels // Pare-feu XML 18

19 Sécurité des services web 19  En Résumé :  HTTP fournit un mécanisme d’authentification très simple  SSL: secure socket layer; un protocole pour transmettre des données encryptées (sécuriser les messages d'un Service Web)  HTTPS = HTTP over SSL: très utilisé  XML digital signature  non-repudiation  Cryptage les données  SSL crypte le message en entier; problème des intermédiaires.  XML encryption permet de crypter de manière sélective => Par contre, cette méthode ne permet pas l'authentification des parties, ne garantit pas leur intégrité et ne protège pas contre la répudiation.

20 Sécurité des services web 20  En résumé, dans ce modèle, la sécurité n’est garantie que par la plate-forme et le transport :

21 21 Sécurité des services web Adresser la problématique de sécurité à un niveau indépendant de la couche transport permet de pallier à ces limites. En se fondant sur une sécurité de niveau messages.

22 La sécurité du transport ou du message? 22 Couche de transport Sécurité du message  Bout en bout  complexe, plusieurs options de sécurité  S’applique à des parties des données utiles et seulement pour la requête ou la réponse  Sécurité possible aussi sur le niveau transport  Point à point  Administration facile  S’applique à l'ensemble des données utiles du message et à travers la session  Dépendant du niveau transport

23 Sécurité des services web 23 Plusieurs autres solutions émergent pour traiter ces problèmes, mais il est encore trop tôt pour déclarer un vainqueur. Citons :  la signature XML (OASIS), permettant de signer une partie du document,  le cryptage XML (W3C),  l'authentification par le protocole SAML (Security Assertion Markup Language -- OASIS).  Enfin, un dernier standard apparaît, appelé "WS-Security", qui adressera l'ensemble de ces problèmes.