Aujourd'hui de plus en plus d'applications web se basent sur les technologies Java. A ces fins, les éditeurs de logiciels proposent une panoplie d'outils très variés permettant de développer différents types d'applications Java.

Cet article se propose de présenter rapidement les technologies Java, en vue d’en clarifier les principaux termes (un glossaire technique accompagne également cette présentation) et de parcourir, dans un second temps, les principes de sécurisation liés aux différents types d’application Java rencontrés.

• La compilation : les sources sont tout d’abord compilés en un code intermédiaire (le "byte code"), en utilisant le JDK ("Java Development Kit")
• L’exécution : ce code intermédiaire est ensuite interprété dans une machine virtuelle Java (JVM) afin d’exécuter le programme. Pour cette phase, le JRE ("Java Runtime Environment") est le plus utilisé.

Ce découpage offre un des grands atouts de Java : la portabilité.

En effet, le code intermédiaire issu de la phase de compilation n’est généré qu’une seule fois, et est utilisable directement sur toutes les plates-formes supportant Java : il n’est pas nécessaire de compiler les sources sur chaque plate-forme visée.

• une API, qui fournit des composants prêts à l’emploi, sur laquelle un programme Java peut s’appuyer,
• une JVM, qui sert de socle à tout programme (API inclue) et permet son exécution sur le système.

Le tableau illustre ce principe de fonctionnement :

2/ Les environnements Java

Avant de développer un programme Java, il faut tout d’abord identifier la plate-forme et le type de solution à réaliser.

Trois déclinaisons sont disponibles : J2EE, J2SE et J2ME (depuis peu appelées respectivement Java EE, Java SE et Java ME).

• Le kit J2ME (Java 2 Micro Edition) est destiné au développement très ciblé des applications pour plate-forme embarquée (assistants personnels, téléphone mobile…). Il contient des outils de compilation, déploiement et configuration, ainsi que des API spécifiques à chaque type d’équipement.
• Le kit J2SE (Java 2 Standard Edition) est le kit nécessaire au développement d’applications spécifiques tournant sur des serveurs ou systèmes "isolés" (hors applications embarquées), ou bien des applications Web seulement basées sur des applets.
  Il offre un compilateur, un environnement d’exécution (JRE), et un certain nombre d’API. Ces API offrent un certain nombre de classes pré-compilées qui peuvent être utilisées pour développer plus rapidement des applications. Elles portent sur des sujets variés allant des interfaces graphiques (AWT, Swing) aux bases de données (JDBC) en passant par les communications RMI (Remote Method Invocation) , la sécurité (JAAS, …), le XML (JAXP)…
• Le kit J2EE (Java 2 Enterprise Environment), est utilisé pour des applications fortement distribuées (serveurs d’applications, serveurs Web).
  Il inclut un serveur d’application, un serveur Web, les API J2EE. Ce kit supporte les EJB (Enterprise Java Bean), les servlets et les JSP.
  D’autres API sont disponibles afin d’étendre le J2SE (Java3D, JCE…). Etant plus spécialisées, elles ne sont pas intégrées dans le noyau de J2SE, et doivent être ajoutées a posteriori.

Remarque : les applets sont des programmes contenus dans des pages Web. Ce sont des programmes qui ne sont pas des applications, car elles nécessitent d’être exécutées sur un navigateur qui servira d’interface (en fournissant une JVM) avec le poste de l’utilisateur.
Elles fonctionnent coté client (poste utilisateur), par opposition aux servlets qui tournent coté serveur.

Le framework de J2EE est complexe et permet de réaliser des applications réparties.

Les systèmes développés dans ce cadre suivent une architecture n-tiers, basée sur des clients (pour les utilisateurs) et un ou plusieurs serveurs d’application.

Le coté serveur est découpé en deux ou trois parties (en fonction de l’importance de l’application), afin de bien séparer les différentes couches d’une application :

• Une couche présentation, qui est en frontal du serveur avec l’extérieur.
  Elle contient les servlets qui composent l’interface d’entrée sollicitée par les requêtes des utilisateurs (équivalents aux CGI).
  Elles récupèrent les informations en provenance de l’extérieur, et les envoient aux objets de la couche métier.
  Pour finir, elles appellent des JSP qui retournent les informations issues du traitement aux clients (sous forme HTML pour les clients Web).
• Une couche "métier", qui contient des objets de traitements métier (Beans simples sur des serveurs petits ou moyens ou EJB sur de grosses applications)
• Une couche "données" ou EIS (Enterprise Information System), qui s’interface avec une base de données via l’API JDBC, ou avec d’anciennes applications existantes ("legacy applications", qui ne sont pas forcément des applications Java) ou des ERP (Enterprise Resource Planning) via l’API "J2EE Connector".

Remarque : les EJB offrent une possibilité sérieuse (au travers d'un framework bien pensé) de se passer d'un serveur Web... Il faut pour cela bâtir une architecture basée sur des clients lourds (par opposition à des clients légers de type navigateur). Ces clients sont appelés "lourds", car il sont plus complexes et nécessitent des phases de déploiement plus élaborées.

Afin de proposer un degré de sécurité satisfaisant pour une application Web Java, certains principes génériques doivent être appliqués.

Ce paragraphe se propose d’en faire une présentation générale. Pour plus de détails, il est recommandé de se reporter au chapitre "Sources" en fin de cet article.

Applet/Application

Java propose une architecture sécurisée. Une applet est exécutée dans un environnement étanche (bac à sable ou "sandbox"). De ce fait, l’applet a des fonctionnalités limitées par défaut par rapport au système sur lequel elle fonctionne (protection contre l’accès sur le disque, l’exploitation des ressources locales).

Il n’est pas non plus possible d’envoyer des informations à une autre destination que le serveur émetteur de la page contenant l’applet.

Ces limitations varient en fonction de la provenance de l’applet : une applet sur un disque local est considérée comme plus sûre qu’une applet en provenance d’Internet. En conséquence, les contraintes de sécurité sont plus souples pour la première.

Il est ensuite possible d’étendre les possibilités d’une applet (et d’une application) en signant cette applet (avec l’outil "jarsigner") et en lui octroyant des droits étendus via un fichier de "policy". Ce fichier permet de spécifier des droits assez finement (utilisateur, ressource, droit en lecture seule ou en écriture...).

a - Serverlet/JSP (couche présentation des serveurs web)

Un servlet reçoit les informations en provenance de l’utilisateur. Par conséquent, il convient lors de son développement de prendre en compte les problématiques communes à toute application Web dynamique.

En standard, les serlvets sont plus sûres que les CGI car Java permet nativement de s’affranchir des problématiques de filtrage de caractères, de gestion des limites de tableaux, de mémoire. En effet, Java stocke les paramètres de la requête HTTP dans des chaînes de caractères. Si un attaquant essaie de faire croire à la fin d’une requête, ça ne fonctionne pas (toute la requête est analysée et rangée dans une collection de paramètres). De plus, on ne passe pas par un interpréteur de commandes. Il n’y a pas d’interprétation directe possible du contenu d’un paramètre, contraitement à ce qui est possible dans une CGI.

Cependant, il convient toutefois de toujours vérifier et filtrer le contenu des requêtes car la valeur des arguments est utilisée par les objets de la couche métier. En particulier, les informations transmises en XML peuvent empêcher un traitement effectué au sein de la couche métier. Il s’agit à ce niveau de vérifier la "sémantique". Dans le cas du XML, des balises permettent d’organiser le contenu. En interceptant une requête, on peut insérer de nouvelles balises, en terminer certaines autres prématurément. A ce moment-là, il faut vérifier ("parsing") le paramètre par rapport à sa DTD (grammaire), afin de vérifier que les données sont cohérentes. XML refuse le mélange de balise, au contraire du HTML par exemple. Rien n’empêche cependant d’écrire un fichier XML mal construit (voire même sans DTD). Par contre, le passage via un parser permet de vérifier que le fichier répond bien à la grammaire

Une autre problématique à surveiller est le "Cross Site Scripting" (XSS), qui est plus orienté sur les JSP (page HTML retournée à l’utilisateur).

L’authentification par certificat client (HTTPS) est à utiliser en priorité pour bien débuter une session (plutôt que l’authentification par formulaire). Elle peut ensuite être exploitée par le biais du serveur d’application ou par une programmation spécifique (via l’API).

b - Définition d'utilisateurs et de profils (couche présentation et métier)

J2EE offre la possibilité de définir et de gérer des utilisateurs purement applicatifs (par opposition aux utilisateurs déclarés au niveau du système d’exploitation).

J2EE offre aux EJB et composants Web la possibilité de définir des rôles, des groupes d’utilisateurs (avec l’outil "deploytool").

Les EJB permettent aussi une gestion de permissions avec une précision allant jusqu’à la méthode d’un EJB par configuration (outil "deploytool"). Il est aussi possible de gérer les permissions par programmation, toujours via l’API.

c - Sécurisation de la couche données (ou EIS)

Le dernier niveau de sécurisation est celui de l’accès au tiers "ressources" (EIS – "Enterprise Information System"). Cette appellation ("tiers ressources") désigne aussi bien les bases de données (via par exemple l’API JDBC), que les anciens systèmes ("legacy applications"), les ERP ("Enterprise Resource Planning").

J2SE et J2EE

b - Mesures diverses (J2SE et J2EE)

Java offre la possibilité de créer et de gérer des certificats, via l’outil "keytool". Cet outil est disponible aussi bien dans le SDK de J2SE que dans celui de J2EE. Il est alors possible de monter une solution s’appuyant sur les certificats (le problème clé étant alors d’avoir une autorité de certification digne de confiance).

 
Ensuite, il convient de se tenir informé sur l’état de sécurité des produits utilisés (système d’exploitation, serveur web et environnements Java). L’annonce de vulnérabilités implique souvent une mise à jour d’un de ces composants.

5/ Quelques produits

Voici un petit tour d'horizon de quelques produits du marché utilisés pour mettre en œuvre des applications web basées sur les technologies Java :

Pour les applications web, les logiciels suivants sont souvent utilisés :

• Solutions Open Source orientées web :
• Le serveur Tomcat seul ou couplé avec Apache.
• Un autre serveur moins connu existe aussi : Jetty.
• L’environnement de développement Eclipse peut leurs être associé.
• Websphere Application Server Express (IBM)
• Weblogic Express (BEA)

Pour les serveurs d’application plus complexes, répondant complètement à la spécification J2EE 1.3 (support des EJB…), on trouve entre autres les produits suivants :

• Solution Open Source :
• JBOSS
• JRUN (Macromedia)
• Oracle 9iAS Java Edition
• Websphere Application Server (IBM)
• Weblogic Server (BEA)

Ce glossaire ne reprend que les principaux termes utilisés dans cette note. Pour plus d’informations, il vaut mieux visiter la page de glossaire indiquée dans le paragraphe "sources".

Pour plus d'information :

Le site http://java.sun.com/ a servi de référence à cet article. Ce portail contient aussi bien de la documentation relative à des informations générales que des articles techniques.

Plus précisément, les pages suivantes présentent des explications générales utiles pour la compréhension du monde Java :

• http://java.sun.com/developer/onlineTraining/new2java/index.html : présentation générale pas à pas (point d’entrée utile pour un premier contact avec le monde Java)
• http://java.sun.com/developer/onlineTraining/new2java/programming/learn/unravelingjava.html : glossaire des sigles/acronymes du monde Java
• http://java.sun.com/developer/onlineTraining/new2java/javamap/intro.html : carte globale de l’organisation du monde Java.
• http://java.sun.com/developer/technicalArticles/Security/Signed/ :explique les étapes de constitution d’une applet signée.
• http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security.html : la sécurité dans J2EE
• http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security10.html#62814 : mise en place d’un certificat.