Le document aborde la sécurité informatique, en mettant l'accent sur les menaces auxquelles les applications, y compris les services web, doivent faire face, ainsi que sur les solutions disponibles pour y faire face. Il décrit diverses vulnérabilités comme le cross site scripting et l'injection XML, ainsi que des technologies de sécurité telles que SSL, IPsec et les pare-feux XML. En conclusion, il souligne l'importance d'adopter des mesures de sécurité au niveau des messages pour garantir la confidentialité et l'intégrité des échanges.

1. 29/11/2011
1
Chapitre 2-
Sécurité Informatique
1
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
2

2. 29/11/2011
2
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

3. 29/11/2011
3
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
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.

4. 29/11/2011
4
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.
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.

5. 29/11/2011
5
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.
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.

6. 29/11/2011
6
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

7. 29/11/2011
7
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
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

8. 29/11/2011
8
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
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.

9. 29/11/2011
9
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).
Pare-feu traditionnels // Pare-feu XML
18

10. 29/11/2011
10
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 ServiceWeb)
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.
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 :

11. 29/11/2011
11
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.
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

12. 29/11/2011
12
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.