Java 7 et la sécurité des applets

academic_dukeDepuis Java 7, des éléments sont apportés pour améliorer la sécurité des applets exécutées depuis un navigateur. Jusqu’à récemment encore la signature des applets java était optionnelle.

Depuis la version Java 1.7.0.21 déjà, l’utilisateur doit autoriser via une boite de dialogue, les applets java à s’exécuter sur son poste depuis un navigateur. Et depuis la version 1.7.0.51, pour plus de sécurité, les applets java exécutées depuis un browser doivent être signées par une autorité de certification sécurisée.

Cependant, même une applet signée n’est pas digne de confiance. Nous allons voir dans cet article en quoi consiste la signature d’une applet et comment s’assurer de la sécurité de celle-ci.

En quoi consiste la signature d’une applet?

Il s’agit d’une signature numérique avec un certificat (code signing) délivrée par une autorité de certification sécurisée (comme par exemple Verisign, thawte etc.). Le certificat peut être auto généré (avec les commandes genkey) pour des besoins en interne mais si l’application est grand public, il est alors indispensable de passer par une autorité de certification. Le certificat numérique est ajouté à une application informatique pour valider que l’application provient du propriétaire du certificat. La signature de l’applet améliore la confiance de l’utilisateur dans l’identité du fournisseur de l’applet voulant s’exécuter sur son poste, et permet aussi d’engager la responsabilité du fournisseur pour la sécurité de l’applet qu’il fournit.

Une fois le « certificat code signing » obtenu, il faut maintenant signer l’applet avec jarsigner qui est l’outil fourni par le jdk.

En ligne de commande

jarsigner -keystore <ton certificat> -storepass <le pass du trousseau> -keypass <le pass de la clé> -signedjar <le nom du jar signé> <le fichier jar à signer> <l’alias>

Par un fichier de build

Extrait:

<!—Signature du jar avec une clé -->
<target name="jar" depends="genkey" description="Sign JAR file">
<signjar jar="Le jar à signer"
 alias="username" <!-- l alias utilisé dans le certificat -->
 storepass="le mot de passe" <!-- le mot de passe du keystore -->
 keystore="location du certificat ou de la clé"
 signedjar="le nom du jar signé"/>
</target>

Le manifest

Toujours pour plus de sécurité, il est indispensable d’utiliser lors de la génération du jar, un fichier manifest en renseignant un certain nombre d’attributs pour améliorer la sécurité des applets exécutées depuis un browser :

Gestion des permissions

Dans le manifest, l’attribut « Permissions » est utilisé pour vérifier que le niveau de sécurité demandé lors de l’exécution de l’applet correspond bien au niveau de sécurité spécifié lors de la fabrication du jar. Cela empêche le redéploiement d’une applet signée avec votre certificat et demandant à s’exécuter avec des droits différents.

Deux valeurs sont possibles :

  • sandbox : pour indiquer que l’applet s’exécute en « sandbox » et qu’il n’y a pas besoin de permissions additionnelles.
  • all-permissions : pour indiquer que l’exécution de l’applet nécessite l’accès aux ressources system du poste de travail de l’utilisateur. Dans le code de l’appel de l’applet, l’attribut « permissions » du tag <applet> doit avoir la même valeur que l’attribut « Permissions » spécifié dans le manifest. Si cet attribut est absent, la valeur par défaut est “all-permissions”. En fonction du niveau de sécurité system du poste du client, l’absence de cet attribut peut bloquer l’exécution de l’applet.

Gestion de la provenance de l’applet

Il s’agit d’un ensemble d’attributs pour restreindre l’exécution de l’applet. Elle ne sera exécutée que si elle est appelée à partir d’un domaine réseau donné et qu’elle est située à un endroit donné.

  • L’attribut «Codebase» est utilisé pour restreindre l’utilisation de votre applet à des domaines réseau spécifiques. Cela empêche que votre applet soit redéployée sur d’autres sites à des fins malveillantes. Si cet attribut ne spécifie pas un serveur sécurisé (https), votre applet pourrait être soumise à des risques d’attaque de type “Man In The Middle”.
  • L’attribut «Application-Library-Allowable-Codebase» Ici il faut spécifier l’emplacement où le jar est censé se trouver. Cet attribut est utilisé pour déterminer ce qui est spécifié dans  le champ « Emplacement » des boîtes d’alerte de sécurité quand l’emplacement de l’applet est différent de celui de la page ayant démarré son exécution. Si le jar ne se trouve pas à l’emplacement spécifié, l’applet est bloqué. On n’a donc pas besoin de renseigner cet attribut quand l’applet et la page appelant se trouvent au même endroit.
  • L’attribut «Caller-Allowable-Codebase» est lui utilisé pour spécifier les domaines à partir desquels du code javascript peut lancer votre applet sans déclencher une alerte de sécurité. Si l’appel vient d’un domaine inconnu, l’exécution de l’applet est bloquée. En fonction du niveau de sécurité du poste client, si cet attribut est absent, l’appel depuis du code JavaScript peut être bloqué.

Voici pour exemple un extrait de manifest :


<manifestEntries>
 <Application-Name>MonAppli</Application-Name>
 <Permissions>sandbox</Permissions>
 <Codebase>https://*.soat.fr https://idi.com</Codebase>
 <Application-Library-Allowable-Codebase>*.soat.fr *.idi.com </Application-Library-Allowable-Codebase>
 <Application-Allowable-Codebase>*.soat.fr</Application-Library-Allowable-Codebase>
</manifestEntries>

Notez que la durée de validité d’un certificat code-signing étant définie, il est impératif à son renouvellement de résilier l’applet. Notez aussi qu’il est toujours possible d’exécuter une applet non signée sur un poste utilisateur. Pour cela il suffit d’ajouter en liste blanche (via le panneau de configuration) le site hébergeant l’applet en question.

Nombre de vue : 780

AJOUTER UN COMMENTAIRE