29/11/2011

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

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

1
 29/11/2011

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

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

2
 29/11/2011

Sept besoins pour la sécurité

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

Services Web :besoins pour la sécurité

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.

3
 29/11/2011

Sécurité des services web: Vulnérabilités

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.

Vulnérabilités : Cross Site Scripting (XSS)

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

4
 29/11/2011

Vulnérabilités : Injection XML

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.

Vulnérabilités : Attaques SOAP

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.

10

5
 29/11/2011

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

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

6
 29/11/2011

Sécurité des services web

 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 ?

13

Une fausse bonne idée : HTTPS

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

7
 29/11/2011

Une fausse bonne idée : TLS

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

15

Principe d'un pare-feu XML

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.

16

8
 29/11/2011

Contrôler l'information

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

Pare-feu traditionnels // Pare-feu XML

18

9
 29/11/2011

Sécurité des services web

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.

19

Sécurité des services web

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

20

10
 29/11/2011

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.

21

La sécurité du transport ou du message?

Couche de transport Sécurité du message

Point à point
Bout en bout

Administration facile
complexe, plusieurs

S’applique à l'ensemble options de sécurité
des données utiles du
S’applique à des parties
message et à travers la des données utiles et
session seulement pour la requête

Dépendant du niveau ou la réponse
transport
Sécurité possible aussi sur
le niveau transport

22

11
 29/11/2011

Sécurité des services web

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.

23

12