Exporter (0) Imprimer
Développer tout

Sécurité dans Visual J#

Visual Studio .NET 2003

Krishnan Thazhathekalam
Visual Studio Team
Microsoft Corporation

Résumé : Cet article décrit brièvement la sécurité dans Microsoft Visual J++ 6.0 et la machine virtuelle Microsoft pour Java (MSJVM) comme contexte. Il présente la sécurité sur le .NET Framework et le Common Language Runtime et fournit des consignes de mise à niveau d'applications Visual J++ 6.0 à Microsoft Visual J# .NET.

Cet article traite aussi des fonctions de sécurité du .NET Framework, comme la sécurité par rôle et la sécurité des applications Web ASP.NET, que les développeurs Visual J# peuvent utiliser quand il créent des applications qui ciblent le Common Language Runtime.

Sommaire

Sécurité dans Visual J++ 6.0
Sécurité .NET Framework
Sécurité dans les applications Visual J++ 6.0 mises à niveau à Visual J#
Sécurité dans les nouvelles applications écrites dans Visual J#
Sécurité par rôle
Sécurité des applications Web ASP.NET
Services cryptographiques dans le .NET Framework
Conclusion

Sécurité dans Visual J++ 6.0

Le langage Java propose de nombreuses fonctions de langage qui rendent difficiles l'écriture de code nuisible par un développeur d'applications, soit accidentellement, soit intentionnellement. Ces fonctions de langage incluent le contrôle des limites sur les tableaux, révoquant les pointeurs et l'arithmétique des pointeurs, et permettant les conversions de types uniquement entre types compatibles.

Outre la sémantique des langages, Visual J++ 6.0 et la machine virtuelle Microsoft pour Java (MSJVM) utilisent trois mécanismes principaux pour implémenter la sécurité et protéger les ressources précieuses de l'ordinateur des programmes malveillants :

  • Contrôleur de code mobile 
  • Chargeur de classes 
  • Gestionnaire de sécurité

Le contrôleur de code mobile s'assure que le code s'exécutant dans un fichier de classe douteux ne plante pas la MSJVM, ne la laisse pas dans un état indéfini et ne cause pas l'absence de réponse du système. Il inspecte le fichier de classes pour garantir que les codes mobiles de la classe sont valables ; le code ne déborde jamais de la pile de la machine virtuelle et n'est jamais insuffisant ; des variables locales sont utilisées avant l'initialisation ; et les modificateurs de contrôle d'accès de champ, méthode et classe sont respectés. Le vérificateur de code mobile est un gage de sécurité contre le code malveillant qui peut avoir été écrit par un développeur mal intentionné ou contre une sortie non valide produite par un compilateur défectueux.

Le chargeur de classes assure la sécurité en associant les classes qu'il charge à un espace de nom unique. L'espace de nom des classes chargé par un chargeur de classes particulier est isolé des espaces de noms de classes chargés à l'aide de chargeurs de classes. Comme les classes fiables et non fiables sont toujours chargées via des chargeurs de classes séparés, ce principe réduit le risque de remplacement d'une classe fiable par une classe non fiable, ce qui causerait par conséquent une attaque par spoofing. Ceci permet à la MSJVM de déterminer l'origine d'une classe donnée et de restreindre en conséquence les activités de cette classe.

Le gestionnaire de sécurité fournit un « bac à sable » de sécurité qui restreint l'accès éventuel d'un code non fiable aux ressources sensibles. Les applications s'exécutant sur la MSJVM n'ont pas de gestionnaire de sécurité installé par défaut et, par conséquent, elles peuvent exécuter toutes les opérations, y compris l'accès aux ressources sensibles, comme les fichiers du disque dur. Pour installer un gestionnaire de sécurité, un développeur doit créer une classe qui étende la classe java.lang.SecurityManager abstraite et la définisse comme gestionnaire de sécurité par la méthode java.lang.System.setSecurityManager. La classe abstraite SecurityManager contient de nombreuses méthodes dont le nom commence par le mot « check ». Les méthodes dans les bibliothèques JDK 1.1.4 appellent ces méthodes avant d'effectuer des opérations éventuellement délicates. Selon l'implémentation des méthodes de contrôle, le développeur peut implémenter une stratégie de sécurité pour une application qui entraîne soit l'échec des méthodes de contrôle et l'émission d'une exception de sécurité, soit un retour réussi sans problèmes. L'émission d'une exception empêche les méthodes des bibliothèques de classes JDK 1.1.4 d'accéder aux ressources sensibles.

Pour les applets qui s'exécutent dans Microsoft Internet Explorer, le navigateur installe automatiquement un gestionnaire de sécurité qui restreint les opérations effectuées par les applets. Les applets n'ont pas non plus le droit de définir leur propre gestionnaire de sécurité. Internet Explorer propose plusieurs zones de sécurité, chacune associée à divers niveaux d'autorisation, de sorte que les applets ou un autre code téléchargé à partir du réseau se voie attribué des autorisations variables en fonction du lieu de téléchargement. Ces zones incluent « Poste de travail », « Intranet local », « Internet » et « Sites sensibles ». Généralement, le code téléchargé à partir de la zone « Poste de travail » se voit accorder le maximum d'autorisations et le code issu des « Sites sensibles » le minimum. En outre, des applets peuvent être signés avec un certificat Authenticode émis par une entité fiable pour pouvoir bénéficier d'autorisations supplémentaires.

Visual J++ 6.0 prend également en charge les packages com.ms.security, com.ms.security.auditing et com.ms.security.permissions qui permettent aux développeurs d'associer des autorisations spécifiques au code. Au moment de l'exécution, les classes qui accèdent aux ressources sensibles peuvent demander que leurs appelants disposent d'autorisations spécifiques pour pouvoir accéder à ces ressources.

Le package java.security

Le package java.security fournit des classes et des interfaces qui prennent en charge les opérations cryptographiques comme la production de clés, signatures et numéros aléatoires forts du point de vue cryptographique. De nombreuses classes fournies dans ce package sont fonction du fournisseur. Les classes définissent une interface de programmation à laquelle les applications peuvent écrire. Les implémentations peuvent ensuite être écrites par un fournisseur tiers et insérées de manière transparente en fonction des besoins. Par conséquent, les développeurs peuvent tirer profit de plusieurs implémentations basées sur les fournisseurs sans avoir à ajouter ou réécrire du code. Une implémentation par défaut du fournisseur de sécurité est fournie dans la MSJVM.

Pour plus d'informations, consultez la documentation des produits Visual J++ 6.0 leave-msdn france Site en anglais dans la bibliothèque en ligne MSDN.

Sécurité .NET Framework

Le .NET Framework et le Common Language Runtime fournissent un environnement haute sécurité qui protège les ordinateurs et les applications des programmes malveillants et des attaques lancées par des utilisateurs non autorisés.

Le Common Language Runtime permet aux développeurs d'écrire des applications et des services gérés dans le langage de leur choix. Les programmes d'écriture-compilation correspondant à ces langages peuvent implémenter une sémantique de langage qui rend difficile l'écriture d'applications qui transgressent les règles de sécurité d'écriture et causent des dégâts à l'ordinateur sur lequel elles s'exécutent.

Avec le Common Language Runtime, tous les compilateurs de langage émettent un code géré sous la forme de Microsoft Intermediate Language (MSIL). Avant exécution, le MSIL doit être compilé juste à temps (JIT) en code natif spécifique au matériel sur lequel il s'exécute. Dans le cadre de la compilation de MSIL en code natif, MSIL doit subir un processus de vérification au moment de l'exécution.

La vérification est un bloc fondamental du système de sécurité du .NET Framework. La vérification implique deux composants : la vérification de la sécurité des types de MSIL et la validation des métadonnées des assemblys. MSIL fait l'objet de plusieurs vérifications : sécurité des types, occurrences de débordement ou dépassement négatif de piles, utilisation correcte des outils de traitement des exceptions et initialisation d'objets. La sécurité des types garantit l'isolation sûre des objets les uns par rapport aux autres et les met donc à l'abri d'une corruption fortuite ou malveillante. Si le code échoue à la vérification, une exception est insérée par le runtime lors de l'exécution du code. La validation des métadonnées fait intervenir l'examen de jetons de métadonnées pour vérifier leur indexage correct dans les tables auxquelles ils accèdent et s'assurer que les index aux tables de chaînes ne pointent pas vers des chaînes dont la taille dépasse les tampons qui doivent les contenir, ce qui élimine par conséquent les dépassements de tampons.

La vérification est la première partie de la sécurité lors de l'exécution. Le .NET Framework propose plusieurs mécanismes supplémentaires pour protéger les systèmes informatiques des codes ou des utilisateurs malveillants :

  • La sécurité d'accès du code, qui utilise des autorisations pour contrôler l'accès du code aux ressources et aux opérations protégées. Cette fonction protège les systèmes informatiques des codes mobiles malveillants tout en autorisant le code mobile à s'exécuter en toute sécurité. (La sécurité d'accès du code et les stratégies qui la gouvernent sont désignées par l'appellation « sécurité fondée sur des preuves ».)
  • La sécurité par rôle, qui fournit les informations nécessaires pour prendre des décisions sur ce qu'un utilisateur a le droit de faire. Ces décisions peuvent être fonction de l'identité de l'utilisateur, de son rôle, ou des deux.
  • La sécurité des applications Web ASP.NET, qui permet de contrôler l'accès à un site en comparant les informations d'authentification (ou leur représentation) aux autorisations du système de fichiers Microsoft Windows NT ou à un fichier XML qui répertorie les utilisateurs, les rôles et les verbes HTTP autorisés.

L'article An Overview of Security in the .NET Framework leave-msdn france Site en anglais présente un aperçu de la sécurité sur le .NET Framework et le Common Language Runtime en approfondissant certains sujets. Des informations plus spécifiques et détaillées figurent également à la section Sécurité du .NET Framework leave-msdn france Site en anglais.

Sécurité d'accès du code

Le .NET Framework propose une sécurité d'accès du code, un mécanisme de sécurité qui protège les systèmes informatiques du code mobile malveillant, ce qui permet aux utilisateurs d'exécuter du code issu d'origines inconnues en toute sécurité et de protéger le code fiable d'une violation de sécurité intentionnelle ou accidentelle. L'ensemble du code géré qui cible le Common Language Runtime, y compris les applications et les services écrits dans Visual J#, bénéficie de la sécurité d'accès du code, sans avoir à effectuer le moindre appel à une méthode de sécurité d'accès au code.

La sécurité d'accès du code applique la sécurité en limitant les opérations exécutables par un code non fiable, telles que l'accès à des ressources protégées, d'après les preuves présentées par le code lors de son chargement par le runtime. Les preuves incluent des entités comme le site Web ou l'URL à partir duquel le code a été téléchargé ou le nom fort ou certificat Authenticode de l'éditeur de code. Avec la sécurité d'accès du code, une application peut accéder à des ressources protégées, comme des fichiers sur l'ordinateur, uniquement si elle dispose d'autorisations suffisantes accordées par le runtime en fonction des preuves qui lui sont présentées. La stratégie de sécurité du .NET Framework examine les preuves présentées par l'application puis, d'après la stratégie de sécurité sur l'ordinateur, accorde des autorisations propres au code. Les applications peuvent uniquement exécuter les opérations pour lesquelles elles disposent d'autorisations. Par conséquent, dans le cadre de la stratégie de sécurité par défaut, les bibliothèques entièrement fiables qui sont chargées à partir du disque dur de l'ordinateur auraient toutes les autorisations (et pourraient donc accéder à toutes les ressources), alors que le code non fiable téléchargé sur Internet ne disposerait que d'un ensemble limité d'autorisations.

Au moment de l'exécution, quand une application essaie d'invoquer une méthode NET Framework qui accède à une ressource sensible, le runtime remonte la pile pour vérifier si tous les appelants de la pile ont l'autorisation appropriée pour accéder à la ressource. Si tous les appelants disposent des autorisations requises, la remontée de pile réussit et l'opération est autorisée, faute de quoi une exception sécurité est émise.

Pour plus d'informations, reportez-vous à Code Access Security leave-msdn france Site en anglais.

Sécurité dans les applications Visual J++ 6.0 mises à niveau à Visual J#

Comme toutes les applications et services qui ciblent le Common Language Runtime, les applications écrites en Visual J# suivent la sémantique de sécurité du .NET Framework et du Common Language Runtime. Ceci est valable aussi bien pour les nouvelles applications écrites en Visual J# qui ciblent les bibliothèques de classes de .NET Framework que pour les applications Visual J++ 6.0 existantes qui ont été mises à niveau à Visual J#. Cette section décrit comment les divers mécanismes de sécurité dans .NET Framework se mappent sur ceux de Visual J++ 6.0 et fournit des consignes aux développeurs d'applications sur la mise à niveau d'applications Visual J++ 6.0 existantes à Visual J#.

Comme les applications et les services créés dans Visual J# sont écrits dans le langage Java, Visual J# propose les mêmes avantages de langage que Visual J++ 6.0. Cela veut dire que, comme Visual J++ 6.0, Visual J# applique le contrôle des limites sur les tableaux, interdit les pointeurs et l'arithmétique de pointeurs et autorise les conversions de types, mais uniquement entre les types compatibles.

Le compilateur Visual J# compile le code source du langage Java en MSIL. Comme indiqué à la section Sécurité du .NET Framework, quand le runtime exécute une compilation JIT sur MSIL en code natif, la sécurité des types et l'adéquation des métadonnées sont également vérifiées. Ainsi, tout code malveillant qui transgresse les règles de sécurité de type ne peut pas s'exécuter.

Accès aux bibliothèques de classes JDK 1.1.4, WFC et com.ms.*

Par défaut, pour les assemblys à nom fort, le .NET Framework applique une sécurité déclarative à toutes les méthodes, propriétés et événements de l'assembly accessibles au public pour limiter leur utilisation à des appelants 100 % fiables. Pour des détails, reportez-vous à Version 1 Security Changes for the Microsoft .NET Framework leave-msdn france Site en anglais.

Comme les bibliothèques de classes Visual J# ont des noms forts et sont installées dans le cache global des assemblys, seules les applications fiables à 100 % peuvent accéder aux classes dans les packages JDK 1.1.4, Windows Foundation Classes (WFC) et com.ms.*. Dans le cadre de la stratégie de sécurité par défaut du .NET Framework, cela veut dire que seules les applications chargées à partir du disque dur ou exécutées dans un groupe de codes auquel la stratégie a accordé l'ensemble des autorisations FullTrust peuvent accéder à ces classes. Toute tentative d'accès à ces classes à partir d'une application partiellement fiable, comme une application téléchargée sur Internet ou exécutée à partir d'un site distant, se soldera par une exception de sécurité.

Les développeurs peuvent toujours créer des bibliothèques 100 % fiables en plus des classes dans Visual J# et les exposer à un code partiellement fiable. Les développeurs de ces bibliothèques ont la responsabilité de s'assurer que les bibliothèques sont 100 % sécurisées et qu'elles ne rendent pas la machine vulnérable à des exploitations. Une bibliothèque sécurisée est une bibliothèque de classes qui utilise des demandes de sécurité pour s'assurer que les appelants de la bibliothèque disposent de l'autorisation d'accès aux ressources exposées par la bibliothèque. Par exemple, une bibliothèque de classes sécurisée peut disposer d'une méthode de création de fichiers qui exigerait que ses appelants disposent d'autorisations de création de fichiers. Pour plus d'informations, reportez-vous à Writing Secure Class Libraries leave-msdn france Site en anglais.

De nombreuses classes de Visual J# proposent une fonctionnalité équivalente à la plupart des classes JDK 1.1.4. Ces classes sont conçues pour demander les autorisations .NET Framework appropriées avant d'exécuter des opérations sensibles. Par conséquent, outre l'exigence que les appelants immédiats des bibliothèques Visual J# soient 100  % fiables, un contrôle de runtime a également lieu pour des autorisations spécifiques avant que l'accès à une ressource ne soit autorisé. Comme indiqué à la section Sécurité d'accès du code, le temps d'exécution remonte la pile pour vérifier si tous les appelants de la pile disposent des autorisations appropriées pour accéder à la ressource. Toutefois, les bibliothèques d'un tiers empilées par-dessus les bibliothèques Visual J# risquent d'annuler le résultat des contrôles de sécurité en appelant Assert, Deny ou PermitOnly lors de ces contrôles. Comme mentionné précédemment, dans ce cas, il incombe au développeur de bibliothèque de s'assurer que la bibliothèque ne rend pas la machine vulnérable à des exploitations. Pour plus d'informations, reportez-vous à Annulation des contrôles de sécurité leave-msdn france Site en anglais.

À la différence des classes JDK 1.1.4, les classes des packages WFC et com.ms.* n'exécutent aucune demande d'autorisation .NET Framework. La seule restriction de sécurité est que les appelants immédiats de ces classes soient fiables à 100 %.

Chargeurs de classes et gestionnaires de sécurité dans Visual J#

À la différence de Visual J++ 6.0, les chargeurs de classes et gestionnaires de sécurité ne sont pas pris en charge dans Visual J#. Quand vous mettez à niveau des applications Visual J++ 6.0 qui utilisent des chargeurs de classes personnalisés ou des gestionnaires de sécurité, ils doivent être modifiés pour utiliser la sémantique de sécurité d'accès au code fournie par le .NET Framework et Common Language Runtime. Pour plus d'informations sur la sécurité d'accès au code .NET Framework, reportez-vous à la section Sécurité d'accès du code leave-msdn france Site en anglais.

Dans Visual J#, les méthodes suivantes dans la classe java.lang.SecurityManager ne sont pas prises en charge :

  • SecurityManager.classDepth
  • SecurityManager.classLoaderDepth
  • SecurityManager.currentClassLoader
  • SecurityManager.currentLoadedClass
  • SecurityManager.getClassContext
  • SecurityManager.inClass
  • SecurityManager.inClassLoader

Ces méthodes insèrent l'exception com.ms.vjsharp.MethodNotSupportedException dans Visual J#. Visual J# ne prend pas non plus en charge les méthodes java.lang.System.setSecurityManager et java.lang.System.getSecurityManager.

De la même manière, les méthodes suivantes de la classe java.lang.ClassLoader ne sont pas prises en charge :

  • ClassLoader.defineClass
  • ClassLoader.resolveClass

Ces méthodes insèrent com.ms.vjsharp.MethodNotSupportedException dans Visual J#. La méthode java.lang.Class.getClassLoader renvoie toujours un nul sur Visual J#.

Quand vous mettez à niveau une application Visual J++ 6.0 qui implémente un gestionnaire de sécurité personnalisé, il doit être modifié pour utiliser les classes d'autorisations dans l'espace de nom System.Security.Permissions du .NET Framework. De nombreuses méthodes de contrôle dans la classe java.lang.SecurityManager ont des classes d'autorisations équivalentes dans le .NET Framework. L'exemple suivant montre un gestionnaire de sécurité simpliste qui illustre comment les applications utilisant des gestionnaires de sécurité peuvent être mises à niveau à Visual J#.

class MySecurityManager extends SecurityManager
{
 .
 .
 .
 public void checkDelete(String file)
 {
 if (file == "boot.ini")
 throw new SecurityException();
 return;
 }
 .
 .
}

Dans une bibliothèque de classes ou une application, un développeur utiliserait cette classe comme suit :

{
 SecurityManager sm;
 if ((sm = System.getSecurityManager()) != null)
 sm.checkDelete("boot.ini");
 
 // Si l'opération est interdite, une exception est insérée dans l'énoncé
 // précédent ; sinon, checkDelete est retournée et l'exécution
 // continue.
 .
 .
 // Modifiez ou supprimez le fichier.
 .
 .
}

La méthode précédente peut être modifiée comme suit :

{ 
FileIOPermission fd = new 
 FileIOPermission(FileIOPermissionAccess.Write, "boot.ini");
 fd.Demand();
 // Si l'opération est interdite, une exception est insérée dans l'énoncé
 // précédent ; sinon, la méthode Demand est retournée et l'exécution
 // continue.

 .
 .
 // Modifiez ou supprimer le fichier.
 .
 .
}

La méthode Demand oblige le runtime à vérifier si tous les appelants situés en haut de la pile d'appels ont l'autorisation d'accéder au fichier spécifié. Si un appelant de la pile ne dispose pas de cette autorisation, une SecurityException est insérée pour empêcher les appelants d'accéder à la ressource protégée. Pour plus d'informations sur les classes d'autorisation disponibles dans le .NET Framework, reportez-vous à System.Security.Permissions Namespace leave-msdn france Site en anglais.

Outre la modification de l'application pour qu'elle utilise les classes d'autorisations .NET Framework, il faudra peut-être modifier la stratégie de sécurité de .NET Framework sur l'ordinateur pour obtenir l'effet désiré. La réussite d'une demande spécifique d'autorisation durant l'exécution dépend du groupe de codes dans laquelle s'exécute l'application et des autorisations accordées par le runtime à ce groupe de codes. Pour plus d'informations sur l'administration de la stratégie de sécurité .NET Framework, reportez-vous à General Security Policy Administration leave-msdn france Site en anglais.

Les chargeurs de classes personnalisés étendent java.lang.ClassLoader et annulent la méthode loadClass pour leur propre implémentation. Les applications qui utilisent des chargeurs de classes personnalisés doivent être correctement modifiées pour ne pas utiliser les méthodes ClassLoader.defineClass et ClassLoader.resolveClass. Les applications doivent être modifiées pour utiliser les classes du .NET Framework lors du chargement des assemblys gérés. Les applications peuvent utiliser des méthodes telles que Assembly.Load ou Assembly.LoadFrom pour charger un assembly, puis retrouver un type spécifique parmi l'assembly chargé.

Dans Visual J++ 6.0, les classes chargées par un chargeur de classes sont associées à un espace de nom unique isolé des classes chargées par d'autres chargeurs de classes. Ainsi, une classe fiable chargée par un chargeur de classe spécifique ne peut pas être spoofée par une classe moins fiable et potentiellement malveillante chargée par un autre chargeur de classes (à partir d'Internet, par ex.). Dans le .NET Framework, l'assembly forme la limite du type. Chaque identité de type inclut le nom de l'assembly dans lequel elle réside. Un type appelé MyType chargé dans le cadre d'un ensemble n'est pas identique à un type appelé MyType chargé dans le cadre d'un autre assembly. Par conséquent, les classes issues d'un assembly fiable ne peuvent pas être spoofées avec des classes non fiables issues d'un ensemble téléchargé sur Internet.

Pour plus d'informations, reportez-vous à Assemblies leave-msdn france Site en anglais.

Mise à niveau d'applications qui utilisent un fournisseur de sécurité tiers

Visual J# prend en charge le package java.security. Visual J# propose par ailleurs une implémentation de fournisseur de sécurité par défaut qui peut être utilisée pour des opérations comme la production de clés ou de signatures. En outre, Visual J# permet aux utilisateurs d'utiliser des fournisseurs de sécurité tiers à la place du fournisseur de sécurité par défaut. Les utilisateurs peuvent préciser, par le biais d'un fichier de configuration de sécurité, les fournisseurs de sécurité installés sur le système et l'ordre dans lequel les fournisseurs doivent être recherchés pour l'implémentation d'un algorithme.

Les utilisateurs de Visual J# peuvent utiliser le fichier de configuration vjsharp.config dans le répertoire Microsoft Visual JSharp .NET\Framework\v<Visual J# version> pour spécifier ces paramètres. Il s'agit d'un fichier XML et tous les paramètres de sécurité sont précisés sous la balise <security> de ce fichier. Le format typique de ce fichier est le suivant :

<vjsharpconfiguration>
 <security>
 <packageinfo> 
 <description>Description of the package</description>
 <loadinfo class="packageName.className, assemblyName,
 Version=assemblyVersion, Culture=assemblyCulture,
 PublicKeyToken=assemblyPublicKeyToken">
 <load/> (or <noload/>)
 </loadinfo>
 </packageinfo>
 .
 .
 .
 </security>
</vjsharpconfiguration>

Les balises du fichier s'utilisent comme suit :

<packageinfo>
Spécifie tous les fournisseurs de sécurité installés.
<description>
Permet à l'utilisateur de fournir une description du package et ne joue aucun rôle dans le chargement d'un fournisseur.
<loadinfo>
Spécifie le nom de la classe de fournisseurs correspondant au package du fournisseur de sécurité et à l'assembly dans lequel il est chargé. Si vous précisez uniquement le nom de l'assembly, seul ApplicationBase est utilisé pour localiser l'ensemble. Pour les ensembles installés dans le cache global d'assemblys, les autres paramètres comme la version, la culture et le jeton de clé publique de l'assembly doivent être également spécifiés. Si un assembly n'est pas installé dans le cache global d'assemblys, vous pouvez également préciser le chemin complet qui mène à l'assembly.
<load> ou <noload>
Spécifiez si l'ensemble doit être chargé ou ignoré pour la recherche en cours. Si vous spécifiez <noload>, il sera ignoré.

vjsharp.config n'est pas créé par défaut durant l'installation de Visual J# .NET. Quand il n'existe aucun fichier de configuration, le fournisseur de sécurité par défaut qui est inclus aux bibliothèques Visual J# est utilisé. Pour utiliser un autre fournisseur, vous devez créer le fichier vjsharp.config dans le répertoire Microsoft Visual JSharp .NET\Framework\v<Visual J# version>. Le format du fichier doit correspondre aux spécifications précédentes. Les fournisseurs sont chargés par ordre d'apparition sous la balise <security>. Les erreurs rencontrées dans le format d'une balise <packageinfo> sont passées sous silence. Les assemblys des fournisseurs répertoriés dans ce fichier doivent être installés à un emplacement permettant à l'heuristique de recherche de l'assembly du Common Language Runtime .NET Framework, qui situe et charge les assemblys, de les localiser. Une fois le fichier vjsharp.config spécifié, le fournisseur par défaut n'est pas recherché, sauf indication contraire dans le fichier. Une balise <loadinfo> correspondant au fournisseur par défaut peut ressembler à ce qui suit :

<loadinfo class="com.ms.vjsharp.security.provider.ms, vjslib, Version= 
1.0.3300.0, Culture=neutral, PublicKeyToken= b03f5f7f11d50a3a">
 <load/>
</loadinfo>

Sécurité dans les nouvelles applications écrites dans Visual J#

Les applications et les services écrits dans Visual J# sont sujets aux mêmes restrictions de runtime que toute autre application gérée s'exécutant sur le .NET Framework. Lors de l'invocation des méthodes sur les classes du .NET Framework, le runtime vérifie si tous les appelants figurant sur la pile, y compris toute application Visual J#, disposent des autorisations appropriées pour exécuter l'opération. Une application écrite dans Visual J# ne peut accéder à aucun code ou ressource pour lesquels la stratégie de sécurité du .NET Framework sur l'ordinateur n'accorde aucune autorisation.

Un développeur d'applications Visual J# peut également utiliser les classes dans les bibliothèques de classes du .NET Framework pour spécifier les autorisations requises à l'exécution d'une application, demander des autorisations spécifiques aux appelants et spécifier les autorisations qui doivent être refusées à tous les appelants de ses classes. Ces demandes sont ensuite évaluées à l'exécution par le Common Language Runtime pour accorder l'ensemble d'autorisations possibles pour l'application s'exécutant. Une application Visual J# peut également demander que ses appelants aient des autorisations particulières ou possèdent une signature numérique.

Outre cette sémantique, toutes les applications ou composants écrits dans Visual J# doivent être fiables à 100 % pour pouvoir s'exécuter. Tous les composants ou applications compilés par le compilateur Visual J# .NET contiennent des références aux bibliothèques Visual J#. Ceci est valable pour les nouvelles applications écrites dans Visual J#, où vous n'accédez qu'aux bibliothèques de classes .NET Framework, ainsi que pour les applications Visual J++ existantes mises à niveau à Visual J#. Comme les bibliothèques de classes Visual J# ont un nom fort et sont installées dans le cache global des assemblys, seules les applications 100 % fiables peuvent accéder aux classes dans ces assemblys. Une exception sécurité est insérée quand une application ou un service Visual J# sont exécutés à partir d'un groupe de codes qui n'a pas reçu d'autorisation FullTrust définie par la stratégie de sécurité.

Par conséquent, les éléments suivants doivent être considérés quand vous écrivez des applications utilisant Visual J# .NET :

Applications

Toutes les applications exécutées à partir de la machine locale sont exécutées dans le groupe de codes MyComputer et se voient octroyer l'autorisation FullTrust accordée dans le cadre de la stratégie de sécurité du .NET Framework. Par conséquent, les applications Visual J# qui s'exécutent à partir de la machine locale le font sans exceptions de sécurité. Toutefois, les applications exécutées à partir de sites distants comme un partage de réseau s'exécutent dans les groupes de codes Internet ou Intranet. Comme les applications exécutées dans ces groupes de codes ne disposent pas de l'ensemble des autorisations FullTrust défini par la stratégie de sécurité par défaut du .NET Framework, elles échouent avec une exception sécurité. Si une application Web est mappée sur un partage UNC, ce partage doit bénéficier d'une fiabilité totale accordée à l'aide des outils de gestion de la stratégie de sécurité du Common Language Runtime. Pour plus d'informations, reportez-vous à General Security Policy Administration leave-msdn france Site en anglais et à Code Groups leave-msdn france Site en anglais.

Contrôles gérés hébergés dans Internet Explorer

Tous les contrôles gérés qui sont hébergés dans Internet Explorer s'exécutent dans les groupes de codes Internet ou Intranet. Comme les composants exécutés dans ces groupes de codes ne reçoivent pas l'autorisation FullTrust définie dans le cadre de la stratégie de sécurité par défaut du .NET Framework, ces applications Visual J# échouent avec une exception sécurité. Ceci est particulièrement vrai des contrôles WFC HTML mis à niveau à Visual J#.

Quand une application Visual J# est téléchargée et exécutée en utilisant la fonction de téléchargement de code d'Internet Explorer, l'application s'exécute dans le groupe de codes Internet ou Intranet. Comme ces groupes de codes ne disposent pas de l'autorisation FullTrust définie dans le cadre de la stratégie de sécurité par défaut, l'application échoue avec une exception sécurité.

Pour exécuter des applications ou des composants Visual J# à partir de sites distants, un Intranet ou Internet, l'une au moins des conditions suivantes doit être remplie :

  • Le composant ou l'application doit avoir été signé avec une paire de clés et la stratégie de sécurité du .NET Framework sur l'ordinateur avoir été modifiée pour accorder l'ensemble des autorisations FullTrust aux composants ou aux applications reconnaissables à cette signature.
  • Le composant ou l'application doit avoir été signé avec un certificat Authenticode et la stratégie de sécurité du .NET Framework sur l'ordinateur avoir été modifiée pour accorder l'ensemble des autorisations FullTrust aux composants ou aux applications reconnaissables à ce certificat Authenticode.
  • La stratégie de sécurité du .NET Framework sur l'ordinateur doit avoir été modifiée pour accorder l'ensemble des autorisations FullTrust aux contrôles téléchargés sur le site Web (URL) d'hébergement du composant ou de l'application.

Modification de la stratégie de sécurité du groupe de codes MyComputer

Quand la stratégie de sécurité du groupe de codes MyComputer est modifiée du niveau par défaut FullTrust à un ensemble d'autorisations plus restreintes, les applications Visual J# démarrées sur la machine locale ne peuvent pas s'exécuter.

Sécurité par rôle

Cette section fournit une présentation succincte de la sécurité en fonction des rôles et des classes du .NET Framework que les applications peuvent utiliser pour implémenter la sécurité par rôle. Elle prend un programme en exemple pour montrer comment un développeur Visual J# peut implémenter la sécurité par rôle dans une application.

Les applications d'entreprises donnent souvent accès à des données ou des ressources en fonction de certaines informations d'identification fournies par l'utilisateur. En général, ces applications vérifient le rôle d'un utilisateur et donnent accès aux ressources d'après ce rôle. Le Common Language Runtime prend en charge l'autorisation par rôle d'après un compte ou une identité personnalisée Windows.

Les rôles sont souvent utilisés dans les applications financières ou d'entreprises pour la mise en application d'une stratégie. La sécurité en fonction des rôles proposée par .NET Framework prend en charge l'autorisation par information sur le principal, construit à partir d'une identité associée, mise à la disposition du thread en cours. L'identité (et le principal qu'elle permet de définir) peut soit être basée sur un compte Windows ou une identité personnalisée non liée à un compte d'ouverture de session Windows. Les applications peuvent utiliser le rôle défini pour déterminer si un principal est autorisé à exécuter une action demandée. Le .NET Framework propose une prise en charge de la sécurité par rôle qui est assez souple et extensible pour satisfaire les besoins d'un large éventail d'applications. Vous pouvez choisir de communiquer avec les infrastructures d'authentification existantes comme COM+ 1.0 Services ou créer votre propre système d'authentification personnalisé. La sécurité est particulièrement bien adaptée à une utilisation dans les applications Web ASP.NET, qui sont traitées essentiellement sur le serveur. Toutefois, la sécurité par rôle proposée par .NET Framework est utilisable sur le client ou sur le serveur. Pour plus d'informations, reportez-vous à Role-Based Security leave-msdn france Site en anglais.

Les espaces de noms System.Security.Principal et System.Security.Permissions dans le .NET Framework contiennent les classes utilisables par les applications gérées pour implémenter la sécurité par rôle. Toutes les classes dans ces espaces de noms sont entièrement accessibles aux applications et services écrits dans Visual J#. L'exemple suivant est celui d'un programme Visual J# qui utilise les classes du .NET Framework pour implémenter la sécurité par rôle :

import System.*;
import System.Threading.*;
import System.Security.Principal.*;

public class RoleBasedSecurity
{
 public static void main(String[] args)
 {
 // Obtenez l'identité en cours et mettez-la dans un objet d'identité.
 WindowsIdentity MyIdentity = WindowsIdentity.GetCurrent();

 // Placez l'identité dans un objet principal.
 WindowsPrincipal MyPrincipal = new 
 WindowsPrincipal(MyIdentity);

 // Valeurs de principal.
 String Name = MyPrincipal.get_Identity().get_Name();
 String Type = 
MyPrincipal.get_Identity().get_AuthenticationType();
 boolean Auth = 
MyPrincipal.get_Identity().get_IsAuthenticated();

 // Valeurs d'identité.
 String IdentName = MyIdentity.get_Name();
 String IdentType = MyIdentity.get_AuthenticationType();
 boolean IdentIsAuth = MyIdentity.get_IsAuthenticated();
 boolean ISAnon = MyIdentity.get_IsAnonymous();

 boolean IsG = MyIdentity.get_IsGuest();
 boolean IsSys = MyIdentity.get_IsSystem();
 String Token = MyIdentity.get_Token().ToString();

 // Imprimez les valeurs.
 Console.WriteLine("Valeurs de principal pour le thread en cours :");
 Console.WriteLine("\n\nNom du principal : " + Name);
 Console.WriteLine("Type de principal : " + Type);
 Console.WriteLine("Principal authentifié : " + Auth);

 Console.WriteLine("\n\nValeurs d'identité pour thread en cours :");
 Console.WriteLine("Nom d'identité : " + IdentName);
 Console.WriteLine("Type d'identité : " + IdentType);
 Console.WriteLine("Identité authentifiée : " + IdentIsAuth);
 Console.WriteLine("\n\nIdentité anonyme : " + ISAnon);
 Console.WriteLine("Identité invitée : " + IsG);
 Console.WriteLine("Identité système : " + IsSys);
 Console.WriteLine("Identité jeton : " + Token);
 }
}

Sécurité des applications Web ASP.NET

La plupart des sites Web doivent restreindre de manière sélective l'accès à certaines parties du site. ASP.NET, en conjonction avec Internet Information Services (IIS), peut authentifier les références d'utilisateur comme les noms et les mots de passe, par l'une quelconque des méthodes suivantes d'authentification :

  • Windows : Basic, Digest ou Integrated Windows Authentication (NTLM ou Kerberos)
  • Authentification Microsoft Passport
  • Formulaires
  • Certificats client

ASP.NET contrôle l'accès aux informations du site en comparant les références authentifiées (ou leur représentation) aux autorisations du système de fichiers NTFS ou à un fichier XML qui répertorie les utilisateurs autorisés, les rôles autorisés (groupes) ou les verbes HTTP autorisés. Pour plus d'informations, reportez-vous à ASP.NET Web Application Security leave-msdn france Site en anglais.

Les applications Web ASP.NET qui sont écrites dans Visual J# peuvent utiliser les classes dans les espaces de noms System.Web.Security et System.Security.Principal du .NET Framework pour implémenter la sécurité des applications Web.

Services cryptographiques dans le .NET Framework

Les réseaux publics comme Internet ne fournissent aucun moyen de communication sécurisé entre les entités. La communication sur les réseaux est susceptible d'être lue, voire modifiée, par un tiers non autorisé. La cryptographie protège l'affichage et la modification des données et fournit des voies de communication sûres sur des canaux qui seraient sinon non sécurisés. Le .NET Framework propose de nombreuses classes dans les espaces de noms System.Security.Cryptography, System.Security.Cryptography.X509Certificates et System.Security.Cryptography.Xml qui prennent en charge les opérations cryptographiques.

Les classes dans l'espace de nom de cryptographie .NET Framework gèrent de nombreux détails de cryptographie pour le développeur. Toutes les classes dans les espaces de noms cryptographiques de .NET Framework sont entièrement accessibles au développeur Visual J#. L'exemple suivant montre l'utilisation de classes cryptographiques dans un programme Visual J# et utilise la classe DESCryptoServiceProvider, une Key et un vecteur d'initialisation spécifiés pour crypter un fichier.

private static void EncryptData(String inFileName, String outFileName,
ubyte[] desKey, ubyte[] desIV) 
{ 
 //Créez les flux de fichiers pour traiter les fichiers d'entrée et de sortie.
 FileStream fin = new FileStream(inFileName, FileMode.Open, 
FileAccess.Read);
 FileStream fout = new FileStream(outFileName, FileMode.OpenOrCreate,
FileAccess.Write);
 fout.SetLength(0);

 //Créez des variables pour aider à la lecture et l'écriture.
 ubyte[] bin = new ubyte[100]; // Stockage intermédiaire pour le cryptage.
 long rdlen = 0; // Nombre total d'octets écrits.
 long totlen = fin.get_Length(); //Longueur totale du
 //fichier d'entrée.
 int len; //Nombre d'octets à écrire à la fois.
 
 DES des = new DESCryptoServiceProvider(); 
 CryptoStream encStream = new CryptoStream(fout, 
des.CreateEncryptor(desKey, desIV), CryptoStreamMode.Write);
 Console.WriteLine("Cryptage...");

 //Lisez le fichier d'entrée, puis cryptez et écrivez vers le fichier de sortie.
 while(rdlen < totlen)
 {
 len = fin.Read(bin, 0, 100);
 encStream.Write(bin, 0, len);
 rdlen = rdlen + len;
 Console.WriteLine(rdlen + " octets traités");
 }
 encStream.Close(); 
 fout.Close();
 fin.Close();
}

Conclusion

Visual J# permet aux développeurs de langage Java de mettre à niveau des applications existantes au .NET Framework de manière transparente tout en garantissant toujours que les applications mises à niveau sont sécurisées. Il permet aussi aux développeurs d'utiliser le plein potentiel de l'ensemble complet des services de sécurité et bibliothèques de classes fournis par le Common Language Runtime et le .NET Framework. Ainsi les développeurs pourront-ils écrire des applications en langage Java qui sont sécurisées et protégées des codes et des utilisateurs malveillants.



Dernière mise à jour le mardi 17 septembre 2002



Pour en savoir plus
Afficher:
© 2014 Microsoft