docServeur
download 
Plainte Transcription
Serveur
Sécurité
•
•
•
•
•
•
•
1
Les différents aspects de la sécurité
l'authentification HTTP
Fonctionnalités de la cryptographie
Cryptographie à clé publique
Certificats numériques
SSL (Secure Socket Layer)
Configuration SSL
Introduction
2
Les échanges entre un client et un serveur web nécessitent d'être
sécurisés selon plusieurs aspects :
authentification un client veut être sûr qu'il parle bien au serveur
choisi et inversement
confidentialité le client et le serveur veulent être sûrs que les
informations qu'ils transmettent ne seront pas lisibles par d'autres
intégrité il faut aussi avoir l'assurance que les informations
transmises ne seront pas modifiées avant d'être reçues.
habilitation limitation de l'accès aux ressources d'un serveur à un
groupe d'utilisateurs sélectionnés
Authentification HTTP
3
Le serveur web maintient une BD des noms et mots de
passe utilisateurs
Basée sur un modèle de question/réponse à travers une
boîte de dialogue
Possibilité de protéger des ressources identifiées
Mais les infos transmises sur le réseau ne sont pas
réellement cryptées
Limitation : pas de prise en charge de la confidentialité
ni de l'intégrité
Acceptable dans un environnement ne nécessitant pas
une forte sécurité (sites payants)
Configuration de l'authentification
HTTP
4
Basée sur web.xml
Définition de contraintes de sécurité pour l'accès
aux pages
Habilitation des utilisateurs ou des groupes
d'utilisateurs basée sur la notion de rôle
Pour chaque rôle un type d'accès est spécifié
Mais la liaison entre rôle et utilisateur dépend du
serveur
Sous tomcat /conf/tomcat-users
Exemple 1 : authentification de
base
5
Une nouvelle grille du loto est tirée mais pas
encore publiée
L'application web n'accorde l'accès à la page
web qui affiche la future grille gagnante qu'aux
utilisateurs dont le rôle est "directeur"
6
Exemple 1 : la servlet à
protéger
public class GrilleCachee extends HttpServlet {
protected void doPost(
HttpServletRequest request,HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
try {
out.println("<html>");out.println("<head>");
out.println("<title>Servlet GrilleCachee</title>");
out.println("</head>");out.println("<body>");
out.println("<h1>La grille cachée gagnante est :
45,32,17,5,1</h1>");
out.println("</body>");out.println("</html>");
} finally {
out.close();}}
Exemple 1 : web.xml
7
<security-constraint>
la ressource à
protéger
<display-name>UneContrainte</display-name>
<web-resource-collection>
<web-resource-name>Secret</web-resource-name>
<url-pattern>/GrilleCachee</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
le rôle qui lui est
associé
<role-name>directeur</role-name>
<auth-constraint>
</auth-constraint>
</security-constraint>
La page affichée par la servlet GrilleCachee ne sera vue que par les utilisateurs
associés au rôle directeur
Exemple 1 : web.xml
8
authentification de base
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
<security-role>
<role-name>directeur</role-name>
</security-role>
spécification du rôle de
sécurité
Exemple 1 : conf/tomcat-users
9
<tomcat-users>
<role rolename="tomcat"/>
<role rolename="role1"/>
<role rolename="directeur"/>
<user username="tomcat" password="tomcat" roles="tomcat"/>
<user username="both" password="tomcat" roles="tomcat,role1"/>
<user username="role1" password="tomcat" roles="role1"/>
<user password="boss" roles="directeur" username="boss"/>
<user password="admin" roles="manager,admin" username="admin"/>
</tomcat-users>
Exemple 1 : formulaire
d'authentification
10
Exemple 1 : affichage de la page
protégée
11
Authentification à base de
formulaire
12
L'authentification est basée sur des formulaires HTML
Possibilité de créer des formulaires de connexion
personnalisées
Prise en compte de ce modèle d'authentification par le
fichier de déploiement web.xml
Exemple 2 : le formulaire
personnalisé login.jsp
13
<html>
Valeurs spéciales à utiliser
<head>
<title>Connection</title>
</head>
<body>
<h2>Veuillez entrer vos nom et mot de passe</h2>
<form method='post' action='j_security_check' >
Votre identificateur :<input type='text' name='j_username'>
<br><br>
Votre mot de passe :<input type='password' name='j_password'>
<br><br>
<input type='submit'>
</form>
</body>
</html>
Exemple 2 : affichage du
formulaire
14
Exemple 2 : modification de web.xml
15
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>
/login.jsp
Page d'ouverture
</form-login-page>
<form-error-page>
/erreur.jsp
</form-error-page>
</form-login-config>
</login-config>
Exemple 2 : utilisateur reconnu
16
Exemple 2 : utilisateur n'ayant pas
les droit d'accès
17
Exemple 2 : accès refusé
18
Cryptographie
19
Science du secret (grec : kryptos)
Techniques de chiffrement : transformation
d'un message compréhensible en un message
opaque
Pour les décoder, il faut posséder une clé
Ces techniques s'appuient sur des propriétés
mathématiques
Cryptographie à clé publique
20
Chaque participant possède 2 clés, une clé publique et une clé
privée
La clé publique est utilisée pour crypter le message à transmettre
La clé privée est utilisée pour décrypter le message. Elle est non
calculable à partir de la clé publique en un temps raisonnable
La clé publique est disponible à tous à partir d'un annuaire
Les 2 clés sont liées mais il est impossible de dériver l'une des clé à
partir de l'autre
La base mathématique est celle de la factorisation de grands
nombres entiers (base de l'algorithme RSA Rivest, Shamir,
Adelman 1977)
Algorithmes à clé publique
21
Annuaire des clés publiques
clé publique de Bob (CPb)
clé publique d'Alice(CPa)
Alice
Bob
Mess
Mess clé publique de Bob
(CPb)
message
en clair
message
en clair
chiffrement
message crypté
clé privée
de Bob
(CSb)
déchiffrement
canal non sécurisé
CPb(Mess)
message crypté
Confidentialité
22
Garantir que l'information transmise sera inintelligible
à toute personne autre que les acteurs de la transaction
Un message crypté par Alice avec la clef publique de
Bob n'est déchiffrable que par ce dernier au moyen
de sa clef secrète :
on garantit ainsi la confidentialité de l'échange.
Mais Bob n'est pas sûr qu'Alice soit l'émettrice
L'analogie est celle de la boîte aux lettres : tout le monde peut envoyer
du courrier à Bob, mais seul Bob peut le lire
Authentification
23
Certifier à chaque correspondant que son interlocuteur est bien
celui qu'il prétend être
Message chiffré par Alice avec sa clé publique => seul le possesseur
de la clé privée peut le déchiffrer => échange confidentiel
Message chiffré par Alice avec sa clé secrète => déchiffrement par
quiconque possède la clé publique d'Alice => seule Alice peut en être la
source donc échange authentifié
(Alice)
CPb(CSa(Mess))
confidentialité
authentification
déchiffrement par CSb
CSa(Mess))
déchiffrement pas CPa
Mess
Bob
Intégrité
24
Garantir que le message n'a pas subi d'altérations.
Un message chiffré par Alice n'a pas pu être altéré par un tiers
car il aurait fallu, après qu'il l'ait décrypté, qu'il le recrypte avec
la clé secrète d'Alice.
On peut associer une signature numérique calculée à partir du
message initial. Celle-ci change si un caractère a été supprimé
ou modifié
Architecture de confiance
25
On sait authentifier la source de l'échange, mais si l'émetteur (Alice) ne connaît
pas personnellement son interlocuteur, comment être certain qu'il est bien celui
qu'il prétend être.
Cela a conduit à créer une autorité de certification (VeriSign, Thawte, ...)
qui délivre des certificats attestant de l'identité correspondant à une clé publique.
Le certificat délivré peut être considéré comme authentique car il est crypté avec
la clé secrète de l'autorité de certification
Si Alice utilise la clé publique de Bob, elle est certaine que c'est bien celle de Bob
On parle de tiers de confiance car ce dispositif permet à 2 personnes qui
ne se connaissent pas d'effectuer une transaction en toute confiance
Certificats numériques
26
Pour obtenir un niveau de sécurité plus élevé
Pour garantir confidentialité et intégrité et une
authentification plus fiable
Basés sur les techniques de cryptographie à clé
publique
Les clés sont stockées sur disque sous la forme
de certificats numériques
ils proviennent d'une autorité de certification
(verisign,...) qui les vérifient et les signent
Java intègre le support des certificats
numériques
Secure Socket Layer
27
Protocole qui se place entre le protocole niveau application HTTP
et le protocole niveau transport TCP/IP
Technologie qui permet une connexion sécurisée entre un navigateur web
et un serveur web. Il utilise la cryptographie à clé publique pour échanger
des clés symétriques qui chiffrent les échanges entre un client et un serveur
Quel que soit le sens de la transmission, les données sont d'abord cryptées
par l'émetteur puis envoyées et décryptées par le récepteur
Le protocole SSL peut être limité à un certain nombre de pages du site
et non au site tout entier. Les pages qui requièrent un accès sécurisé sont
par exemple : pages de login, pages possédant des informations personnelles,
pages de paiement électronique
Fonctionnement de SSL
28
Serveur
Navigateur
(CPc,CSc)
connaît CPs
Authentification du
destinataire
(CPs,CSs)
connaît CPc
CSs(CPs)
CPs chiffrée avec CSs
déchiffrement avec
CPs, puis comparaison
= CPs ? le navigateur contrôle si clé signée par tiers de confiance
sinon il demande à l'utilisateur décide de continuer ou pas
clé symétrique générée
pour la session
chiffrée par CPs
Confidentialité, Intégrité
(dé)chiffrement par cléSym
=> Mess
CPs(CléSym)
CléSym(Mess)
clé symétrique déchiffrée
par CSs => connaissance
privée commune
(dé)chiffrement par cléSym
=> Mess
29
Authentification des
applications web
Authentification serveur
Lors d'une tentative de communication avec un serveur web,
celui-ci présente au navigateur des certificats authentifiant le site convoité
SSL 2.0 n'offre que l'authentification coté serveur.
Authentification client
Essentiellement utilisé pour les transactions B2B, le serveur demande
un certificat au navigateur web pour prouver que l'utilisateur est bien celui
qu'il prétend être
SSL 3.0 offre une authentification coté client. Le serveur demande
le certificat du client.
30
31
Configuration de SSL
32
Pour qu'une application web soit sécurisée par SSL (HTTPS), il faut
configurer le descripteur de déploiement web.xml
la balise <security-constraint> doit contenir une balise
<user-data-constraint>
qui contient une balise <transport-guarantee>
qui prend de manière standard la valeur CONFIDENTIAL
CONFIDENTIAL implique que la donnée ne pourra pas être lue par un
tiers
Configuration de SSL
33
<security-constraint>
<web-resource-collection>
<web-resource-name> ... </web-resource-name>
<url-pattern> ... </url-pattern>
<http-method> ... </http-method>
</web-resource-collection>
visibilité de la ressource
<auth-constraint>
<role-name> ... </role-name>
</auth-constraint>
protection de l'échange
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transportguarantee>
</user-data-constraint>
</security-constraint>
Configuration de SSL
34
pour indiquer au serveur que les authentifications de l'application se
font sur la base des certificats du client et non avec un formulaire, il
configurer la balise <login-config>
<login-config>
<auth-method>
CLIENT-CERT
</auth-method>
</login-config>
Le mécanisme SSL est transparent pour les servlets à condition
de configurer le serveur
