Ippon-Technologies-La-sécurité-des-applications-Java-EE

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


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 [email protected], 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


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.


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.


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.


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

[...]


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.


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


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.


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 :


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


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


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.


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.


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.


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


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


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.


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 {

//


}

@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)


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();


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.


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 .


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)


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


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=


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


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.


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.


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.


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.


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


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.


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


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

Ippon-Technologies-La-sécurité-des-applications-Java-EE

Documents

Transcript of Ippon-Technologies-La-sécurité-des-applications-Java-EE