Sécurité 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 1
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> <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> <auth-constraint> le rôle qui lui est associé <role-name>directeur</role-name> </auth-constraint> </security-constraint> la ressource à protéger 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 <login-config> </login-config> <auth-method>basic</auth-method> authentification de base <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>
10 Exemple 1 : formulaire d'authentification
11 Exemple 1 : affichage de la page protégée
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> <head> Valeurs spéciales à utiliser <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>
14 Exemple 2 : affichage du formulaire
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>
16 Exemple 2 : utilisateur reconnu
17 Exemple 2 : utilisateur n'ayant pas les droit d'accès
18 Exemple 2 : accès refusé
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 Alice Annuaire des clés publiques clé publique de Bob (CPb) clé publique d'alice(cpa) Bob Mess clé publique de Bob (CPb) message en clair Mess message en clair clé privée de Bob (CSb) message crypté chiffrement canal non sécurisé CPb(Mess) message crypté déchiffrement
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)) déchiffrement par CSb Bob confidentialité CSa(Mess)) authentification déchiffrement pas CPa Mess
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 Navigateur Serveur (CPc,CSc) connaît CPs Authentification du destinataire (CPs,CSs) connaît CPc déchiffrement avec CPs, puis comparaison CSs(CPs) CPs chiffrée avec CSs = 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é CPs(CléSym) clé symétrique déchiffrée par CSs => connaissance privée commune (dé)chiffrement par clésym => Mess CléSym(Mess) (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> <auth-constraint> visibilité de la ressource <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