Post on 13-Sep-2015
description
La scurit des applications Java EE
Par David Martin et lquipe dIppon Technologies Version 1.0 - 3 Janvier 2012
http://blog.ippon.fr 2 / 45
A propos d'Ippon Technologies 3
Nos Solutions 3
Notre offre scurit 3
Nous contacter 3
Licence 4
Introduction 5
Comment se dcline la scurit ? 6
Identifier les acteurs 6
Autoriser des actions 7
Rendre confidentiels les changes 7
Prvenir diffrentes attaques 7
Quelles rponses peut-on apporter sur une application Java? 11
Identifier les utilisateurs 11 La donne utilisateur : source et usage 11 Comment intgrer une application lidentification et lauthentification 11 Le point sur les protocoles (OpenID, SAML, OAuth...) 14 Solution centralise ou SSO 15
Autoriser les actions 16 Principe premier : associer un profil un utilisateur 16 Dclinaison technique : comment contrler les droits 17 Aller plus loin dans la modularisation 30 Approche centralise de la gestion des autorisations : intrt, limites 33
Scuriser les changes 34 O se situe le risque ? 34 Quelques rponses techniques 34
Se parer contre les attaques 35 Scuriser sa plate-forme dexcution 35 Le captcha contre lattaque brute force 39 Gestion des erreurs : le silence comme parade 40 XSS, injection de code : comment sen protger 40 Stratgie de gestion de lauthentification automatique 41
Conclusion 43
Remerciements 44
Ressources 45
S MMAIRE
http://blog.ippon.fr 3 / 45
A propos d'Ippon Technologies Ippon Technologies est une socit de services informatiques spcialise dans les technologies Java EE.
Socit fonde dbut 2002 sous la double impulsion de Sportifs de Haut Niveau et de Managers issus de
grandes socits de conseil en technologies, Ippon Technologies sest dvelopp autour de lexpertise
ncessaire la conception et lintgration de solutions logicielles la pointe des nouvelles technologies
de lentreprise, et notamment sur la plate-forme Java EE. Notre force passe avant tout par la richesse de
notre potentiel humain et notre positionnement original sur le march de l'externalisation. L'ensemble de
nos consultants sont des professionnels aguerris dans leur secteur et ont leur actif des expriences
dterminantes pour le dveloppement des entreprises.
Ippon Technologies intervient dans les domaines de lindustrie, de la distribution, des
tlcommunications, des services, de la banque et de la finance.
Nos Solutions
Expert historique des dveloppements spcifiques Java EE, Ippon Technologies a fait voluer ses
comptences vers un ensemble cohrent d'offres fonctionnelles et techniques.
Ces solutions mises en place par Ippon Technologies permettent dapporter une rponse de choix aux
problmatiques dentreprise suivantes :
Notre offre scurit
Leader dans les technologies Java EE depuis 2002, Ippon Technologies a une longue exprience des
problmatiques lies la scurit informatique. Nous assurons notamment depuis 2005 l'intgration, la TMA et
le pilotage hbergeur de l'extranet Espace Partenaires de la DGA homologu niveau "sensible dfense". Ippon
Technologies propose ses clients une offre "scurit des applications Java", qui inclut des audits de scurit,
du conseil en architecture, ainsi qu'un support pour l'exploitation d'applications sensibles.
Nous contacter
Vous pouvez retrouver toutes nos coordonnes sur www.ippon.fr/contact, nous joindre par mail
ladresse accueil@ippon.fr, ou contacter une de nos agences directement par tlphone :
Paris : 01 46 12 48 48
Rnover, par la refonte dapplications stratgiques vers
les nouvelles technologies et les nouveaux usages.
Fdrer, par la mise en place de portails dentreprise
collaboratifs et mobiles.
Intgrer, en facilitant lchange dinformation entre les
systmes laide des technologies dEAI, d'ETL et
dESB.
Diffuser, en facilitant l'accs l'information et aux
donnes par la mise en place d'interfaces riches et
mobiles.
Bordeaux : 05 35 54 62 26 Nantes : 02 40 48 28 06
http://blog.ippon.fr 4 / 45
Licence Cette prsentation vous est fournie sous licence Creative Commons Attribution Share Alike.
Vous tes libres de reproduire, distribuer et communiquer cette cration au public selon les conditions
suivantes :
Paternit. Vous devez citer le nom des auteurs originaux mais pas d'une manire qui suggrerait qu'ils vous soutiennent ou approuvent votre utilisation de l'uvre.
A chaque rutilisation ou distribution de cette cration, vous devez faire apparaitre clairement au public les conditions contractuelles de sa mise disposition sous licence identique Creative Commons Share Alike.
Chacune de ces conditions peut tre leve si vous obtenez l'autorisation du titulaire des droits sur cette uvre.
Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des auteurs.
http://blog.ippon.fr 5 / 45
Introduction Le besoin de scurisation va croissant avec le dveloppement continuel des changes. Les donnes
exposes sont de plus en plus nombreuses et peuvent donc susciter de plus en plus de convoitise. Une
tude publie en novembre 2011 par le cabinet PricewaterhouseCoopers (Global State of Information
Security Survey - 2011 [1]) illustre bien le risque rel encouru : en 2011, 6 entreprises sur 10 ont connu un
incident de scurit et 20% des entreprises ont accus une perte financire directement imputable un
incident de scurit. Ces chiffres sont en augmentation par rapport ltude de lanne prcdente. Le
vol de proprit intellectuelle, la dgradation de limage et la perte de confiance sont autant de
consquences lourdes pouvant affecter chaque entreprise. Personne nchappe cette menace. Les
gants du net et de lindustrie sont aussi concerns, que ce soit Sony avec les attaques sur son rseau
PlayStation Network dont le cot est estim 170 millions de Dollars ou Amazon et ses Amazon Web
Services, pour lesquels des failles ont t identifies par des chercheurs allemands de la Ruhr-Universitt
Bochum, permettant ni plus ni moins que de soctroyer des privilges administrateurs.
Conserver le contrle sur les donnes et les services est donc une ncessit. Cela peut mme tre une
obligation. En effet, afin de limiter au maximum les risques de fraude sur les cartes bancaires, les
entreprises disposant dapplications o la saisie dune carte bancaire est ncessaire doivent se conformer
un standard international : le Payment Card Industry Data Security Standard ou PCI DSS [2]. Ce
standard, rendu plus strict dans sa version 2.0, impose la mise en uvre dun certain nombre de mesures
afin de protger les donnes bancaires manipules.
De faon gnrale, il apparat donc comme ncessaire dune part dassurer aux personnes autorises un
accs aux ressources et dautre part de restreindre ou interdire tout usage celles ne disposant pas des
droits suffisants.
Le primtre de ce livre blanc prsente les principaux aspects de cet enjeu dans le cadre des applications Java.
Il va de soi que la scurit ne s'arrte pas l et ncessite dintgrer dautres lments. Par exemple, une
des formes les plus efficaces dans le vol de donnes est dorigine humaine : le social engineering.
Gagner la confiance dune personne pour lui soutirer des informations confidentielles, comme ses
identifiants, est une pratique rpandue et motive par sa redoutable efficacit et sa facilit de mise en
uvre. La scurit nest donc pas quun ensemble de mesures techniques : il sagit dune pratique qui
doit tre adapte tous les niveaux, commencer par la sensibilisation des individus aux risques
encourus et leur responsabilisation face aux consquences possibles.
http://blog.ippon.fr 6 / 45
Comment se dcline la scurit ? Dans le cadre de ce livre blanc, la scurit est aborde sous plusieurs aspects. Chacun vise rpondre
un besoin prcis. Certains aspects sont par ailleurs intimement complmentaires.
On pourra discerner deux thmes majeurs dans lesquels ces diffrents aspects peuvent tre catgoriss.
Ce sont dune part la gestion et le contrle des droits daccs aux ressources et, dautre part, la protection
contre les actes malveillants.
Le premier thme concerne la connaissance de lutilisateur et la personnalisation des autorisations qui en
dcoule pour assurer un accs matris aux donnes et services et dans certains cas, un accs
confidentiel ceux-ci.
Le second thme est la rponse apporter aux tentatives daccs frauduleuses des donnes rputes
scurises. Le spectre de ltude sera cependant limit dans ce livre aux sujets en rapport direct avec la
nature des applications tudies. Ce second thme inclut aussi les rponses possibles pour veiller ce
que ces actes malveillants ne perturbent pas les accs aux ressources pour les utilisateurs lgitimes.
Identifier les acteurs
Connatre lidentit des utilisateurs est une des premires tapes lorsque la scurisation de laccs des
ressources est souhaite. Identifier un utilisateur, ou plus gnralement une entit (en effet, une
ressource peut tre accde par un utilisateur ou un systme), va traduire la capacit reconnatre celle-
ci. Deux termes sont lis la connaissance de lentit : lidentification et lauthentification.
Lidentification concerne la capacit reconnatre une entit. Elle va reposer par exemple sur un
matricule ou une clef unique pour lentit. La connaissance de cette clef va permettre dassocier une
identit un acteur ou entit.
Lauthentification est trs souvent couple lidentification. Son rle est de vrifier que l'identit fournie
est bien lgitime. Elle va mettre en jeu dautres informations, comme un mot de passe, une empreinte
digitale, dans le but de vrifier que lentit est bien celle quelle prtend tre.
Pour les applications en entreprise, les premiers utilisateurs sont trs souvent les collaborateurs de
lentreprise elle-mme. Cette population a lavantage dtre trs souvent connue des systmes internes
(messagerie, paie, ...). En gnral, les collaborateurs sont rfrencs dans un systme, le plus souvent
un annuaire dentreprise, et un certain nombre de progiciels et systmes puisent dans ce rfrentiel pour
leurs propres besoins de scurit.
Les utilisateurs peuvent aussi venir dautres cercles, plus larges : des partenaires, des clients ou des
utilisateurs totalement extrieurs (internautes par exemple).
Quelle que soit la catgorie laquelle un utilisateur appartient, il est possible de mettre en place des
mcanismes permettant de collecter et grer les informations ncessaires son identification et son
authentification.
http://blog.ippon.fr 7 / 45
Autoriser des actions
Une fois une entit identifie et authentifie, il importe de dfinir ce quelle a le droit de faire.
Le seul fait dtre reconnu dun systme donne rarement le droit aux pleins pouvoirs sur les ressources
quil gre. Il est trs souvent ncessaire daffiner la granularit et didentifier les ressources et actions
possibles et de savoir autoriser ou non ces actions sur les ressources concernes.
La gestion des autorisations va donc consister en la capacit associer une identit particulire un
certain nombre de droits valides dans un contexte donn et de les faire respecter au sein de lapplication
ou du service.
Rendre confidentiels les changes
Que faire lorsquil existe un risque dtre cout aux portes ? Parler dans une langue qui nest connue
que par les personnes autorises est une solution possible. Cette approche peut tre tendue aux
systmes dinformation : si les changes entre un client et un fournisseur ne sont comprhensibles que
deux seuls, le risque de dtournement des informations est considrablement limit.
Prvenir diffrentes attaques
La notion de faille de scurit nest trangre personne. Un certain nombre de techniques exploitant
ces failles sont mises en uvre dans le but de dtourner des informations sensibles ou de nuire
lapplication en la rendant indisponible. Les applications Java ne font pas exception et sont exposes
ces actes malveillants. Il convient de les connatre pour pouvoir leur apporter une rponse efficace.
Les applications Web ont leur lot de failles possibles et dattaques associes, certaines plus connues que
dautres. Voici une prsentation des principales :
Le Cross Site Scripting
Le Cross Site Scripting (CSS ou XSS) est une technique visant faire excuter un code tranger une
application au sein dun de ses crans. Il est ainsi possible de dtourner des informations sensibles et de
les communiquer un tiers. Bien que le JavaScript soit le langage le plus souvent utilis pour ces
attaques, il nest pas le seul. Il est tout fait possible de raliser ce type dattaque avec un script
malicieux crit en Flash ou Java ou autre encore...
Voici un scnario classique dattaque XSS. Considrons une page dune application utilisant une variable
passe en paramtre de la requte HTTP :
http://application/page?variable=valeur
En rponse, lapplication affiche la valeur de la variable :
[...]
Voici la valeur : valeur
[...]
http://blog.ippon.fr 8 / 45
Imaginons que la valeur soit remplace par un code JavaScript bnin :
http://application/page?variable=alert(document.cookie)
La page retourne excutera dans le navigateur la portion de code JavaScript injecte. Si maintenant le
code redirige ces donnes sur un serveur externe, les donnes pourront tre dtournes et drobes.
Ce type dattaque peut utiliser le spam comme vecteur dun lien HTML corrompu, sappuyant sur une
application cible sur laquelle la faille aura t identifie. A noter que ce type dapproche (spam) est aussi
utilis dans les attaques de type phishing (souvent traduit en hameonnage ).
Un autre moyen de rpandre ce type dattaque est darriver faire en sorte que le code malicieux soit
sauvegard dans la page de telle sorte qu chaque affichage ultrieur, il sexcute dans les navigateurs.
Il sagissait dune attaque classique sur les sites de type forum de discussion dans lesquels les
commentaires pouvaient tre rdigs sans contrle sur les donnes saisies.
Linjection de code
Linjection de code est un type dattaque assez large. Le Cross Site Scripting peut dailleurs tre
considr comme une des formes dinjection. Les autres formes qui vont tre prsentes ici concernent
linjection de code destin tre excut sur le serveur.
Tout comme le XSS, il est possible dinjecter du code de diffrents langages. Le plus commun reste
linjection de code SQL, mais linjection de requtes LDAP par exemple peut aussi tre dune redoutable
efficacit.
Le principe va reposer sur lutilisation de caractres spciaux pour injecter une portion de code qui,
concatne un code lgitime, va venir modifier le comportement attendu.
Lexemple trivial, que chaque dfinition dinjection de code SQL reprend, concerne lauthentification sur
une application. Typiquement un identifiant et un mot de passe sont demands sur la page
dauthentification et on peut imaginer quune requte va ensuite tre passe sur le serveur pour valider
ces donnes. Considrons que cette requte est une requte SQL, cela pourrait donner ceci :
SELECT user.name, user.isAdmin FROM Users WHERE user.login = ' + login + ' AND user.password =
' + password + ';
NOTE : Cet exemple est lanti-pattern par excellence, le stockage du mot de passe tant ici en clair dans
la base de donnes... ce qui bien sr nexiste pas dans les applications en entreprise.
Si la variable password contient un ordre SQL judicieusement format, il sera concatn la requte et
en modifiera le comportement nominal attendu.
Voici un exemple pour illustrer ceci :
password = "blabla' OR 'a'='a" mnera la cration de cette requte :
SELECT user.name, user.isAdmin FROM Users WHERE user.login = 'login' AND user.password =
'blabla' OR 'a'='a';
Laquelle sera toujours vraie du fait de la clause OR a = a
Le dni de service (direct ou distribu)
Le dni de service est une attaque dun type diffrent car sa finalit est de rendre indisponible une
application. Les cibles sont en gnral des applications publiques.
http://blog.ippon.fr 9 / 45
Lapplication victime peut, lissue dune telle attaque, soit tre totalement mise hors service ou tre
fortement dgrade.
Plusieurs techniques utilisant des failles diffrentes peuvent tre mises en uvre pour arriver cet tat.
Le principe partag par la plus grande partie des techniques utilises est de surcharger lapplication, par
un envoi massif de requtes, jusqu croulement dun des maillons sous la charge occasionne. Selon
lattaque, la nature de lapplication et de linfrastructure sur laquelle elle sexcute, le point de faiblesse
pourra tre la ressource processeur, la mmoire, un quipement rseau, lespace disque...
Les attaques de type dni de service peuvent tre issues dune seule source ou tre le fruit dune action
coalise. On parlera dans ce second cas dattaque distribue. Les acronymes, anglophones, pour
caractriser les attaques de type dni de service sont DoS et DDoS respectivement pour Denial of
Service et Distributed Denial of Service.
Nous verrons plus loin dans ce livre quelques parades pour limiter certains scnarios possibles dattaque
mais selon lampleur et la technicit de ces attaques, elles restent une menace difficile radiquer.
Les attaques par force brute ou dictionnaire
Ce type dattaque a pour but lusurpation didentit. Le principe va consister raliser un grand nombre
de tentatives de connexion sur un systme jusqu identifier les informations dauthentification. Elles
peuvent sappuyer sur un dictionnaire des possibilits les plus courantes pour accrotre leur efficacit.
Dtournement de session
Le dtournement de session (ou session hijacking en anglais) est une technique permettant lusurpation
didentit auprs dune application en se faisant passer, grce la rcupration frauduleuse de
lidentifiant de session, pour un autre utilisateur.
Chaque session dispose dun identifiant unique. Cest la clef qui va permettre lapplication de travailler
avec le jeu de paramtres propres lutilisateur. Dtourner la session va donc consister rcuprer cet
identifiant afin de pouvoir excuter des requtes au nom dun tiers lgitime, avec toutes les
consquences qui en rsultent.
Voici quelques approches possibles pour rcuprer cet identifiant :
La premire, et la moins probable, consiste essayer de deviner cet identifiant. Si cela a pu tre possible
une certaine poque, cest maintenant quasiment impossible compte tenu des clefs uniques gnres.
Le moyen pour cela est soit lusage dune mthode de type brute force pour esprer finalement identifier
une clef valide, soit par dduction (analyse du pattern des clefs, des squences possibles, ).
Une autre approche, dont le succs est plus probable, est la capture de lidentifiant de session. Nous
lavons vu prcdemment avec le Cross Site Scripting, dtourner des informations est rendu possible et
assez simple si lapplication prsente ce type de faille. Il existe aussi dautres moyens de capturer cette
information, via lcoute rseau (ou network sniffing) par exemple. Cette possibilit est dautant plus
simple si lutilisateur a recours une connexion non scurise via un point daccs WiFi public pour
accder lapplication. Il existe en effet des outils spcifiquement raliss pour cela et rendus publics (et
donc accessibles au plus grand nombre) comme Firesheep.
La troisime mthode est plus subtile : elle consiste faire en sorte que lutilisateur pig utilise un
identifiant de session prdfini par lattaquant. Cette forme est appele fixation de session (ou, en
http://blog.ippon.fr 10 / 45
anglais, session fixation). Elle peut tre mise en uvre de plusieurs faons, partageant le mme principe
: faire se connecter lutilisateur sur le serveur de lapplication vise avec un identifiant de session dj pr
tabli plutt que de laisser le serveur lui en gnrer un.
Les frameworks de scurit proposent en gnral des parades contre ce type dattaques, comme illustr
plus loin dans ce livre blanc.
http://blog.ippon.fr 11 / 45
Quelles rponses peut-on apporter sur une application Java? Au fil des paragraphes suivants, des cas concrets, appliqus aux applications Java, vont tre prsents
pour illustrer les diffrentes facettes de la scurit (identification / authentification, autorisation, protection
contre les vulnrabilits, ...) et les rponses possibles associes. Les rponses apportes seront pour
certaines assez gnralistes ; elles pourraient de ce fait sappliquer dautres types dapplications crites
dans des langages autres que Java.
Identifier les utilisateurs
La donne utilisateur : source et usage
Lutilisateur dune application, quel quil soit, est qualifi par un certain nombre de caractristiques.
Certaines serviront son identification, dautres son authentification et ses autorisations, dautres
encore pour des besoins purement mtier (tat civil, adresse de facturation, poste occup, prfrences
dachat...).
Nous naborderons pas la gestion des identits mais mettrons un accent particulier sur les informations
relatives aux diffrents aspects de la scurit : donnes didentification, dauthentification, potentiellement
donnes de chiffrement,
Lutilisateur sera donc identifi sur cette base dinformations, laquelle se matrialisera le plus souvent
sous deux formes rpandues : lannuaire et la base de donnes. Ces informations ne seront en gnral
pas accdes directement mais plutt au travers dun service ddi.
Lannuaire est une organisation arborescente de donnes accessibles au travers des interfaces
standardises (LDAP) respectant un formalisme prcis issu des normes X.500. Cest donc une rponse
sur mesure pour la gestion des identits et des caractristiques associes.
Cependant, il est aussi trs commun de trouver la base de donnes comme rponse au stockage de ces
informations, surtout si celles-ci ne sont pas centralises mais sont la proprit dune application en
particulier.
Comment intgrer une application lidentification et lauthentification
Pour quune application soit en mesure didentifier chaque utilisateur, il convient de linterfacer avec le
systme en charge du stockage des donnes didentification. Il sagit en gnral soit dun annuaire
dentreprise soit dune base de donnes, plus rarement dautres systmes.
Plusieurs solutions soffrent alors aux dveloppeurs ou architectes dapplications Java. Elles admettent
chacune des avantages et inconvnients qui seront dtaills dans ce livre blanc.
Il est possible de diffrencier deux approches distinctes : selon la norme Java EE dune part et par des
moyens tiers dautre part. La premire que nous aborderons est celle soutenue par les spcifications
Java EE. Elle repose sur un ensemble de services fournis par le serveur dapplications et va permettre
lapplication de dlguer de ce fait un certain nombre de tches ce dernier. En voici les principes :
http://blog.ippon.fr 12 / 45
Identification / Authentification selon la norme Java EE
La spcification Java EE propose un cadre pour grer les aspects de la scurit dans les applications et
services. Elle impose que les serveurs dapplications fournissent les outils ncessaires la scurisation.
Les contraintes de scurit concernant une application, un module ou un service peuvent tre exprimes
de deux faons : dclarative ou programmative.
Lapproche dclarative peut prendre deux formes : la premire fait usage des descripteurs de
dploiement et la seconde utilise un jeu dannotations spcifiques. Certaines ressources pourront tre
dfinies comme sujettes des contraintes daccs et une mthode dauthentification sera alors dcrite
pour le serveur dapplications. Lors dune tentative daccs une ressource protge, le serveur
excutera la procdure dcrite par la configuration si lutilisateur courant nest pas encore identifi.
Pour procder lauthentification, le serveur doit tre en mesure de confronter les donnes recueillies
avec des donnes relatives lidentit des individus. Les serveurs dapplications peuvent grer
localement des bases dutilisateurs ou sappuyer sur des systmes externes (annuaires LDAP, bases de
donnes, ...). Le serveur dapplications va manipuler plusieurs notions autour des identits : Realm,
Group, User, Role.
Gestion de lidentification / authentification autonome
Dans ce cas, la gestion de la scurit ne va pas sappuyer sur les mcanismes prconiss par la norme
Java EE mais sur une solution tierce, souvent sous la forme dun framework technique incorpor
lapplication qui prendra en charge lensemble des tapes.
Le framework le plus connu et le plus massivement utilis actuellement sur le march est Spring Security,
anciennement nomm Acegi Security. Toutefois, il existe des alternatives, techniquement et
fonctionnellement intressantes, mritant dtre connues, comme Apache Shiro.
Un framework comme Spring Security va fournir lensemble des composants permettant dadresser les
aspects de la scurit applicative, comme lauthentification.
Spring Security offre une configuration simplifie, car prdfinie, pour les cas dutilisation classiques.
Cette simplicit nempche pas de pouvoir paramtrer plus finement certains aspects afin de se
conformer des exigences particulires ou des cas dutilisation moins triviaux.
Le principe de fonctionnement de Spring Security repose sur une chane de filtres propres au framework,
appliqus via un point dentre unique : le DelegatingFilterProxy qui est un filtre Java EE
(javax.servlet.Filter). Chacun de ces filtres adresse un besoin spcifique li lidentification,
lauthentification ou lautorisation. La chane de filtres pourra tre recompose, complte, ... tout ceci par
simple configuration dans la plupart des cas.
La configuration minimale, qui offre un premier niveau de scurit une application, ne requiert que peu
de mise en uvre : la dfinition du filtre Java EE prcdemment voqu (charg de grer la chane de
filtres appliquer sur les requtes) et la dclaration de la configuration par dfaut du framework.
Dfinition du proxy dans le descripteur web.xml :
springSecurityFilterChain
org.springframework.web.filter.DelegatingFilterProxy
http://blog.ippon.fr 13 / 45
springSecurityFilterChain
/*
Et la dfinition des beans par dfaut, via lutilisation du namespace ddi de Spring Security :
Une application ainsi configure supporte dj lauthentification par formulaire et lauthentification de type
BASIC, ainsi quun filtre de dconnexion. Elle sappuie par ailleurs dans cet exemple sur un dpt
dutilisateurs dfini localement dans la configuration.
Bien sr, une application dentreprise devra toffer cette configuration pour se connecter par exemple sur
un annuaire dentreprise, plutt que sur une dfinition locale des utilisateurs, ce que Spring Security
permet facilement en proposant les implmentations adaptes pour les cas les plus frquents.
Dautres mcanismes didentification / authentification que la mthode BASIC (prcdemment cite et
active dans la configuration par dfaut) sont disponibles via le framework, parmi lesquels la mthode
DIGEST, le filtre RememberMe (permettant de stocker dans un cookie un ticket pour les connexions
futures), la dlgation un serveur CAS, le recours aux certificats X.509,
Dans tous les cas, les informations collectes serviront alimenter un contexte de scurit qui sera par la
suite utilis pour lapplication des rgles de scurit.
Synthse des deux approches
La spcification Java EE propose une solution suffisante pour apporter aux applications une premire
rponse en matire de gestion de lauthentification. Cependant, elle se confronte rapidement plusieurs
limitations, dont, en premier lieu, une souplesse moindre dans les possibilits de configuration et, par
ailleurs, une assez forte adhrence au serveur dapplications, lie la configuration spcifique qui doit y
tre ralise.
La gestion autonome par lapplication, via un framework ddi la scurit, apporte un lot de
fonctionnalits minima quivalent (et mme sensiblement plus riche) celles proposes par la
http://blog.ippon.fr 14 / 45
spcification Java EE tout en offrant des possibilits suprieures, dune part de configuration avance et,
dautre part, de personnalisation simplifie des comportements (par surcharge ou dfinition de
composants ddis).
Faire le choix initial de se reposer sur un framework ddi la scurit apportera donc la latitude de faire
voluer ultrieurement la finesse des rgles de scurit sans rencontrer trop rapidement des limitations.
Par ailleurs, ce type dapproche offrant un mme niveau de qualit en matire de scurit, les arguments
en faveur dune approche Java EE se limitent assurment quelques cas dutilisation isols.
Le point sur les protocoles (OpenID, SAML, OAuth...)
Diffrents protocoles sont cits lorsquil sagit dvoquer la scurit des applications web. Voici une
prsentation qui va permettre de mieux les comprendre et den saisir les diffrents cas dutilisation
possibles.
OpenID
OpenID offre une rponse technique clef en main ouverte la problmatique de SSO (Single Sign On ou
authentification unique) sur internet en mettant disposition des utilisateurs des instances charges de
grer leur identit (les OpenID Providers). OpenID fournit en outre aux sites sappuyant sur ce protocole
pour lauthentification (ces sites sont appels Relying Parties) un moyen de vrifier lidentit des
internautes sy connectant. Chaque utilisateur est identifiable par une URI propre, laquelle rfrence
lOpenID Provider vers lequel la Relying Party devra rediriger pour lauthentification.
OpenID est trs simple mettre en uvre et dispose dimplmentations clientes dans beaucoup de
langages, dont bien sr Java.
OpenID est actuellement en version 2.0. Ce standard nest pas parfait et souffre de faiblesses pouvant
permettre un certain type dattaques. Il reste cependant trs utilis par de grandes entits de linternet
(Microsoft, Yahoo, ...).
SAML (Security Assertion Markup Language)
SAML est une autre rponse au besoin de Single Sign On, promue par lOASIS. Elle repose sur trois
notions. La premire est lIdentity Provider, une entit conservant les informations dauthentification de
lutilisateur. La seconde est le Service Provider, un service auquel un utilisateur souhaite accder. Enfin la
troisime est lutilisateur lui-mme. SAML en tant que tel est un framework abstrait : il ne propose pas
directement de rponse technique. SAML dispose de profils, lesquels sont en charge de spcifier plus
prcisment les aspects techniques autour dune problmatique.
Le profil SAML Web Browser SSO se situe donc proche dOpenID. Dune faon gnrale, SAML
proposera une possibilit dadaptation beaucoup plus forte aux diffrents cas dutilisation quOpenID et
restera prfrable pour des applications complexes et/ou sensibles.
OAuth (Open Authorization)
OAuth est un standard ouvert pour rpondre un besoin de dlgation dautorisation. Ce standard
permet doctroyer le droit un service daccder selon certaines conditions (limitation dans le temps,
limitation du spectre des ressources accessibles, ...) des informations disponibles auprs dun autre
service sans avoir donner au premier ses informations didentification valides sur le second.
http://blog.ippon.fr 15 / 45
Solution centralise ou SSO
Le besoin de centraliser lidentification des utilisateurs afin de leur permettre de passer dune application
une autre sans leur redemander leurs informations personnelles est trs frquent et lgitime. Ce type
de solution gagne petit petit les entreprises et apparat aussi sur des applications publiques sur
lInternet, avec par exemple les applications Google Apps.
En entreprise, les gains sont multiples : la factorisation de la brique dauthentification apporte non
seulement un confort aux utilisateurs qui ne ressaisissent plus les donnes, mais aussi une meilleure
gestion de la scurit en conservant cette brique technique sous contrle unique plutt quen la voyant
duplique dans tout le parc applicatif, avec potentiellement des implmentations diffrentes laissant la
place des failles de scurit dans le dispositif du SI.
Ce march est investi par des solutions propritaires payantes (Evidian, ...) mais aussi par des acteurs du
monde de lopen source qui ont su crer des solutions de qualit. On pourra citer parmi ces solutions le
serveur CAS[9] (pour Central Authentication Service) de Jasig, qui figure parmi les solutions les plus
connues et reconnues.
Principe de fonctionnement du serveur SSO CAS
Le serveur CAS est une application autonome qui va tre sollicite pour diffrents services par dautres
applications. Il va tre configur pour sappuyer sur une ou plusieurs sources de donnes
dauthentification (annuaires, bases de donnes, fichiers, ). Il utilise son propre protocole mais peut
aussi se conformer aux protocoles OpenID et SAML par configuration.
La cinmatique mise en uvre dans une architecture utilisant CAS comme solution dauthentification
centralise se dcompose ainsi :
Un utilisateur souhaite accder une ressource protge sur une application dlguant CAS
lauthentification.
Lapplication contrle si cet utilisateur est dj connu (si elle dispose dj dune session
conscutive une authentification prcdente russie).
Si ce nest pas le cas, lutilisateur est redirig vers le service dauthentification du serveur CAS
avec comme paramtre le service (i.e. : lapplication) do il provient.
Le serveur CAS vrifie alors si cet utilisateur est dj connu de lui (par la prsence dun cookie qui
aurait t gnr lors dune authentification russie prcdente, quelle lait t sur cette mme
application ou sur une autre). Ce cookie est nomm Ticket Granting Cookie (TGC)
Si lutilisateur nest pas dj connu de CAS, le serveur va afficher une page contenant un
formulaire (configuration par dfaut de CAS) afin quil y saisisse ses identifiants.
Le serveur CAS les valide en oprant les recherches ncessaires dans le ou les systmes source.
Si la validation est OK, un cookie est cr sur le domaine du serveur CAS (le Ticket Granting
Cookie) et lutilisateur est redirig vers son service dorigine avec un autre ticket (appel Service
Ticket), exclusivement valide pour ce service et utilisable une seule fois.
A ce stade lutilisateur est revenu sur lapplication sur laquelle il souhaitait accder une ressource. Le
ticket qui lui a t transmis (Service Ticket) va tre utilis par lapplication pour lauthentifier et lui
permettre dobtenir ses habilitations locales (en vue dappliquer les rgles dautorisation).
Lapplication, pour valider le ticket et donc authentifier lutilisateur, appelle le service de validation de
tickets de CAS et lui passe en paramtre le ticket reu.
http://blog.ippon.fr 16 / 45
NOTE : cette fois, lappel est opr par lapplication elle-mme (il ny a pas de redirection sur le
navigateur de lutilisateur) et se fait vers CAS en HTTPS. Cette tape est donc totalement invisible pour
lutilisateur.
Lors de la rception dune demande de validation dun ticket, le serveur CAS ralise les oprations
suivantes :
Vrification que le ticket lui est connu et na pas dj t utilis.
Vrification que ce ticket est valide pour le service faisant la demande.
Si le ticket passe avec succs les deux vrifications, le serveur CAS retourne lapplication une rponse
positive accompagne de quelques informations sur lutilisateur (le nombre et la nature de ces
informations varient selon la configuration du serveur CAS) dont son identifiant. Lapplication pourra alors
utiliser cette donne pour identifier les rles associs cet utilisateur et lui affecter : il sagit ici de dfinir
le volet autorisation du contexte de scurit associ lutilisateur. La gestion de cette association rle -
utilisateur est la discrtion de lapplication ; la plupart du temps, ces donnes sont gres au sein mme
de lapplication, principalement en base de donnes.
Par ailleurs, lapplication pourra, si besoin, enrichir le profil de lutilisateur avec les ventuelles autres
donnes que le service de validation de ticket de CAS aurait pu lui transmettre.
Si le ticket nest pas valid par le service de CAS (cas dun ticket inconnu, dj utilis ou invalide pour le
service appelant), un message derreur est retourn lapplication. Elle pourra alors ventuellement
relancer le workflow.
Les deux concepts principaux ici sont, dune part, de dcharger les services (applications sappuyant sur
CAS pour le SSO) de toute connaissance des informations dauthentification des utilisateurs (typiquement
les mots de passe) et, dautre part, de permettre aux utilisateurs de sauthentifier une seule fois pour
lensemble des services auxquels ils ont accs.
Autoriser les actions
Principe premier : associer un profil un utilisateur
Dans une application, toutes les actions ne sont pas gales et certaines requirent de ne pas tre
laisses accessibles lensemble des utilisateurs. Afin dadresser ce besoin de filtrage, la notion
dhabilitation est utilise. Chaque utilisateur reoit un certain nombre dhabilitations qui lui autoriseront,
limiteront, voire empcheront laccs aux fonctionnalits de lapplication.
Comme les utilisateurs dune application sont susceptibles de changer et quil nest bien videmment pas
souhait qu chaque changement de ce type lapplication doive tre redploye, il convient dopter pour
une couche dabstraction entre les utilisateurs nomms et les privilges possibles dans lapplication.
Lapproche intuitive pour rsoudre ceci est la cration de profils, dots de privilges, qui seront associs
aux utilisateurs. Ainsi, lorsquun nouvel utilisateur est identifi, il convient juste de dfinir le ou les profils
le qualifiant pour quil puisse directement utiliser lapplication. Nous verrons un peu plus loin que ce
modle peut tre encore amlior pour rendre la gestion de la scurit plus souple.
http://blog.ippon.fr 17 / 45
Dclinaison technique : comment contrler les droits
Le contrle des droits peut soprer plusieurs niveaux, potentiellement cumulables. Selon la nature de
la ressource protger, ainsi que la technologie utilise pour exposer cette ressource, les possibilits
techniques peuvent varier. Voici une synthse des principales possibilits de contrle des droits selon ces
deux axes.
Scurisation des applications Web
La scurisation des applications Web, ou tout au moins de leur couche de prsentation, est le besoin le
plus commun. Nous allons voir quil existe plusieurs faons de procder pour cela et comprendre dans
quels cas les utiliser.
Lapproche dclarative par descripteur de dploiement
Lapproche dclarative selon la norme Java EE
La premire approche consiste en une expression dclarative des contraintes de scurit. Le descripteur
de dploiement (le fichier web.xml dans ce cas) est la mthode propose par la norme Java EE pour y
exprimer les contraintes de scurit de faon dclarative. Bien souvent, ce fichier est connu pour la
dclaration des servlets, filtres et autres listeners, un peu moins pour ces considrations de scurit.
Voici un exemple de ce quil est possible de faire avec ce descripteur.
Securing the Application Layer
pictureManagerServlet
fr.ippon.picman.PictureManagerServlet
admin
administrator
administrator
http://blog.ippon.fr 18 / 45
pictureManagerServlet
/pics/*
AppConfiguration
/pics/configuration/*
GET
POST
administrator
CONFIDENTIAL
BASIC
Dtaillons maintenant cet exemple.
Les tags intressants pour la scurisation de lapplication sont principalement , et .
Le premier tag, permet de dfinir la faon dont vont tre collectes les informations
dauthentification. Dans le cas prsent, cest la mthode dauthentification BASIC qui est dfinie.
NOTE : cette mthode passe les informations dauthentification dans len-tte de la requte HTTP
(header) avec un encodage Base64. Utilise seule, cette mthode est trs peu scurise du fait de
l'extrme simplicit pour dcoder la chane en Base64. Il est fortement conseill de lutiliser couple
une connexion HTTPS ou dutiliser une autre mthode.
Le tag permet de dfinir dautres types que BASIC, comme lauthentification par
formulaire (FORM), par certificat client (CLIENT-CERT), ou de type DIGEST (DIGEST).
Le tag permet dexprimer une contrainte daccs une ressource.
La ressource est identifie par un chemin (une URL) et un verbe HTTP (GET, POST, ) tous deux
exprims sous le tag .
Une contrainte dautorisation est ensuite dfinie sous . Elle va permettre de citer le (ou
http://blog.ippon.fr 19 / 45
les) rle(s) accept(s) pour cette ressource.
Enfin, le tag exprime les prrequis au niveau de la communication rseau. Les
trois valeurs admises sont NONE, CONFIDENTIAL et INTEGRAL. Les deux dernires ncessitent que la
communication soit effectue en HTTPS.
Le tag dfinit quant lui un rle utilis dans lapplication. Il peut tre utilis
conjointement avec le tag , ce dernier permettant de crer un alias entre le rle
dfini dans le conteneur dapplications et le nom du rle utilis dans le code de lapplication. En cas
domission, cest le rle dfini par qui est accessible dans le code de lapplication.
Lavantage de cette approche rside dans le fait quelle est supporte par un large nombre de
conteneurs, lgers et moins lgers. Cependant, cette approche est contrainte par ses capacits limites
de personnalisation de la configuration. Par exemple les patterns utiliss pour identifier les ressources
sont assez rudimentaires et peuvent savrer insuffisants dans certains cas.
Lapproche dclarative avec Spring Security
Lapproche descriptive peut aussi tre exprime sous une autre forme via lutilisation de frameworks
comme Spring Security, dj voqu dans la partie Authentification. En effet, Spring Security utilise,
parmi diffrentes mthodes, le filtrage dURL et permet dexprimer ces contraintes sous forme dclarative
dans son fichier de configuration (fichier descripteur du contexte Spring).
Si nous reprenons lexemple cit dans le cadre de lauthentification, ce dernier tait compos de la
dclaration suivante :
Le principe ici est donc identique : dfinir un pattern appliqu un chemin daccs (identifiant une ou
plusieurs ressources) et lui affecter une contrainte en spcifiant le rle devant tre possd par
lutilisateur pour lui octroyer laccs.
Le tag admet plusieurs attributs :
pattern : va reprsenter le pattern appliquer aux URL daccs aux ressources.
access : il sagit des attributs ou rles devant tre possds par lutilisateur pour obtenir laccs.
La richesse propose ici est assez importante. Il est possible dy crire des rgles mettant en jeu
plusieurs aspects, via des mthodes utilitaires fournies par le framework au travers des classes
WebSecurityExpressionRoot et SecurityExpressionRoot.
Un exemple de rgle pourrait tre :
method : reprsente la liste des mthodes HTTP (GET, PUT, POST, ) pour lesquelles la rgle
sapplique.
requires-channel : pourra prendre les valeurs HTTP ou HTTPS selon les besoins.
NOTE : Spring Security soccupera de la bascule automatique dun protocole vers lautre tandis
que lapproche Java EE via le descripteur de dploiement dlgue cette bascule au conteneur.
filters : peut prendre la valeur none et dans ce cas, bypasser la chane de scurit. Cette
fonction peut tre utilise pour des ressources comme la page de connexion pour lesquelles un
accs non contraint doit tre assur.
http://blog.ippon.fr 20 / 45
Spring Security propose un panel de possibilits beaucoup plus riche que lapproche Java EE. On
pourra citer quelques atouts :
Une implmentation unique garantissant un comportement identique quel que soit lenvironnement
dexcution : la configuration de Spring Security aura le mme comportement quel que soit le
serveur dapplications, ce qui nest pas forcment vrai pour lapproche Java EE (voir : Tomcat et la
gestion des )
Possibilit dcrire des patterns complexes (via le mode regexp en substitution du mode ant
dfini par dfaut, lequel propose dj une richesse syntaxique dpassant ce qui est propos par
Java EE).
Possibilit de surcharger des composants de la configuration afin dadapter le comportement un
besoin spcifique.
La gestion de la fonction remember me.
La gestion des sessions concurrentes (nombre maximum autoris de sessions parallles pour un
mme compte utilisateur). Peut tre utile par exemple pour contrler quun compte nest pas
partag par plusieurs personnes.
Lusage des mtadonnes
Les mtadonnes proposes par la norme Java EE
La spcification Java EE propose aussi de configurer les aspects de scurisation via lutilisation de
mtadonnes dans lapplication. Un panel dannotations est mis disposition des dveloppeurs pour
apporter leur application les outils de scurisation :
@DeclareRoles : dfinit un ou plusieurs rles utiliss dans lapplication. Cette annotation est
lquivalent de la dclaration suivante dans le descripteur de dploiement :
roleA
Il est ensuite possible dutiliser au sein de la classe annote la mthode isUserInRole par exemple
afin de vrifier si lutilisateur courant dispose ou non des rles exprims.
@RunAs : Cette annotation dcore les classes. Elle permet dexcuter une portion de code au
nom du rle cit et ouvre donc ainsi la possibilit de propager lidentit dans une cascade
dappels. Il existe aussi lquivalent pour le descripteur de dploiement (run-as).
@RolesAllowed : nautorise une action quau(x) rle(s) cit(s). Cette annotation ne ncessite pas
dtre accompagne de @DeclareRoles : en effet, les rles cits sont dclars de faon implicite.
@ServletSecurity (Servlet 3.0) : Cette annotation va permettre dexprimer des contraintes de
faon synthtique. Voici un exemple illustrant son fonctionnement :
@WebServlet(name="SimpleServlet", urlPatterns={"/SimpleServlet"})
// Pour toutes les mthodes HTTP, une appartenance aux rles auth_user ou guest
// est ncessaire.
@ServletSecurity(@HttpConstraint(rolesAllowed = {"auth_user", "guest"}))
public class SimpleServlet extends HttpServlet {
//
http://blog.ippon.fr 21 / 45
}
@HttpConstraint (Servlet 3.0) : Permet de dfinir une contrainte pour toutes les mthodes HTTP.
Voir exemple de @ServletSecurity ci-dessus.
@HttpMethodConstraint (Servlet 3.0) : Permet de dfinir une contrainte spcifique une mthode
HTTP.
Lalternative Spring Security
Spring Security fournit aussi un jeu dannotations permettant une dclaration par mta donnes (les
annotations) des contraintes de scurit. La gestion des autorisations va reposer sur un ensemble de
dfinitions sappuyant sur le jeu dannotations suivant :
@Secured, @PreFilter, @PreAuthorize, @PostAuthorize, @PostFilter
A noter que le support des annotations Java EE (issues de la JSR 250) est aussi propos (mais napporte
pas de fonctionnalit additionnelle aux annotations proposes par Spring) ; voir plus bas pour lactivation
de ce support.
Le cas dutilisation simple et souvent suffisant sexprime sous la forme :
@Secured("ROLE_ADMIN")
public User doSomething(final User user);
Laccs la mthode scurise ne peut se faire que si lutilisateur courant possde le rle ROLE_ADMIN.
Si lutilisateur ne satisfait pas cette contrainte, une exception (AccessDeniedException) sera leve lors de
la tentative daccs.
La conjonction de ces annotations avec lExpression Language de Spring permet dcrire des
expressions pouvant apporter un contrle trs fin des autorisations. Voici un exemple inspir par la
documentation de Spring Security illustrant ceci :
@PreAuthorize("#contact.name == authentication.name")
public void doSomething(Contact contact);
La mthode doSomething() ne pourra tre excute que si le nom du principal est gal au nom du
contact pass en paramtre la mthode.
Lactivation du support de ces annotations se fait au travers dune dclaration simple dans le fichier de
configuration de Spring Security :
active la prise en compte de @Secured
active la prise en compte des
annotations de la JSR 250
active la prise en compte des
annotations @Pre/@Post
Pour aller plus loin avec Spring Security
Les possibilits offertes par Spring Security ne sarrtent pas l. Il est par exemple possible de dfinir les
autorisations sous forme daspects (AOP) et ainsi centraliser les concepts en un point unique (ou un
nombre de points limits). Pour cela, le tag global-method-security mentionn plus haut admet des
dclarations de type protect-pointcut. Il est possible daller plus loin encore dans lAOP en faisant usage
des diffrents interceptors proposs par le framework (ex. : MethodSecurityInterceptor)
http://blog.ippon.fr 22 / 45
De plus, Spring Security propose dappliquer les autorisations non seulement aux mthodes appeles
mais aussi aux donnes manipules. Ainsi il est possible dactiver des contraintes dont la consquence
sera de filtrer une liste dobjets en retour dune mthode afin quaucun de ces objets nenfreigne la rgle
de scurit. Cette fonctionnalit (nomme ACL pour Access Control List) va donc prendre en compte non
pas deux, mais trois axes : qui, comment et quoi, concernant respectivement lutilisateur, la mthode
utilise et les donnes manipules. Le niveau de granularit descend donc ainsi lobjet.
Lapproche programmatique
Cette approche tend tre de moins en moins utilise, au profit des approches prcdemment cites, qui
offrent lavantage dune intrusion moindre dans le code.
Par essence, lapproche programmatique sera beaucoup moins transparente car la logique mtier
exprime dans le code source sera mixe avec une logique de scurit.
Aussi, cette approche ne sera que succinctement prsente ici.
La norme Java EE propose un jeu de classes et mthodes relatives la scurit, accessibles dans le
code de lapplication. La plupart de ces mthodes ont dj t cites dans ce livre. Les voici rcapitules
pour la norme Java EE 6.
La classe HttpServletRequest propose les mthodes suivantes en rapport direct avec la gestion de la
scurit :
authenticate(response)
login(user, pass)
logout()
getRemoteUser()
isUserInRole(name)
Ces mthodes vont permettre deffectuer des contrles ou des actions dans une servlet afin de mettre en
uvre une politique de scurit.
Il existe dautres facilits fournies par la spcification Java EE 6, comme lAPI
ServletRegistration.Dynamic. Cette API permet dajouter des contraintes de scurit une servlet de
faon programmatique, comme lillustre lexemple ci-dessous :
@WebListener()
public class CustomServletContextListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
try {
ServletContext servletContext = sce.getServletContext();
Class servletClass = (Class)
Class.forName("fr.ippon.servlets.SimpleServlet");
SimpleServlet servlet = servletContext.createServlet(servletClass);
ServletRegistration.Dynamic servletRegistration = (ServletRegistration.Dynamic)
servletContext.addServlet("fr.ippon.servlets.SimpleServlet", servlet);
servletRegistration.addMapping("/simpleServlet");
HttpConstraintElement constraint = new HttpConstraintElement();
http://blog.ippon.fr 23 / 45
List methodConstraints =
new ArrayList();
// Cration de plusieurs contraintes
methodConstraints.add(
new HttpMethodConstraintElement("GET",
new HttpConstraintElement(TransportGuarantee.NONE,
new String[] { "guest" })));
methodConstraints.add(
new HttpMethodConstraintElement("POST",
new HttpConstraintElement(TransportGuarantee.CONFIDENTIAL,
new String[] { "auth_user" })));
ServletSecurityElement servletSecurityElement =
new ServletSecurityElement(constraint, methodConstraints);
servletRegistration.setServletSecurity(servletSecurityElement);
Cet exemple est une illustration assez claire de la complexit inutile que lapproche programmatique peut
apporter.
De la mme faon, il est possible dutiliser Spring Security de faon programmatique. Des classes
utilitaires comme SecurityContextHolder permettent de donner accs au contexte de scurit associ
lutilisateur courant et den exploiter les donnes pour exprimer des contraintes directement dans le code.
Lexpression
SecurityContextHolder.getContext().getAuthentication()
donne accs un objet Authentication, porteur des informations suivantes :
getAuthorities()
getCredentials()
getDetails()
getPrincipal()
isAuthenticated()
Il est ensuite ais de raliser des contrles sappuyant sur ces donnes.
Scurisation des EJB
Au cur de la norme Java EE, on trouve les EJB. Cette entit ncessite aussi un soin particulier en ce
qui concerne la scurit. Les principes globaux restent identiques la scurisation dune application web,
savoir que les approches par utilisation du descripteur de dploiement, par mta donnes ou de faon
programmatique sappliquent ici aussi.
Lapproche dclarative est celle prconise officiellement pour la scurisation des EJB, avec une
prfrence, l aussi officielle, pour les annotations plutt que le descripteur de dploiement.
http://blog.ippon.fr 24 / 45
Le descripteur de dploiement
Le descripteur de dploiement dun EJB est un fichier XML conventionnellement nomm ejb-jar.xml, et
situ dans le rpertoire META-INF du livrable.
SimpleServiceBean
fr.ippon.services.SimpleServiceBean
Role administrateur rserv aux tches sensibles de
configuration
admin
administrator
Le role administrator
administrator
Le role admin peut acceder toutes les methodes du service
admin
SimpleServiceBean
*
Ce fichier va permettre dexprimer plusieurs notions, communes pour partie avec la scurisation des
servlets. On retrouvera donc les tags , , catgoriss diffremment
mais aux significations identiques.
On trouvera aussi un jeu de tags ddis aux EJB, comme et ses nuds fils, permettant la
dfinition des autorisations sur chaque EJB, lchelle des mthodes.
Il est noter cependant que la dfinition du transport ou du type dauthentification ne se fait pas dans ce
descripteur de dploiement mais dans un fichier annexe, propre au serveur dapplications. Dans le cas du
serveur Glassfish par exemple, ce fichier est nomm sun-ejb-jar.xml.
La dfinition de ces informations se fera sous le tag .
http://blog.ippon.fr 25 / 45
Les annotations
Cette approche est, comme prcdemment cit, celle privilgier selon les recommandations officielles.
A linstar des tags utiliss dans le descripteur de dploiement, cette approche reprend aussi les
annotations prcdemment vues dans le cadre de la scurisation des modules web.
Les annotations @DeclareRoles et @RolesAllowed sont donc prsentes, auxquelles sajoutent les
annotations @PermitAll et @DenyAll, illustres dans lexemple ci-dessous.
// Dclaration de rles...
@DeclareRoles({"admin", "manager", "user"})
public class SimpleService {
// Seul le role admin est autoris excuter cette mthode
@RolesAllowed("admin")
public void eraseAll() {
// ...
}
// Tous les roles sont autoriss excuter cette mthode
@PermitAll
public IDontKnowWhat getIDontKnowWhatById(Long id) {
// ...
}
// Ne sera pas excutable dans le conteneur, quel que soit le rle de l'utilisateur
@DenyAll
public void excludeFromExecutionInContainer() {
// ...
}
}
On retrouve aussi la dlgation didentit via lannotation @RunAs (qui trouve son pendant dans le
descripteur de dploiement : sous le tag ).
En injectant dans lEJB tout objet tendant javax.ejb.EJBContext, il est possible daccder aux
informations relatives au Principal et au rle de ce dernier. Les mthodes pour cela sont :
getCallerPrincipal()
isCallerInRole(role)
La mthode programmatique
Cette approche, dconseille car fortement intrusive, peut sappuyer sur les mthodes mentionnes
prcdemment, savoir :
getCallerPrincipal()
isCallerInRole(role)
http://blog.ippon.fr 26 / 45
fournies par linterface javax.ejb.EJBContext. Chaque mthode des EJB peut donc tre protge en
implmentant des contraintes au plus prs du code avec ces mthodes.
Le gain est quasi inexistant et cette approche nest donc rserver qu un usage trs cibl et justifi.
Scurisation des beans Spring
A linstar des EJB, les beans Spring peuvent aussi tre scuriss, par le framework Spring Security bien
sr.
Lapproche prconise dans ce cas sera dclarative, au travers de lannotation @Secured dj voque
prcdemment, mais aussi des annotations @PreAuthorize et @PostAuthorize au besoin.
Bien sr, le recours lAOP pour exprimer les contraintes de scurit sur les services est possible si la
dclaration par annotation vient ne pas suffire. Voir aussi la section Pour aller plus loin avec Spring
Security
Scurisation des Web Services
Cas des services web SOAP
Un service web est par dfinition un service permettant des systmes, potentiellement htrognes,
dchanger des informations au travers dun rseau. La forme la plus rpandue des services web fait
usage du protocole SOAP. Les services web SOAP sont donc un sous ensemble et non lunique forme
quun service web peut prendre. La scurit de ce type de service a fait lobjet de plusieurs normes ou
techniques couvrant un spectre large de possibilits.
Voici les mthodes les plus classiques pouvant tre mises en uvre dans le cadre de la scurisation des
services Web SOAP.
Scuriser le moyen de transport
La scurisation du transport, par le biais du protocole TLS (Transport Layer Security), est un moyen
simple mais cependant trs efficace de protger un change dinformations avec un service Web. Ce
mode de scurisation reste transparent pour le service lui-mme et peut tre ajout tout moment,
limpact tant principalement ct client, lequel devra se conformer ce nouveau type de transport pour
continuer daccder au service.
Parmi les avantages de cette approche, on peut citer la simplicit de mise en uvre, les standards bien
tablis, la protection tant des messages que des pices jointes ventuelles.
Par contre, cette approche noffre pas un niveau de granularit fin : la scurit ne peut pas tre applique
de manire slective sur des parties du message mais uniquement sur le message en entier. De plus, la
protection offerte est de type point point, par opposition une protection de bout en bout. La scurit
nest assure quentre deux points SSL enabled, des quipements rseau par exemple : les donnes en
amont et aval de ces points sont donc non scurises. Cela peut poser des problmes lors de
transactions mettant en uvre plusieurs rebonds possibles entre services ou quipements au sein
desquels les donnes pouvant tre lues en clair. Il faut donc bien considrer SSL pour ce quil est : un
moyen de protection du transport des donnes entre deux points et non une solution globale.
Lextension WS-Security
http://blog.ippon.fr 27 / 45
Lextension WS-Security est une rponse technique globale la problmatique de scurisation des
services web. Elle permet de proposer un cadre technique, reposant sur des standards dj bien tablis
pour la plupart, indpendants du transport du message et du chemin par lequel ce message serait amen
passer.
WS-Security adresse plusieurs aspects :
Lauthentification
Le cryptage des messages (ou de parties de messages)
La signature des messages (ou de parties de messages)
Lextension repose sur lutilisation dun en-tte ajout lenveloppe du message. Cet en-tte sera porteur
des informations utiles la scurit.
Il est alors possible de vrifier lidentit de lappelant, de savoir si le message a t modifi depuis son
mission, de vrifier si le message provient bien de lentit lgitime attendue ou encore de sassurer que
des parties confidentielles ne peuvent tre interprtables que par le destinataire lgitime.
WS-Security propose diffrents moyens de fournir les donnes utiles lauthentification. Lextension
dfinit la notion de UsernameToken pour encapsuler un identifiant et un mot de passe. Elle supporte
aussi le passage dun token binaire (BinarySecurityToken) pour, par exemple, une authentification avec
un ticket Kerberos.
Le passage dinformation avec le token UsernameToken prend cette forme :
david
supertopsecret
[...]
Bien sr, il sagit l dune forme peu scurise : le mot de passe est exprim en clair.
Une approche plus rigoureuse consisterait encoder le mot de passe :
david
DFsKG/1ab/sQo+NjAc+lm6eIsGZ=
http://blog.ippon.fr 28 / 45
dTVS7rt4Unda2x7CCkrddi5rbHi=
2011-11-07T16:14:01Z
[...]
Le mot de passe propag dans le message est le fruit dun cryptage SHA1 de la chane de caractre
compose du vritable mot de passe, de la valeur du nud Nonce, ici encod en Base64, et de la date
de cration porte par le nud Created. Le nud Nonce contient une valeur alatoire, thoriquement
unique pour chaque appel, permettant le salage du message (Le salage est lintroduction dune donne
externe, potentiellement variable, dans le but daccrotre la difficult didentification du message dorigine).
La formule applique est : Password_Digest = Base64 ( SHA-1 ( Nonce + Created + Password ) )
Note : Bien que plus scuris, ceci ne protge pas totalement contre une attaque de type replay (o le
mme message, si intercept, serait rejou par un tiers malveillant). Afin de sen prmunir, une approche
complmentaire pourrait introduire dune part une plage de validit des informations (par exemple avec
lutilisation du type Timestamp, issu du namespace utility, dfinissant une fentre de validit des donnes
avec une date de cration et une date dexpiration), et dautre part, afin dviter toute interception et
modification du contenu (comme par exemple une modification de la fin de validit), la signature de ce
nud. Une autre approche encore, toujours pour contrer ce type dattaque, pourrait reposer sur le
contrle dunicit dutilisation des donnes par mise en cache : le n-uplet de valeurs (Username,
Password, Nonce, Created (, Timestamp si combin)) ne pouvant tre utilis quune seule fois seulement
sur une priode de temps dtermine.
Lutilisation du BinarySecurityToken est assez similaire. Elle prsente elle aussi par ailleurs un risque
dattaque de type replay quil faut prendre en compte avec une approche similaire celle voque pour le
UsernameToken.
Il est possible de passer tant un certificat X509 quun ticket Kerberos (Ticket Granting Ticket ou Service
Ticket).
Lextension WS-Security permet aussi la signature des messages. La signature assure que le contenu du
message, ou dune partie de celui-ci, na pas t altr pendant son transport. La signature peut se faire
avec une clef prive X509, une clef de session Kerberos ou le mot de passe du UsernameToken.
Le cryptage du message ou dune partie du message est une possibilit utile dans certains cas
dutilisation. En effet, dans le cadre de certains changes, il peut tre exig que des donnes ne puissent
tre lues si interceptes. WS-Security propose un cadre pour assurer le cryptage des donnes dun
message. Le cryptage joue donc un double rle : sassurer quil nest pas possible de comprendre le
contenu protg et garantir que ce dernier nest pas modifi.
Parmi les inconvnients de WS-Security, on peut citer le cot en terme de performance. La signature et le
cryptage des messages sont des oprations consommatrices en ressources et doivent tre prises en
considration dans le dimensionnement de lenvironnement ou dans la phase de choix des solutions. WS-
Security ajoute en outre de la complexit dans la ralisation des services web. La configuration, quelle
http://blog.ippon.fr 29 / 45
que soit limplmentation retenue, est assez complexe. De plus, les diffrentes implmentations noffrent
pas toutes un support 100% des spcifications.
Les implmentations Java de WS Security sont Sun/Oracle XWSS et Apache WSS4J, cette dernire
tant largement utilise dans de nombreux projets.
La mise en uvre est fonction de la pile utilise pour la gestion des services web SOAP. Ainsi avec
Apache CXF, implmentation open source utilise par exemple par le serveur dapplications JBoss, la
mise en uvre va reposer sur des intercepteurs sur les flux. Les informations de scurit
(authentification, signature et/ou cryptage) sont donc interceptes de faon transparente pour le
traitement opr par le service.
Pour complter larsenal propos par WS-Security, et dans certains cas apporter une rponse des
points de faiblesse reconnus, dautres normes viennent pauler le dispositif : WS-SecurityPolicy (permet
un service web SOAP dexposer ses contraintes de scurit dans le WSDL permettant dventuels
clients de savoir comment sy interfacer), WS-SecureConversation (apporte une rponse moins
consommatrice de ressources pour un service appel de nombreuses fois par un client en nutilisant un
jeu de clefs fortes que lors du premier change, puis un autre jeu de clefs pour les suivants), WS-Trust
(permettant lobtention de tokens de scurit auprs dun tiers).
La scurisation via Spring Security (et Spring WS)
Bien quoffrant un panel doptions beaucoup plus limit que WS-Security, Spring Security peut aussi
apporter une contribution la scurisation des services web.
Il est par exemple simple doffrir par configuration le support de lauthentification et des autorisations.
Le filtrage dURL, dans le cas des services web de type SOAP, avoue sa limite puisquil ne permet pas de
dterminer la mthode prcise du service utilise et potentiellement lui affecter une politique de scurit
particulire.
Il faudra donc utiliser une approche par annotation pour obtenir un meilleur niveau de finesse, si
ncessaire.
Spring propose au travers de son module ddi aux services web, Spring-WS, les outils pour scuriser
les services Web. Spring-WS dispose de deux intercepteurs, lun sappuyant sur Sun XWSS et le second
sur Apache WSS4J, offrant le support de lauthentification, le cryptage/dcryptage et la signature des
messages tels que dfinis par WS-Security. Il est ainsi possible, via ce module ddi aux services web
dobtenir une rponse pour leur scurisation dun niveau tout fait acceptable.
Cas des services RESTful ou assimilables
Les services Web de type REST dits service RESTful sont relativement mdiatiss depuis quelques
temps. Ils proposent un autre modle de services et se caractrisent des services Web de type SOAP sur
plusieurs points. Une des caractristiques est de ne pas recourir une enveloppe technique, telle que
lenveloppe SOAP mais de faire usage dun maximum de caractristiques du protocole de transport pour
satisfaire les besoins du service.
Ce livre blanc nouvre pas le dbat sur la dfinition prcise et stricte dun service REST ni sur la
classification de ceux qui en sont et ceux qui nen sont pas. Il sagit ici, pour tout type de services
reposant sur cette philosophie, ft-elle implmente entirement ou partiellement, den tudier la
scurisation. Cest donc pour cela que cette section se nomme Cas des services RESTful ou
assimilables.
http://blog.ippon.fr 30 / 45
Bien que philosophiquement les services RESTful puissent faire usage dautres protocoles que HTTP, ce
dernier retient les faveurs et reprsente une norme majorit des cas de mise en uvre. Nous
retiendrons donc HTTP comme protocole tudi pour la scurisation des services RESTful.
Ainsi, comme voqu, les services REST promeuvent lusage des fonctionnalits natives des protocoles
de transport pour saffranchir de surcouches ou enveloppes. La scurisation va donc reposer sur des
rgles dj voques.
Afin de protger laccs des ressources sensibles, il va convenir de sassurer de lidentit de lappelant.
Il nexiste pas comme pour les services SOAP de mthode officielle en matire de scurisation des
services RESTful. Cest pour cela que plusieurs approches sont constates, chacune pouvant servir un
ensemble de besoins prcis mais ayant aussi ses propres limites.
Lapproche la plus classique pour lauthentification, et du reste bien souvent suffisante, est une
authentification de type BASIC. Compte tenu de la faon dont le mot de passe transite avec cette
mthode, il convient de lutiliser conjointement avec du SSL. Tout ceci est extrmement simple mettre
en uvre, tant ct client que serveur.
Une autre possibilit, dj voque, consiste utiliser non plus BASIC mais DIGEST. Un des
inconvnients est dajouter un change rseau supplmentaire (un premier appel au serveur pour
retourner au client une rponse 401 et le nonce ncessaire pour le cryptage).
Il est cependant commun de constater dautres approches, fournies par exemple par des services comme
Amazon S3[6] ou Microsoft Azure Platform[7]. Leurs propositions, trs proches, reposent sur lutilisation du
champ Authorization du header de la requte HTTP et dune signature sous forme de HMAC (Hash-
based Message Authentication Code) calcule sur la base de plusieurs donnes issues du message ET
dune clef symtrique fournie par le service (dans le cas dAmazon, la fameuse Secret Access Key). Une
telle approche peut tre utilise pour scuriser un service RESTful. Avec Spring Security, le support
passera par lcriture dun filtre spcifique grant cette mthode. Lcriture dun tel filtre ne prsente pas
de difficult technique particulire.
Enfin, il est aussi souvent voqu lutilisation dOAuth pour la scurisation des services RESTful. OAuth
propose aussi en effet un mcanisme de gnration de signature, sur le mme principe quvoqu juste
avant (HMAC et utilisation du champ Authorization du header HTTP), mais se restreint un cas
dutilisation bien prcis, la dlgation : le propritaire dune ressource servie par un systme autorise un
systme tiers y accder directement. De plus, OAuth ne considre pas tous les contenus des messages
dans le calcul de la signature, exposant certains messages des risques de corruption des donnes.
Pour rsumer cette partie sur la scurisation des services web RESTful, il faut retenir globalement ceci :
dans la plupart des cas, une authentification de type BASIC + SSL suffira et la prise en charge cot
serveur sera trs simple raliser (via Spring Security ou en Java EE traditionnel) et si le besoin le
justifie, une approche plus complexe inspire par Amazon S3 ou Microsoft Azure est un modle
intressant suivre.
Aller plus loin dans la modularisation
Nous avons vu dans cette section sur la gestion des autorisations que le concept phare est de se reposer
sur des dfinitions de rles, permettant de sabstraire des utilisateurs. Les exemples que lon trouve dans
la majorit des guides parlent de rles administrateurs, managers, utilisateurs,
Cette approche est appele (en anglais) Role-Based Access Control ou RBAC.
http://blog.ippon.fr 31 / 45
Volontairement, ce livre blanc a manipul ces notions de rles fonctionnels jusqu ce point dans un souci
de simplicit.
Cependant cette approche peut encore tre amliore. Nous allons voir pourquoi et comment.
Lutilisateur, le rle et la permission
Reprenons la justification initiale des rles. Ceux-ci ont pour but de dfinir des profils types dutilisateurs,
chacun disposant de droits particuliers, vitant lapplication la connaissance fine des utilisateurs (seuls
les rles de ses derniers lui importent). Un des avantages directs de ce systme est dviter davoir
dployer nouveau lapplication en cas de modifications des utilisateurs : une dclaration dun nouvel
utilisateur et laffectation dun ou plusieurs rles suffisent lui autoriser laccs lapplication.
Maintenant quen est-il si un profil vient changer de responsabilits ou si un nouveau rle doit tre
introduit dans lapplication ? Le systme ne permet pas de ragir de faon souple ce cas de figure. En
effet, les mthodes autorises pour un rle sont explicitement annotes (si on considre lapproche
dclarative par annotation utilise) de ce rle. Toute modification de ce type doit donc passer par une
modification du code, et par une phase de tests pour valider la bonne implmentation dune part et
sassurer quaucune rgression na t introduite dautre part.
Une approche oriente sur les rles est donc contraignante. Il convient de se tourner vers une approche
oriente sur les permissions.
La permission va reprsenter une contrainte plus atomique, qui sera qualifie par une action et une
ressource concerne par laction dans la plupart des cas. Un exemple simple serait :
VOIR_PROFIL, MODIFIER_PROFIL, SUPPRIMER_PROFIL,
Le rle dfinit quant lui un ensemble de permissions auquel il peut prtendre. Il est ainsi possible de
recomposer les autorisations de faon plus souple.
Quels sont les avantages de cette approche ?
Une approche explicite base sur les permissions est plus facile comprendre : elle se dfinit de faon
simple par une action et une ressource cible. Limplmentation des rgles de scurit en est donc
simplifie. Par ailleurs, la maintenance en cas de modification de la gomtrie dun rle nengendre pas
de consquences lourdes (comme une modification de lapplication, des tests et une nouvelle livraison
par exemple). La ractivit sen trouve donc aussi amliore.
Enfin, la dfinition de la politique de scurit (i.e. : dfinition des rles) peut tre totalement externalise,
permettant ainsi des changements de configuration au runtime.
Comment la mettre en uvre ?
Dans le cadre de lutilisation dun framework de scurit comme Spring Security, cette mise en uvre est
simplifie par la possibilit offerte de personnaliser le fonctionnement par dfaut. Voici une approche
possible pour implmenter une scurit oriente permission.
Un modle de donnes ddi la persistance de ces notions doit tre cr. Il sagit de pouvoir exprimer
un lien entre des permissions et des rles dune part et des rles et des utilisateurs dautre part.
http://blog.ippon.fr 32 / 45
Le modle peut donc tre de ce type :
Spring Security permet de crer une implmentation personnalise du service responsable de la
rcupration des informations de lutilisateur. Aussi, en implmentant linterface UserDetailService, il suffit
de ncrire quune seule mthode qui doit retourner pour un principal (utilisateur rel ou logique) un objet
de type UserDetails (une autre interface l aussi), qui comporte, parmi ses attributs, la collection dobjets
de type GrantedAuthority correspondant aux permissions ici (aux rles dans le modle par dfaut de
Spring Security).
Limplmentation de lobjet UserDetails peut tre soit une des implmentations proposes par Spring
Security (comme User), soit une implmentation personnalise (par exemple tendant la classe User) qui
permettra de maintenir le lien entre lutilisateur, ses rles et les permissions associes. Il peut en effet
tre utile, des fins daudit par exemple, de disposer de ces informations.
Le framework de scurit Apache Shiro supporte nativement[10] cette approche oriente ressources. Les
permissions peuvent tre affines en sous catgories (appeles parts dans la documentation de Shiro)
permettant dobtenir un degr de granularit pouvant aller jusqu linstance dun objet.
En outre, Apache Shiro propose une syntaxe simple pour exprimer les permissions, base de wildcard.
Cette syntaxe rend leur criture comme leur lecture trs accessible, ce qui est un avantage certain en
termes de cot de maintenance. Voici un exemple de permission :
printer:query,print:lp7200
Cette permission se lit ainsi : pour un objet printer didentifiant lp7200, les actions query et print sont
permises.
http://blog.ippon.fr 33 / 45
Approche centralise de la gestion des autorisations : intrt, limites
Nous avons vu prcdemment quil y a un grand nombre davantages centraliser une brique
dauthentification dans un systme dinformation. Il parait lgitime de se poser la mme question
concernant la gestion des autorisations.
Au mme titre que les annuaires LDAP sont linfrastructure ddie la gestion des identits en
entreprise, ils sont aussi souvent le rceptacle pour la gestion centralise des autorisations. Plusieurs
approches ont t mises en avant par les diffrents diteurs dannuaire, de la modification du schma
pour ajouter aux individus des caractristiques propres la scurit (solution peu volutive et
relativement lourde) ou par la cration de groupes ou rles affectables aux individus.
Cependant, cette approche sappuyant sur un annuaire LDAP lie les applications la technologie de
persistance. Une couche de service, indpendante de la technologie utilise, permettrait de limiter
ladhrence ce systme et de proposer de la souplesse, comme la gestion de dpts multiples (pour
grer de faon isole les individus, les comptes techniques, ...).
Il peut tre intressant de citer comme solution proposant une approche service, Atlassian Crowd[13], qui
offre un service centralis (incluant lauthentification, le SSO et la gestion des droits), ainsi quOpenAM[14].
http://blog.ippon.fr 34 / 45
Scuriser les changes
O se situe le risque ?
Comme voqu en dbut de livre, et comme souvent illustr dans dautres domaines que linformatique,
linterception dune communication est un moyen efficace de voler de linformation.
Aussi il importe de faire en sorte que les communications porteuses dinformations sensibles ne puissent
tre ni interceptes ni clairement interprtables.
La principale zone de risque qui vient lesprit est celle entre le client de lapplication et lapplication elle-
mme. En gnral, ce canal fait lobjet dune attention particulire et le recours aux techniques classiques
(SSL) pour le scuriser est commun.
Lapplication a souvent aussi ses propres besoins de communication (avec une base de donnes, inter-
applicative), lesquels sont souvent moins bien pris en compte, pour diverses raisons. Une premire raison
peut tre par oubli pur et simple, une seconde raison peut aussi tre par choix, considrant que le risque
de voir ce canal exploit est beaucoup plus faible car requiert davoir pntr lenvironnement dexcution
de lapplication.
Linvestissement consenti pour la scurisation doit tre en rapport avec la criticit des donnes
protges. Cet aspect aussi doit suivre un pilotage par le retour sur investissement.
Cependant, certaines rponses simples peuvent dj apporter, pour un cot limit, une premire
protection efficace.
Quelques rponses techniques
Une des rponses techniques les plus efficaces pour protger un systme dinformation est le recours
un firewall. Cest une des raisons pour lesquelles il est important de bien connatre les diffrents flux qui
concernent une application. Cela permet de configurer le bon niveau de restriction sur les changes
rseau sans entraver le fonctionnement de lapplication.
Dautres solutions peuvent aussi tre mises en uvre pour complter ce premier dispositif, comme la
mise en place dun systme de dtection (ou prvention) dintrusion rseau, ou de dtection dintrusion
systme. Des solutions open source matures comme Snort[11] ou plus rcemment introduites, comme
Suricata[12] rpondent ces exigences en matire de dtection dintrusion. Dans une autre gamme, des
quipementiers comme Cisco proposent aussi des solutions de haute performance pour rponse ce
besoin.
http://blog.ippon.fr 35 / 45
Se parer contre les attaques
Scuriser sa plate-forme dexcution
La scurit ne vaut que si elle est complte. Il ne viendrait normalement lesprit de personne dinvestir
dans une porte blinde sil est une habitude de laisser les fentres ouvertes. La mme logique sapplique
aussi sur une application. Cette dernire peut tre trs bien scurise en tant que telle, si elle sexcute
sur un serveur offrant une ou plusieurs failles de scurit, cet effort est rendu caduc.
Bien sr, cette prsentation dpasse largement le domaine de responsabilit de lquipe de
dveloppement, puisquen gnral ces aspects sont du ressort des administrateurs systmes. Aussi,
seules les grandes lignes seront ici nonces afin de sensibiliser aux diffrents aspects prendre en
compte.
Nexposer que le ncessaire
Il sagit l dune rgle lmentaire et universelle : le meilleur moyen de se protger est de volontairement
restreindre le nombre de points de faiblesse potentiels au strict ncessaire. Le mme principe sapplique
aussi larchitecture de lapplication. Une bonne connaissance des flux requis pour le fonctionnement de
lapplication permet de poser les rgles associes sur les changes rseaux. Il est ainsi possible de
nexposer que les ports ncessaires et de naccorder lautorisation daccs quaux sources lgitimes. En
limitant ainsi les possibilits de pntration du systme, le risque ne porte plus que sur un ensemble
restreint de services.
Le systme dexploitation
La scurit de la plate-forme commence par celle du systme dexploitation sur lequel les diffrents
services sont installs. Lensemble des diteurs est ractif face aux publications de vulnrabilits et les
correctifs sont rapidement proposs. Encore faut-il les installer. Afin de se prmunir deffets indsirables
pouvant tre induits par ces correctifs, un environnement bac sable est une approche intressante,
principalement lorsquelle est accompagne dun systme de tests de lapplicatif.
Par ailleurs, une gestion stricte des comptes utilisateurs sur les instances et lattribution des droits
suffisants aux comptes techniques, permet de limiter limpact dune compromission dun service. Il faut
pour cela avoir une vision prcise des besoins du service en terme dutilisation des ressources locales
afin de prcisment dimensionner les privilges du ou des comptes techniques associs.
La JVM
Au-del du systme dexploitation, la JVM fait elle aussi lobjet de correctifs de scurit et, de la mme
faon, un test prliminaire dans un environnement isol permet de sassurer que le correctif na pas
deffet de bord sur lapplication. En tant que brique fondamentale sur laquelle reposent les applications
Java, il convient aussi davoir un suivi rigoureux des publications de correctifs.
Le serveur dapplications
Le serveur dapplications est une des briques sensibles de larchitecture applicative. Son exposition,
mme si indirecte dans certains cas (voir plus loin, Les services additionnels), en fait une des principales
http://blog.ippon.fr 36 / 45
cibles dattaques. En dehors de lapplication vidente des correctifs de scurit, dautres mesures
peuvent aussi tre prises, concernant sa configuration. Parmi les mesures appliquer, la scurisation des
outils dadministration du serveur dapplications est une opration importante et ncessaire. Ces outils
dadministration peuvent aussi bien tre des interfaces web que des services exposs (accs aux
MBeans JMX par exemple).
Voici par exemple quelques recommandations pour scuriser le conteneur dapplications Apache Tomcat [5] :
Supprimer tout ce qui nest pas ncessaire, en particulier lensemble des applications livres par dfaut avec Tomcat. Il en va de mme pour toute autre application en dehors de celles par dfaut de Tomcat qui naurait plus dutilit en production (une version antrieure, ).
Utiliser le Security Lifecycle Listener, fourni avec Tomcat 7. Ce composant vrifie quun certain nombre de rgles de scurit sont bien appliques sur lexcution courante de Tomcat, comme par exemple le fait que le service nest pas excut avec lutilisateur root, ou que les fichiers que Tomcat cre le sont de faon scurise (gestion correcte des droits).
Activer le composant AccessLogValve, par dfaut sur Tomcat 7 mais pas sur les versions prcdentes. Ce composant fournira des informations qui pourraient tre prcieuses pour remonter la source dune attaque.
Utiliser la RemoteAddrValve, plutt que la RemoteHostValve, pour restreindre laccs certaines applications (interfaces dadministration par exemple) sur la base dadresses IP.
Si vous utilisez Tomcat pour la gestion de lauthentification, pensez utiliser le composant LockOutRealm, qui permettra de faon transparente dajouter une fonctionnalit de ban pour les utilisateurs chouant trop de fois lauthentification. Cela permet en outre de prvenir dune attaque de type DoS par exemple.
Dsactivez le port darrt de Tomcat (en s