Exporter (0) Imprimer
Développer tout
Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Utilisation de la sécurité d'accès au code avec ASP.NET

Dernière mise à jour le 31 août 2004
Sur cette page

Dans ce module Dans ce module
Objectifs Objectifs
S'applique à S'applique à
Présentation Présentation
Accès aux ressources Accès aux ressources
Confiance totale et confiance partielle Confiance totale et confiance partielle
Configuration de la sécurité d'accès au code dans ASP.NET Configuration de la sécurité d'accès au code dans ASP.NET
Fichiers de stratégie ASP.NET Fichiers de stratégie ASP.NET
Stratégie ASP.NET Stratégie ASP.NET
Développement d'applications Web de confiance partielle Développement d'applications Web de confiance partielle
Niveaux de confiance Niveaux de confiance
Approches liées aux applications Web de confiance partielle Approches liées aux applications Web de confiance partielle
Personnalisation de la stratégie Personnalisation de la stratégie
Code privilégié du sandbox Code privilégié du sandbox
Choix de l'approche à adopter Choix de l'approche à adopter
Confiance moyenne Confiance moyenne
Restrictions de la confiance moyenne Restrictions de la confiance moyenne
Résumé Résumé
Ressources supplémentaires Ressources supplémentaires

Dans ce module

La sécurité d'accès au code est un modèle de contraintes de ressources permettant aux administrateurs de déterminer si un morceau de code précis peut accéder à des ressources indiquées et effectuer des opérations privilégiées et, dans l'affirmative, comment il peut réaliser ces opérations. Ce module traite de la configuration de la stratégie de sécurité d'accès au code ASP.NET et vous explique comment surmonter la plupart des principaux obstacles que vous risquez de rencontrer lors du développement d'applications Web de niveau de confiance partielle.

Les éléments pratiques de la sécurité d'accès au code y sont expliqués en détail, et vous apprendrez à développer des applications Web de niveau de confiance moyenne qui bénéficient de la protection fournie par la sécurité d'accès au code, mais sont capables d'utiliser des composants nécessitant une confiance totale.

Ce module inclut également des informations sur la création de stratégie de confiance ASP.NET et contient les deux listes très utiles suivantes :

  • Les assemblys système possédant l'attribut APTCA (AllowPartiallyTrustedCallersAttribute).

  • Les autorisations de stratégie et les niveaux de confiance ASP.NET par défaut. Cette liste indique les restrictions de clés imposées par chaque niveau de confiance ASP.NET.

Objectifs

Ce module vous permettra d'effectuer les opérations suivantes :

  • étudier le fonctionnement des fichiers de stratégie ASP.NET et créer une stratégie personnalisée ;

  • développer des applications Web à niveau de confiance partielle ;

  • utiliser OLE DB, le journal des événements, les services Web et le Registre à partir d'applications Web à niveau de confiance partielle ;

  • placer du code privilégié dans le sandbox ;

  • savoir quand placer du code en sandbox et personnaliser, le moment venu, des stratégies de confiance ASP.NET existantes.

S'applique à

Ce module s'applique aux produits et technologies suivants :

  • Microsoft® Windows® 2000 Server et Microsoft Windows Server? 2003 ;

  • Microsoft .NET Framework 1.1 et ASP.NET 1.1.

Présentation

La sécurité traditionnelle basée sur l'ordinateur principal, comme celle fournie par le système d'exploitation, autorise les accès aux ressources suivant l'identité de l'utilisateur.

À l'aide de Microsoft .NET Framework 1.1, les administrateurs ont la possibilité de configurer une stratégie pour des applications Web ASP.NET et des services Web à assemblys multiples ou non. Ils peuvent également accorder des autorisations de sécurité d'accès au code de sécurité pour permettre à l'application d'accéder à des types de ressources précis et d'effectuer des opérations privilégiées précises.

Par exemple :

  • Un administrateur peut décider que le code téléchargé depuis Internet ne doit accéder à aucune ressource, alors que le code d'application Web développé par une société précise bénéficie d'un niveau d'approbation supérieur, afin d'accéder à des ressources telles que le système de fichiers, le journal des événements et des bases de données Microsoft SQL Server.

  • Les programmes lancés par l'administrateur local s'exécutent sans limite sur l'ordinateur local. Malheureusement, un utilisateur malintentionné usurpant l'identité de l'administrateur peut exécuter sans limite du code dans le contexte de sécurité de celui-ci.

Ces zones correspondent aux endroits où la sécurité d'accès au code est importante car elle peut fournir des restrictions et une sécurité supplémentaires basées sur le code lui-même, plutôt que sur l'utilisateur exécutant le code.

Remarque : les applications Web et les services Web construits à l'aide de .NET Framework 1.0 s'exécutent toujours avec des autorisations d'accès au code illimitées, ce qui n'est pas configurable.

Accès aux ressources

Tous les accès aux ressources d'applications ASP.NET et au code géré en général obéissent aux deux couches de sécurité suivantes :

  • Sécurité d'accès au code. Cette couche de sécurité vérifie que tout le code de la pile d'appels en cours, code d'accès aux ressources compris, est autorisé à accéder à la ressource. Un administrateur emploie une stratégie de sécurité d'accès au code pour octroyer des autorisations aux assemblys. Les autorisations déterminent précisément à quels types de ressources l'assembly peut accéder. Les types d'autorisation correspondant aux types de ressources accessibles sont nombreux : il s'agit du système de fichiers, du Registre, du journal des événements, des services d'annuaire, de Microsoft SQL Server?, des sources de données OLE DB et des ressources réseau.
    Le module 8, « La sécurité d'accès au code en pratique », dresse la liste complète des autorisations d'accès au code.

  • Sécurité du système d'exploitation/de la plate-forme. Cette couche de sécurité vérifie que le contexte de sécurité du thread demandeur peut accéder à la ressource. Si le thread emprunte une identité, le jeton d'emprunt d'identité du thread est employé. Dans le cas contraire, le jeton du processus est utilisé et les autorisations qu'il possède sont comparées à celles de la liste de contrôle d'accès (ACL) associée à la ressource pour déterminer si l'opération demandée peut ou non être effectuée et si la ressource est accessible ou non.

Les deux contrôles doivent réussir pour que l'accès à la ressource soit autorisé. Tous les types de ressources exposés par les classes .NET Framework sont protégés avec des autorisations d'accès au code. La figure 9.1 présente un éventail de types de ressources accessibles à des applications Web, ainsi que l'autorisation d'accès au code associée requise pour la réussite de la tentative d'accès.

Types de ressources accessibles à partir d'applications Web ASP.NET et types d'autorisations associés

Figure 9.1
Types de ressources accessibles à partir d'applications Web ASP.NET et types d'autorisations associés

Confiance totale et confiance partielle

Par défaut, les applications Web s'exécutent en confiance totale. Les applications de confiance totale bénéficient d'autorisations d'accès illimitées au code délivré par la stratégie de sécurité d'accès au code. Ces autorisations comprennent les autorisations système prédéfinies et les autorisations personnalisées. Ceci signifie que la sécurité d'accès au code n'empêche pas votre application d'accéder aux types de ressources sécurisées présentés dans la figure 9.1. Le niveau de sécurité du système d'exploitation détermine la réussite ou l'échec de la tentative d'accès à une ressource. Parmi les applications Web qui s'exécutent en confiance totale, on peut citer les applications ASP.NET créées à l'aide de .NET Framework 1.0. Par défaut, les applications .NET Framework 1.1 s'exécutent en confiance totale, mais il est possible de configurer le niveau de confiance à l'aide de l'élément <trust>, décrit plus loin dans ce module.

Une application dont le niveau de confiance est autre que « Full (total) » est désignée sous le nom d'application de confiance partielle. Les applications de confiance partielle possèdent des autorisations restreintes qui limitent leur capacité à accéder à des ressources sécurisées.

Important Les applications Web créées à l'aide de .NET Framework 1.0 s'exécutent toujours en confiance totale du fait que les types de System.Web exigent des appelants de confiance totale.

Configuration de la sécurité d'accès au code dans ASP.NET

Par défaut, les applications Web s'exécutent avec un niveau de confiance totale et des autorisations illimitées. Pour modifier les niveaux de confiance de sécurité d'accès au code ASP.NET, vous devez définir un commutateur dans Machine.config ou dans Web.config et attribuer un niveau de confiance partielle à l'application.

Configuration des niveaux de confiance

L'élément <trust> de Machine.config permet d'activer la sécurité d'accès pour une application Web. Ouvrez Machine.config, puis recherchez « <trust » afin d'afficher ce qui suit.

  <system.web>
     <!-- level="[Full|High|Medium|Low|Minimal]" -->
     <trust level="Full" originUrl=""/>
  </system.web>

Un niveau de confiance réglé sur « Full » a pour effet de désactiver la sécurité d'accès au code car les demandes d'autorisation ne s'effectuent pas de la même façon que les tentatives d'accès aux ressources. Il s'agit de la seule option pour les applications Web ASP.NET qui s'appuient sur .NET Framework 1.0. Chaque niveau de « Full » à « Minimal » réduit le nombre d'autorisations et la capacité d'une application à accéder à des ressources sécurisées et à effectuer des opérations privilégiées. Chaque niveau renforce l'isolement de l'application. Le tableau 9.1 dresse la liste des niveaux de confiance prédéfinis et indique les principales limites d'un niveau par rapport au précédent.

Tableau 9.1 : Limites imposées par les niveaux de confiance ASP.NET

Niveau de confiance ASP.NET

Limites principales

Full

Autorisations illimitées. Les applications peuvent accéder à toutes les ressources soumises à la sécurité du système d'exploitation. Toutes les opérations privilégiées sont prises en charge.

High

Appels de code non géré interdits
Appels de composants traités interdits
Écriture interdite dans le journal des événements
Accès aux files d'attente Microsoft Message Queuing interdit
Accès aux sources de données OLE DB interdit

Medium

Mêmes restrictions qu'au niveau précédent, plus accès limité aux fichiers du répertoire de l'application en cours et accès au Registre interdit.

Low

Mêmes restrictions qu'au niveau précédent, plus connexion à SQL Server interdite à partir de l'application et appel de CodeAccessPermission.Assert interdit à partir du code (pas d'autorisation de sécurité des assertions).

Minimal

Seule l'autorisation d'exécution est disponible.

Verrouillage du niveau de confiance

Un administrateur de serveur Web qui souhaite utiliser la sécurité d'accès au code pour assurer l'isolement des applications et restreindre les accès aux ressources de niveau système doit être en mesure de définir la stratégie de sécurité au niveau de l'ordinateur et d'obliger les applications à s'y soumettre.

Le niveau de confiance des applications Web doit être verrouillé par les fournisseurs de services d'application ou par toute personne responsable de l'exécution de plusieurs applications Web sur le même serveur. Pour verrouiller le niveau de confiance, placez l'élément <trust> de Machine.config dans une balise <location>, puis réglez l'attribut allowOverride sur false, comme indiqué dans l'exemple suivant.

<location allowOverride="false">
  <system.web>
    <!-- level="[Full|High|Medium|Low|Minimal]" -->
    <trust level="Medium" originUrl=""/>
 </system.web>
</location>

Vous pouvez également employer l'attribut path avec l'élément <location> pour appliquer une configuration à un site ou à une application Web précis qui ne doivent pas être remplacés. Pour plus d'informations sur l'élément <location>, consultez le module 19, « Sécurisation de votre application ASP.NET et de vos services Web ».

Fichiers de stratégie ASP.NET

Chaque niveau de confiance est associé à un fichier de stratégie XML individuel qui comporte la liste des autorisations octroyées à chaque niveau de confiance. Les fichiers de stratégies résident dans le répertoire suivant :

%windir%\Microsoft.NET\Framework\{version}\CONFIG

Les niveaux de confiance sont associés à des fichiers de stratégie à l'aide d'éléments <trustLevel> dans Machine.config, situés juste au-dessus de l'élément <trust>, comme le montre l'exemple suivant.

<location allowOverride="true">
  <system.web>
    <securityPolicy>
      <trustLevel name="Full" policyFile="internal"/>
      <trustLevel name="High" policyFile="web_hightrust.config"/>
      <trustLevel name="Medium" policyFile="web_mediumtrust.config"/>
      <trustLevel name="Low" policyFile="web_lowtrust.config"/>
      <trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>
    </securityPolicy>
    <!--  level="[Full|High|Medium|Low|Minimal]" -->
    <trust level="Full" originUrl=""/>
  </system.web>
</location>

Remarque : aucun fichier de stratégie n'existe pour le niveau de confiance totale. Il s'agit d'un cas particulier correspondant simplement à un jeu d'autorisations illimitées.

La stratégie ASP.NET est entièrement configurable. Outre les niveaux de stratégie par défaut, les administrateurs peuvent créer des fichiers d'autorisations personnalisés et les configurer à l'aide de l'élément <trust>, décrit plus loin dans ce module. Le fichier de stratégie associé au niveau personnalisé doit également être défini par un élément <trustLevel> dans Machine.config.

Stratégie ASP.NET

La stratégie de sécurité d'accès au code est organisée suivant une structure hiérarchique et administrée à plusieurs niveaux. Elle peut être créée aux niveaux entreprise, machine, utilisateur et domaine d'application. La stratégie de sécurité d'accès au code ASP.NET est un exemple de stratégie de niveau domaine d'application.

Les paramètres d'un fichier de configuration XML séparé définissent la stratégie de chaque niveau. La stratégie d'entreprise, de machine et d'utilisateur peut être configurée à l'aide de l'outil de configuration de Microsoft .NET Framework, mais les fichiers de stratégie ASP.NET doivent être modifiés manuellement à l'aide d'un éditeur XML ou d'un éditeur de texte.

Les différents fichiers de stratégie de niveau confiance ASP.NET indiquent quelles autorisations peuvent être accordées à des applications configurées à un niveau de confiance particulier. Les autorisations réelles qui sont octroyées à une application ASP.NET sont déterminées en croisant les autorisations de tous les niveaux de stratégie, y compris entreprise, machine, utilisateur et ASP.NET (domaine d'application).

Du fait que la stratégie est évaluée du niveau entreprise au niveau application ASP.NET, les autorisations se réduisent à chaque niveau. Il n'est pas possible d'ajouter une autorisation au niveau ASP.NET sans qu'un niveau supérieur l'ait accordée préalablement. Cette approche garantit que le dernier mot revient toujours à l'administrateur et que le code néfaste s'exécutant dans un domaine d'application ne peut ni demander ni recevoir plus d'autorisations que l'administrateur n'en configure.

Pour plus d'informations sur l'évaluation d'une stratégie, consultez le module 8, « La sécurité d'accès au code en pratique ».

Étude d'un fichier de stratégie ASP.NET

Pour savoir quelles autorisations sont définies pour un niveau de confiance précis, ouvrez le fichier de stratégie adéquat dans le Bloc-notes ou, de préférence, dans un éditeur XML et recherchez le jeu d'autorisations « ASP.NET ». Ce jeu d'autorisations répertorie les autorisations configurées pour l'application au niveau de confiance en cours.

Remarque : le fichier de stratégie comporte également les jeux d'autorisations « FullTrust » et « Nothing ». Ceux-ci ne contiennent pas d'éléments d'autorisation car « FullTrust » signifie que toutes les autorisations sont accordées et « Nothing » qu'aucune autorisation n'est accordée.

Voici les principaux éléments d'un fichier de stratégie ASP.NET :

<configuration>
    <mscorlib>
        <security>
            <policy>
                <PolicyLevel version="1">
                    <SecurityClasses>
                      ... liste des classes de sécurité, types d'autorisation 
                        et types de groupes de code ...
                    </SecurityClasses>
                    <NamedPermissionSets>
                      <PermissionSet Name="FullTrust" ... />
                      <PermissionSet Name="Nothing" .../>
                      <PermissionSet Name="ASP.NET" ...
                        ... Voici la section pertinente ...
                        ... Liste des autorisations ...
                            <IPermission 
                                    class="AspNetHostingPermission"
                                    version="1"
                                    Level="High" />
                            <IPermission
                                    class="DnsPermission"
                                    version="1"
                                    Unrestricted="true" />
                          ... Suite de la liste des autorisations ...
                      </PermissionSet>
                </PolicyLevel version="1">
            </policy>
        </security>
    </mscorlib>
</configuration>

Vous pouvez constater que chaque autorisation est définie par un élément <IPermission>, qui indique non seulement le nom et la version du type d'autorisation mais également l'état de l'autorisation (illimité ou non).

État des autorisations et autorisations illimitées

La plupart des autorisations comprennent un état permettant d'ajuster les droits d'accès définis. L'état de l'autorisation détermine précisément les actions réalisables par votre application. Par exemple, une autorisation FileIOPermission peut indiquer un répertoire et un type d'accès (lecture, écriture, etc.). La demande d'autorisation requiert que le code appelant reçoive une autorisation de lecture pour accéder au répertoire C:\RépertQuelconque :

(new FileIOPermission(FileIOPermissionAccess.Read, @"C:\SomeDir")).Demand();

Dans un état illimité, FileIOPermission permet tous les types d'accès à tous les emplacements du système de fichiers (bien entendu, la sécurité du système d'exploitation continue à s'appliquer). La demande d'autorisation suivante requiert que le code appelant reçoive l'autorisation illimitée, FileIOPermission :

(new FileIOPermission(PermissionState.Unrestricted)).Demand();

Jeu d'autorisations nommé ASP.NET

Le jeu d'autorisations nommé « ASP.NET » figurant dans chaque fichier de stratégie ASP.NET définit les autorisations accordées par la stratégie du domaine d'application aux applications associées.

La stratégie ASP.NET introduit également l'autorisation AspNetHostingPermission, possédant un attribut Level qui correspond à l'un des niveaux par défaut. Tous les types publics de System.Web et de System.Web.Mobile sont protégés avec des demandes du niveau Minimal de cette autorisation. Cette stratégie de réduction des risques est conçue pour que le code d'application Web ne soit pas utilisable dans d'autres environnements de confiance partielle sans configuration de stratégie spécifique définie par un administrateur.

Paramètres de substitution

En modifiant un fichier de stratégie ASP.NET, vous pourrez constater que certains éléments d'autorisation contiennent des paramètres de substitution ($AppDirUrl$, $CodeGen$ et $Gac$). Ces paramètres permettent de configurer des autorisations d'accès à des assemblys qui appartiennent à votre application Web mais qui sont chargés à partir d'emplacements différents. Chaque paramètre de substitution est remplacé par une valeur réelle lors de l'évaluation de la stratégie de sécurité qui a lieu au moment où l'assemblage de votre application Web est chargé pour la première fois. Les trois types d'assemblys disponibles pour une application sont les suivants :

  • assemblys privés qui sont compilés en même temps que l'application et déployés dans le répertoire bin de celle-ci ;

    Important Ce type d'assembly ne peut pas porter un nom fort. Les assembly à nom fort employés par des applications Web ASP.NET doivent être installées dans le cache de l'assembly global. Cette limite est nécessaire en raison du fonctionnement interne du processus de traitement du domaine multi-applications.

  • assemblys compilés en dynamique qui sont générés en réponse à une demande de page ;

  • assemblys partagés chargés à partir du cache de l'assembly global.

Chaque type d'assembly possède un paramètre de substitution décrit dans le tableau 9.2.

Tableau 9.2 : Paramètres de substitution de la stratégie de sécurité d'accès au code

Paramètre

Représente

$AppDirUrl$

Répertoire racine virtuel de l'application. Permet d'appliquer des autorisations au code situé dans le répertoire bin de l'application. Par exemple, si un répertoire virtuel est associé à C:\VotreAppWeb, $AppDirUrl$ correspondra à C:\VotreAppWeb.

$CodeGen$

Répertoire contenant des assemblys générés de manière dynamique (le résultat de compilations de pages .aspx). Il peut être configuré pour chaque application et pointer vers
%windir%\Microsoft.NET\Framework\{version}\Temporary ASP.NET Files.
$CodeGen$ permet d'appliquer des autorisations à des assemblys générés de manière dynamique.

$Gac$

Tout assembly installé dans le cache de l'assembly global (GAC) de l'ordinateur (%windir%\assembly). Ceci permet d'attribuer des autorisations à des assemblys à nom fort chargés depuis le GAC par l'application Web.

Développement d'applications Web de confiance partielle

Les applications Web de confiance partielle sont des applications qui ne bénéficient pas d'autorisations illimitées mais d'un jeu limité d'autorisations d'accès au code déterminé par la stratégie de sécurité d'accès au code. Par conséquent, les applications de confiance partielle sont limitées dans leur capacité à accéder à des ressources sécurisées et à effectuer d'autres opérations privilégiées. Certaines autorisations sont refusées à ces applications, ce qui signifie que les ressources nécessitant ces autorisations ne sont pas accessibles directement. D'autres autorisations sont attribuées sous certaines conditions, ce qui signifie que les ressources qui en ont besoin sont accessibles d'une façon limitée. Par exemple, une autorisation FileIOPermission restreinte peut indiquer que l'application ne peut accéder, dans le système de fichiers, qu'aux sous-répertoires de la racine du répertoire virtuel de l'application.

À quoi sert la confiance partielle ?

L'attribution d'un niveau de confiance partielle à une application Web ou à un service Web permet de restreindre la capacité de l'application à accéder à des ressources système essentielles ou à des ressources appartenant à d'autres applications Web. En n'accordant que les autorisations requises par l'application, vous pouvez créer des applications Web aux privilèges minimaux et, ainsi, limiter les risques que pourrait courir l'application Web en cas d'injection frauduleuse de code.

Problèmes potentiels

Si vous modifiez la configuration d'une application Web pour que celle-ci s'exécute à un niveau de confiance partielle ne limitant pas l'accès aux seules ressources requises, vous risquez de rencontrer les problèmes suivants :

  • Votre application est incapable d'appeler des assemblys à nom fort annotés avec l'attribut AllowPartiallyTrustedCallersAttribute (APTCA). Sans l'attribut APTCA, les assemblys à nom fort demandent à bénéficier d'une confiance totale, ce qui débouche sur un échec quand la requête atteint votre application Web de confiance partielle. La plupart des assemblys système ne prennent en charge que les appelants de confiance totale. La liste suivante indique quels assemblys .NET Framework prennent en charge les appelants de confiance partielle et peuvent être appelés par des applications de confiance partielle sans nécessiter d'assemblys de wrappers en sandbox.

    Remarque : la mise en sandbox est traitée en détail plus loin dans ce module.

    Les assemblys système suivants sont annotés avec l'attribut APTCA, ce qui signifie qu'ils peuvent être appelés par des applications Web ou des éléments de programme de confiance partielle :

    • System.Windows.Forms.dll

    • System.Drawing.dll

    • System.dll

    • Mscorlib.dll

    • IEExecRemote.dll

    • Accessibility.dll

    • Microsoft.VisualBasic.dll

    • System.XML.dll

    • System.Web.dll

    • System.Web.Services.dll

    • System.Data.dll

    Si votre application de confiance partielle échoue car elle appelle un assembly à nom fort qui n'est pas annoté avec l'attribut APTCA, une exception générique SecurityException est émise. Dans ce cas, l'exception ne comporte pas d'informations supplémentaires indiquant que l'échec de l'appel est dû à celui de la demande de confiance totale.

  • Les demandes d'autorisation peuvent commencer à échouer. Il est possible que le niveau de confiance configuré n'accorde pas les autorisations nécessaires pour que votre application accède à un type de ressource précis. Voici quelques scénarios courants posant ce problème :

    • Votre application utilise le journal des événements ou le Registre, ce qui génère une exception SecurityException. En effet, les applications Web de confiance partielle ne disposent pas des autorisations nécessaires pour accéder à ces ressources système.

    • Votre application recourt au fournisseur de données ADO.NET OLE DB pour accéder à une source de données. Le fournisseur de données OLE DB requiert des appelants de confiance totale.

    • Votre application appelle un service Web. Les applications Web de confiance partielle possèdent une autorisation WebPermission restreinte, qui influe sur leur capacité à appeler des services Web situés sur des sites distants.

Niveaux de confiance

Si vous envisagez de faire migrer une application existante vers un niveau de confiance partielle, il est judicieux de réduire les autorisations de façon incrémentielle afin d'afficher les ruptures sur les différentes parties de votre application. Par exemple, commencez par régler l'attribut level sur High, puis sur Medium, et ainsi de suite. Enfin, le niveau de confiance visé dépend du niveau de restriction que vous souhaitez associer à l'application. Pour choisir le niveau de confiance requis, notez ce qui suit :

  • Les applications configurées pour un niveau de confiance élevée (Full), moyenne (Medium), faible (Low) ou minimale (Minimal) seront incapables d'appeler du code non géré ou des composants de type « serviced », d'écrire dans le journal des événements, d'accéder à des files d'attente Message Queuing ou d'accéder à des sources de données OLE DB.

  • Les applications configurées pour une confiance élevée possèdent un accès illimité au système de fichiers.

  • Les applications configurées pour une confiance moyenne ont un accès limité au système de fichiers. Elles ne peuvent accéder qu'aux fichiers de leur propre hiérarchie de répertoires.

  • Les applications configurées pour la confiance basse ou la confiance minimale ne peuvent pas accéder aux bases de données SQL Server.

  • Les applications de confiance minimale sont privées de tout accès aux ressources.

Le tableau 9.3 identifie les autorisations accordées par chaque niveau de confiance ASP.NET. Le niveau de confiance totale est omis car il accorde toutes les autorisations et un accès illimité aux ressources.

Tableau 9.3 : Autorisations de la stratégie ASP.NET par défaut et niveaux de confiance correspondants

Autorisation et état

High

Medium

Low

Minimal

AspNetHosting
Level

High

Medium

Low

Minimal

DnsPermission
Unrestricted

 

mnp_tickmark.gif

 

mnp_tickmark.gif

 

 

EnvironmentPermission
Unrestricted
Read Write

 

mnp_tickmark.gif

TEMP; TMP;
USERNAME;
OS;
COMPUTER
NAME

 

 

EventLogPermission

 

 

 

 

FileIOPermission
Unrestricted
Read
Write
Append
PathDiscovery

 

mnp_tickmark.gif



$AppDir$
$AppDir$
$AppDir$
$AppDir$



$AppDir$


$AppDir$

 

IsolatedStorageFilePermission
Unrestricted
AssemblyIsolationByUser
Unrestricted UserQuota

 

mnp_tickmark.gif

 

mnp_tickmark.gif
mnp_tickmark.gif

mnp_tickmark.gif


1 Mo
(variable selon le site)

 

OleDbClientPermission
Unrestricted

 

 

 

 

PrintingPermission
Unrestricted
DefaultPrinting

 

mnp_tickmark.gif

 

mnp_tickmark.gif

 

 

ReflectionPermission
Unrestricted
ReflectionEmit

 

mnp_tickmark.gif

 

 

 

RegistryPermission
Unrestricted

 

mnp_tickmark.gif

 

 

 

SecurityPermission
Unrestricted
Assertion
Execution
ControlThread ControlPrinicipal
RemotingConfiguration

 



mnp_tickmark.gif
mnp_tickmark.gif
mnp_tickmark.gif
mnp_tickmark.gif
mnp_tickmark.gif

 



mnp_tickmark.gif
mnp_tickmark.gif
mnp_tickmark.gif
mnp_tickmark.gif
mnp_tickmark.gif

 

mnp_tickmark.gif

 

mnp_tickmark.gif

SocketPermission
Unrestricted

 


mnp_tickmark.gif

 

 

 

SqlClientPermission
Unrestricted

 


mnp_tickmark.gif

 


mnp_tickmark.gif

 

 

WebPermission
Unrestricted

 


mnp_tickmark.gif

$OriginHost$

 

 

Approches liées aux applications Web de confiance partielle

Si vous développez une application de confiance partielle ou activez une application pour qu'elle s'exécute à un niveau de confiance partielle, et que celle-ci ne parvient pas à accéder à des ressources car les autorisations adéquates n'ont pas été attribuées, vous pouvez opter pour l'une ou l'autre des approches de base suivantes :

  • Personnalisation de la stratégie
    Personnalisez la stratégie afin d'accorder les autorisations requises à votre application. Il se peut que cette opération soit interdite, comme c'est le cas dans les environnements d'hébergement dont les restrictions de stratégie manquent de souplesse.

  • Code privilégié du sandbox
    Placez le code d'accès des ressources dans un assembly de wrapper, accordez une confiance totale à cet assembly (et non pas à l'application Web) et placez dans le sandbox les exigences d'autorisation du code privilégié.

L'approche appropriée dépend du point sur lequel porte le problème. Si l'application tente d'appeler un assembly système qui ne contient pas d'attribut AllowPartiallyTrustedCallersAttribute, le problème concerne l'attribution d'une confiance totale à une partie du code. Dans ce scénario, l'approche du sandbox doit être choisie car elle permet d'attribuer une confiance totale à l'assembly du wrapper placé dans le sandbox.

Remarque : la personnalisation de la stratégie est la plus aisée des deux approches car elle ne nécessite aucun effort de développement.

Personnalisation de la stratégie

Si votre application Web contient du code nécessitant plus d'autorisations que n'en accorde un niveau de confiance ASP.NET particulier, la personnalisation du fichier de stratégie est le moyen le plus aisé d'accorder les autorisations manquantes à l'application. Vous pouvez soit modifier un fichier de stratégie existant et attribuer des autorisations supplémentaires, soit créer un fichier de stratégie à partir d'un fichier de stratégie existant.

Remarque : si vous éditez l'un des fichiers de stratégie intégrés, tel que le fichier de stratégie de niveau de confiance moyenne, Web_mediumtrust.config, les modifications s'appliqueront à toutes les applications configurées pour s'exécuter au niveau de confiance correspondant.

  • Pour personnaliser une stratégie pour une application

    1. Copiez l'un des fichiers de stratégie existants pour créer un fichier de stratégie. Par exemple, copiez un fichier de stratégie de confiance moyenne pour créer un fichier de stratégie similaire :

      %windir%\Microsoft.NET\Framework\{version}\CONFIG\web_votreconfiance.config
      
    2. Ajoutez l'autorisation requise au niveau du jeu d'autorisations ASP.NET dans le fichier de stratégie ou modifiez une autorisation existante pour accorder une autorisation moins restrictive.

    3. Ajoutez un nouveau mappage <trustLevel> sous <securityPolicy> dans le fichier Machine.config pour le nouveau fichier de niveau de confiance, comme suit :

      <securityPolicy>
        <trustLevel name="Personnalisé" policyFile="web_votreconfiance.config"/>
        . . .
      </securityPolicy>
      
    4. Configurez votre application afin qu'elle s'exécute avec le nouveau niveau de confiance, en définissant l'élément <trust> dans le fichier Web.config de l'application, comme suit :

      <system.web>
        <trust level="Personnalisé" originUrl=""/>
      </system.web>

Code privilégié du sandbox

Une autre approche ne nécessitant pas de mise à jour de la stratégie de sécurité d'accès au code ASP.NET consiste à envelopper votre code d'accès de ressource dans son propre assembly de wrapper et à configurer la stratégie de sécurité d'accès au code au niveau machine afin d'accorder l'autorisation appropriée à l'assembly. Vous pouvez ensuite placer en sandbox le code privilégié supérieur à l'aide de la méthode CodeAccessPermission.Assert pour ne pas avoir à modifier l'attribution globale d'autorisations de l'application Web. La méthode Assert empêche la demande de sécurité émise par le code d'accès aux ressources de propager la sauvegarde de la pile d'appels au-delà des limites de l'assembly de wrapper.

Modèle de mise en sandbox

Il est possible d'appliquer le modèle suivant à tout code privilégié devant accéder à une ressource restreinte ou d'effectuer une autre opération privilégiée pour laquelle l'application Web parente ne possède pas d'autorisations suffisantes :

  1. Encapsulez le code d'accès de ressource dans un assembly de wrapper.
    Assurez-vous que l'assembly porte un nom fort pour qu'il puisse être installé dans le GAC.

  2. Attribuez l'autorisation adéquate avant d'accéder à la ressource.
    Ceci signifie que l'appelant doit posséder l'autorisation de sécurité d'assertion (SecurityPermission avec SecurityPermissionFlag.Assertion). Les applications configurées pour le niveau de confiance moyenne ou les niveaux de confiance supérieurs possèdent cette autorisation.

    L'assertion d'autorisations est dangereuse car elle signifie que le code appelant votre code peut accéder à la ressource encapsulée par votre assembly sans nécessiter l'autorisation d'accès requise pour la ressource. L'instruction Assert indique que votre code peut se porter garant de la légitimité de ses appelants. Pour cela, il doit demander une autre autorisation pour le code appelant avant d'appeler l'instruction Assert. De cette façon, seul le code ayant reçu l'autorisation de remplacement peut accéder à la ressource exposée par l'assembly.

    Il se peut que .NET Framework ne fournisse pas d'autorisation adéquate à demander. Dans ce cas, vous pouvez créer et demander une autorisation personnalisée. Pour plus d'informations sur la création d'une autorisation personnalisée, consultez « Procédure : création d'une autorisation de cryptage personnalisée » dans la section « Procédure » de ce guide.

  3. Annotez l'assembly du wrapper avec l'attribut APTCA.
    L'application Web de confiance partielle peut ainsi appeler l'assembly.

  4. Installez l'assembly du wrapper dans le GAC.
    Le wrapper bénéficie ainsi d'une confiance totale, à la différence de l'application Web. Les fichiers de stratégie ASP.NET contiennent le groupe de code suivant, qui accorde une confiance totale à tout assembly situé dans le GAC :

    <CodeGroup
       class="UnionCodeGroup"
       version="1"
       PermissionSetName="FullTrust>
       <IMembershipCondition 
           class="UrlMembershipCondition"
           Url="$Gac$/*"
           version="1"
       />
    </CodeGroup>
    

    Remarque : la stratégie d'entreprise et la stratégie d'ordinateur local par défaut accordent également une confiance totale à tout code installé dans le GAC. Ceci est important du fait du recoupement des autorisations octroyées entre niveaux de stratégie.

  5. Configurez le niveau de confiance de l'application Web (par exemple, réglez-le sur « Medium »).

La figure 9.2 représente l'approche du sandbox.

Mise en sandbox du code privilégié dans son propre assembly, qui attribue l'autorisation adéquate

Figure 9.2
Mise en sandbox du code privilégié dans son propre assembly, qui attribue l'autorisation adéquate

Il est conseillé d'utiliser des assemblys distincts pour encapsuler l'accès des ressources et éviter de placer le code d'accès dans des fichiers .aspx ou dans du code en arrière-plan. Par exemple, créez un assembly d'accès de données distinct afin d'encapsuler l'accès à la base de données. Ceci simplifie la migration d'applications vers des environnements de confiance partielle.

Choix de l'approche à adopter

L'approche appropriée dépend du problème que vous tentez de résoudre et de la possibilité que vous avez ou non de modifier la stratégie de sécurité sur le serveur Web.

Personnalisation de la stratégie

Cette approche est la plus aisée des deux car elle ne requiert aucun effort de développement. Cependant, il se peut que vous n'ayez pas le droit de modifier la stratégie du serveur Web et, dans certains scénarios, votre code qui appelle la bibliothèque de classes .NET Framework peut nécessiter une confiance totale. Dans ces situations, vous devez recourir au sandbox. Par exemple, les ressources suivantes exigent une confiance totale et vous devez placer en sandbox le code d'accès aux ressources lorsque vous accédez à celles-ci :

  • journaux des événements (via la classe EventLog) ;

  • sources de données OLE DB (via le fournisseur de données ADO.NET OLE DB) ;

  • source de données ODBC (via le fournisseur de données ODBC .NET ADO.NET) ;

  • bases de données Oracle (via le fournisseur de données Oracle .NET ADO.NET).

Remarque : cette liste n'est pas exhaustive mais comporte les types de ressources courants nécessitant une confiance totale.

Mise en sandbox

Si vous placez en sandbox votre code d'application privilégié dans un assembly séparé, vous pouvez accorder des autorisations supplémentaires à ce dernier. Vous pouvez également lui accorder une confiance totale sans que l'application s'exécute avec des autorisations étendues.

Prenons l'exemple de code utilisant le fournisseur de données ADO.NET OLE DB et interagissant avec la classe System.Data.OleDb.OleDbCommand. Ce code nécessite une confiance totale. Bien que l'assembly System.Data.dll soit annoté avec AllowPartiallyTrustedCallersAttribute, les classes (dont fait partie System.Data.OleDb.OleDbCommand ) ne peuvent être appelées par des appelants de confiance partielle car elles sont protégées par une demande de liaison de confiance totale. Pour le constater, exécutez la commande suivante à l'aide de l'utilitaire permview à partir du répertoire %windir%\Microsoft.NET\Framework\{version} :

permview /DECL /OUTPUT System.Data.Perms.txt System.Data.dll

Le fichier System.Data.Perms.txt obtenu comporte la sortie suivante :

class System.Data.OleDb.OleDbCommand LinktimeDemand permission set:
<PermissionSet class="System.Security.PermissionSet"
               version="1" Unrestricted="true"/>

Vous pouvez constater qu'un jeu d'autorisations illimitées (confiance totale) est employé dans une demande de liaison protégeant la classe System.Data.OleDb.OleDbCommand. Dans un tel scénario, la configuration de la stratégie n'est pas suffisante pour accorder des autorisations illimitées, comme OleDbPermission, à votre code de confiance partielle. Vous devez en fait placer en sandbox votre code d'accès de ressource et lui accorder une confiance totale. Le moyen le plus simple d'y parvenir consiste à l'installer dans le GAC. À l'aide de Permview.exe, vous pouvez connaître les exigences d'autorisation d'autres classes, bien que cet utilitaire n'affiche que les attributs de sécurité déclaratifs. Si une classe exige impérativement une confiance totale, cette demande est visible via Permview.exe. Dans ce cas, testez les exigences de sécurité de la classe en l'appelant à partir de code à confiance partielle et en diagnostiquant les éventuelles exceptions de sécurité.

Remarque : le fait que l'assembly possède l'attribut APTCA ne signifie pas que toutes les classes contenues prennent en charge des appelants de confiance. Certaines classes peuvent comporter des demandes explicites de confiance totale.

Confiance moyenne

En hébergeant des applications Web, vous pouvez choisir d'implémenter une stratégie de sécurité de confiance moyenne afin de limiter les opérations privilégiées. Cette section traite de l'exécution d'applications de confiance moyenne et explique comment résoudre les problèmes que vous risquez de rencontrer.

L'exécution de code à un niveau de confiance moyenne présente les deux avantages principaux suivants :

  • réduction de la zone exposée aux attaques ;

  • isolement des applications.

Réduction de la zone exposée aux attaques

Comme la confiance moyenne n'accorde pas à l'application un accès illimité à toutes les autorisations mais seulement à un certain nombre d'entre elles, la surface exposée aux attaques se trouve réduite. La plupart des autorisations accordées par une stratégie de niveau de confiance moyenne se trouvent également dans un état restreint. Si un attaquant est capable de prendre le contrôle de votre application, il est en revanche limité dans ses actions.

Isolement des applications

L'isolement des applications par sécurité d'accès au code restreint les accès aux ressources système et aux ressources appartenant à d'autres applications. Par exemple, même si l'identité du processus permet de lire et d'écrire des fichiers hors du répertoire de l'application Web, l'autorisation FileIOPermission est limitée dans les applications à niveau de confiance moyenne. En effet, elle permet à l'application de lire et d'écrire dans sa propre hiérarchie de répertoires uniquement.

Restrictions de la confiance moyenne

Si elle s'exécute avec un niveau de confiance moyenne, votre application rencontre un certain nombre de restrictions, dont les plus notables sont les suivantes  :

  • Elle ne peut pas accéder directement au journal des événements.

  • Son accès au système de fichiers est limité et elle ne peut accéder qu'aux fichiers se trouvant dans sa hiérarchie de répertoires virtuels.

  • Elle ne peut pas accéder directement aux sources de données OLE DB (bien que les applications de confiance moyenne bénéficient de l'autorisation SqlClientPermission, qui leur permet d'accéder à SQL Server).

  • Son accès aux services Web est limité.

  • Elle ne peut pas accéder directement au Registre Windows.

Cette section explique comment accéder aux types de ressources suivants à partir d'une application Web ou d'un service Web d'un niveau de confiance moyenne : 

  • OLE DB ;

  • journal des événements ;

  • services Web ;

  • Registre.

OLE DB

L'autorisation OleDbPermission n'est pas octroyée aux applications Web à niveau de confiance moyenne. De plus, le fournisseur OLE DB .NET exige des appelants de confiance totale. Si une application doit accéder à des sources de données alors qu'elle s'exécute au niveau de confiance moyenne, optez pour l'approche du sandbox. Placez votre code d'accès aux données dans un assembly séparé, attribuez-lui un nom fort, puis installez-le dans le GAC, ce qui lui octroie un niveau de confiance totale.

Remarque : la modification d'une stratégie ne fonctionne que si vous avez réglé le niveau de confiance sur « Full » car le fournisseur géré OLE DB exige une confiance totale.

La figure 9.3 illustre la procédure.

Mise en sandbox de l'accès à la ressource OLE DB

Figure 9.3
Mise en sandbox de l'accès à la ressource OLE DB

Mise en sandbox

Dans cette approche, l'assembly du wrapper créé vous permet d'encapsuler un accès à la source de données OLE DB. Cet assembly reçoit des autorisations illimitées, nécessaires pour utiliser le fournisseur ADO.NET OLE DB.

  • Pour créer un assembly du wrapper en sandbox capable d'appeler des sources de données OLE DB

    1. Créez un assembly pour votre code d'accès aux données. Configurez la version de l'assembly, affectez un nom fort à l'assembly ainsi que l'attribut AllowPartiallyTrustedCallersAttribute, comme suit :

      [assembly: AssemblyVersion("1.0.0.0")]
      [assembly: AssemblyKeyFile(@"..\..\oledbwrapper.snk")] 
      [assembly:AllowPartiallyTrustedCallersAttribute()]
      

      Pour pouvoir prendre en charge des appelants de confiance, un assembly à nom fort doit être annoté avec l'attributAllowPartiallyTrustedCallersAttribute. Cela rend inutile le chargement d'une demande de liaison implicite de confiance totale à partir d'un assembly à nom fort ainsi que sa compilation JIT.

    2. Demandez une confiance totale. Bien que cela ne soit pas absolument nécessaire, il est conseillé de demander une confiance totale car l'administrateur peut ainsi visualiser les exigences d'autorisation de l'assembly à l'aide d'outils tels que Permview.exe. Pour obtenir une confiance totale, demandez le jeu d'autorisations illimitées comme suit :

      [assembly: PermissionSet(SecurityAction.RequestMinimum, Unrestricted=true)]
      
    3. Enveloppez les appels de base de données à l'aide de l'instruction Assert afin de bénéficier d'une confiance totale. Enveloppez un appel RevertAssert pour inverser l'effet de l'assertion. Bien que cela ne soit pas indispensable, il est conseillé de placer l'appel de RevertAssert dans un bloc finally.
      Du fait que le fournisseur OLE DB exige une confiance totale, le wrapper doit attribuer ce niveau de confiance. L'assertion d'une autorisation OleDbPermission n'est pas suffisante. L'étape 7 explique comment améliorer la sécurité à l'aide de CodeAccessPermission.Assert.

      public OleDbDataReader GetProductList()
      {
        try
        {
          // Confiance totale (jeu d'autorisations illimitées)
          new PermissionSet(PermissionState.Unrestricted).Assert();
          OleDbConnection conn = new OleDbConnection(
             "Provider=SQLOLEDB; Data Source=(local);" +
             "Integrated Security=SSPI; Initial Catalog=Northwind");
          OleDbCommand cmd = new OleDbCommand("spRetrieveProducts", conn);
          cmd.CommandType = CommandType.StoredProcedure;
          conn.Open();
          OleDbDataReader reader = 
                cmd.ExecuteReader(CommandBehavior.CloseConnection);
          return reader;
        }
        catch(OleDbException dbex)
        {
          // Consigner et gérer l'exception
        }
        catch(Exception ex)
        {
          // Consigner et gérer l'exception
        }
        finally
        {
          CodeAccessPermission.RevertAssert();
        }
        return null;
      }
    4. Générez l'assembly et installez-le dans le GAC à l'aide de la commande suivante :

      gacutil -i oledbwrapper.dll
      

      Pour garantir l'ajout de l'assembly dans le GAC à chaque génération, insérez la ligne de commande de l'événement après génération (disponible dans la boîte de dialogue des propriétés du projet dans Visual Studio.NET) dans le projet de l'assembly du wrapper :

      "C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\gacutil.exe" 
      /i $(TargetPath)
      

      Remarque : tout assembly à nom fort appelé par une application ASP.NET Web ou un service Web doit être installé dans le GAC. Dans cette instance, vous devez installer l'assembly pour vérifier qu'il bénéficie d'un accès illimité.

    5. Configurez votre application Web pour lui attribuer un niveau de confiance moyenne. Ajoutez le code ci-dessous dans Web.config ou placez-le dans un élément <location> pointant vers votre application :

      <trust level="Medium" originUrl=""/>
      
    6. Référencez l'assembly d'accès aux données à partir de votre application Web ASP.NET.
      Du fait qu'un assembly à nom fort doit se trouver dans le GAC, et non pas dans le répertoire \bin d'une application Web, vous devez ajouter l'assembly à la liste des assemblys de l'application si vous n'utilisez pas de code associé à des fichiers. Pour obtenir le jeton de clé publique, PublicKeyToken de l'assembly, exécutez la commande suivante :

      sn -Tp oledbwrapper.dll
      

      Remarque : le commutateur –T doit être en majuscule.

      Ajoutez ce qui suit dans Machine.config ou Web.config :

      <compilation debug="false" >
        <assemblies>
          <add assembly="oledbwrapper, Version=1.0.0.0, Culture=neutral,    
               PublicKeyToken=4b...06"/>
        </assemblies>
      </compilation>
      

      Remarque : entre les générations successives de votre assembly du wrapper, il se peut que vous deviez recycler le processus de traitement ASP.NET, car l'assembly, installé dans le GAC, est placé en mémoire cache par le processus ASP.NET. Pour recycler le processus de traitement ASP.NET (Aspnet_wp.exe), vous pouvez exécuter l'utilitaire IISreset.exe.

    7. Protégez le code qui appelle Assert.
      L'appel de Assert signifie que tout code appelant le wrapper d'accès aux données peut interagir avec la source de données OLE DB. Pour empêcher du code nuisible d'appeler le composant d'accès aux données et de l'utiliser pour diriger des attaques contre la base de données, vous pouvez émettre une demande d'autorisation personnalisée avant d'appeler Assert et mettre à jour le fichier de stratégie de niveau de confiance moyenne pour accorder l'autorisation personnalisée à votre application Web. Cette solution implique un effort de développement raisonnable.

      Pour plus d'informations sur le développement d'une autorisation personnalisée, consultez « Procédure : création d'une autorisation de cryptage personnalisée » dans la section « Procédure » de ce guide.

Journal d'événements

La classe EventLogPermission est conçue pour encapsuler les droits d'accès du code au journal des événements. Cependant, pour accéder au journal des événements, le code doit disposer d'une confiance totale. Ceci signifie qu'une application Web d'un niveau de confiance moyenne ne peut pas accéder directement au journal des événements. Pour y remédier, vous devez placer dans le sandbox le code de journalisation d'événement.

Accès au journal des événements

Assurez-vous tout d'abord que le compte de processus employé pour l'exécution de votre application Web (ou l'identité du thread si l'application a emprunté celle-ci) est capable de créer des sources d'événements. Pour cela, le processus ou l'identité du thread doit pouvoir créer des clés de Registre sous la clé suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog 

L'identité du processus ASP.NET de toute identité empruntée doit disposer des autorisations suivantes sur cette clé de Registre :

  • requête valeur de clé ;

  • affectation valeur de clé ;

  • création sous-clé ;

  • énumération des sous-clés ;

  • notification ;

  • lecture.

Ces paramètres doivent être appliqués à la clé ci-dessus et à ses sous-clés. Vous pouvez également créer des sources d'événements lors de l'installation quand des privilèges d'administration sont disponibles. Pour plus d'informations sur cette approche, consultez la section traitant de l'audit et de la journalisation dans le module 10, « Création de pages et de contrôles ASP.NET sécurisés ».

Mise en sandbox

Pour placer dans le sandbox votre code de journal d'événements, vous créez un assembly de wrapper afin d'encapsuler l'accès au journal des événements. Vous pouvez ensuite installer l'assembly dans le GAC de sorte que la stratégie de sécurité d'accès au code accorde un niveau de confiance totale.

  • Pour générer un assembly de wrapper mis en sandbox permettant d'écrire dans le journal des événements

    1. Créez un assembly pour votre code d'accès au journal des événements. Configurez la version de l'assembly, affectez un nom fort à l'assembly ainsi que l'attribut AllowPartiallyTrustedCallersAttribute, comme suit :

      [assembly: AssemblyVersion("1.0.0.0")]
      [assembly: AssemblyKeyFile(@"..\..\eventlogwrapper.snk")] 
      [assembly:AllowPartiallyTrustedCallersAttribute()]
      

      Pour pouvoir prendre en charge des appelants de confiance, un assembly à nom fort doit être annoté avec l'attribut AllowPartiallyTrustedCallersAttribute. Cela rend inutile le chargement d'une demande de liaison implicite de confiance totale à partir d'un assembly à nom fort ainsi que sa compilation JIT.

      Remarque : AllowPartiallyTrustedCallersAttribute est défini dans l'espace de noms System.Security, que vous devez référencer à l'aide d'une instruction using.

    2. Demandez des autorisations adéquates.
      Bien que cette option ne soit pas indispensable, la demande d'autorisations adéquates est conseillée car elle permet à un administrateur de visualiser les exigences d'autorisation de l'assembly à l'aide d'outils comme Permview.exe. Comme il est accessible à partir d'appelants de niveau de confiance partielle, l'assembly du journal des événements n'a pas à demander un jeu d'autorisations illimitées. Dans cet exemple, l'assembly n'écrit que dans le journal des événements d'un ordinateur précis et, par conséquent, requiert seulement la demande d'autorisation suivante :

      [assembly:EventLogPermissionAttribute(SecurityAction.RequestMinimum,
      MachineName="<nom ordinateur>",
      PermissionAccess=EventLogPermissionAccess.Instrument)]
      

      Cependant, si votre assembly requiert une confiance totale, demandez le jeu d'autorisations illimitées comme suit :

      [assembly: PermissionSet(SecurityAction.RequestMinimum, Unrestricted=true)]
      
    3. Enveloppez les appels du journal des événements avec une instruction Assert qui octroie une confiance totale et avec une instruction RevertAssert qui inverse l'effet de l'instruction précédente. Bien que ce ne soit pas indispensable, il est conseillé de placer l'appel de RevertAssert dans un bloc finally. Le code suivant écrit une entrée Information dans le journal Application avec le texte « Écriture dans le journal des événements » :

      try
      {
        string source = "Source de l'événement";
        string log = "Application";
        string eventText = "Écriture dans le journal des événements";
        EventLogEntryType eventType = EventLogEntryType.Information;
      
        //Attribuer l'autorisation
        EventLogPermission eventPerm;
        eventPerm = new EventLogPermission(EventLogPermissionAccess.Instrument,
      "<machinename>");
        eventPerm.Assert();
      
        //Vérifier l'existence de la source.
        if(!EventLog.SourceExists(source))
        {//Clés inexistantes : votre application doit être enregistrée en tant que source
           EventLog.CreateEventSource(source, log);
        }
      
        //Écrire dans le journal.
        EventLog.WriteEntry(source, eventText, eventType);
        }
        catch(Exception ex)
        {/*Handle exception*/}
        finally
        {
          CodeAccessPermission.RevertAssert();
        }
      
    4. Générez l'assembly et installez-le dans le GAC à l'aide de la commande suivante :

      gacutil -i eventlogwrapper.dll
      

      Pour garantir l'ajout de l'assembly dans le GAC à chaque génération, insérez la ligne de commande de l'événement après génération (disponible dans la boîte de dialogue des propriétés du projet dans Visual Studio.NET) dans le projet de l'assembly du wrapper :

      "C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\gacutil.exe" 
      /i $(TargetPath)
      

      Remarque : tout assembly à nom fort appelé par une application Web ou un service Web ASP.NET doit être installé dans le GAC. Les assemblys installés dans le GAC bénéficient d'une confiance totale accordée par la stratégie d'accès au code par défaut.

    5. Configurez votre application Web pour lui attribuer un niveau de confiance moyenne. Ajoutez le code ci-dessous dans Web.config ou placez-le dans un élément <location> pointant vers votre application :

      <trust level="Medium" originUrl=""/>
      
    6. Référencez l'assembly du journal des événements à partir de votre application Web ASP.NET.


      Du fait qu'un assembly à nom fort doit se trouver dans le GAC et non pas dans le répertoire \bin d'une application Web, vous devez ajouter l'assembly à la liste des assemblys de l'application si vous n'utilisez pas de code associé à des fichiers. Pour obtenir le jeton de clé publique, PublicKeyToken de l'assembly, exécutez la commande suivante :

      sn -Tp eventlogwapper.dll
      

      Remarque : le commutateur –T doit être en majuscule.

      Ajoutez le code suivant dans Machine.config ou Web.config :

      <compilation debug="false" >
        <assemblies>
          <add assembly="eventlogwrapper, Version=1.0.0.0, Culture=neutral,
               PublicKeyToken=4b...06"/>
        </assemblies>
      </compilation>
      

      Remarque : entre les générations successives de votre assembly du wrapper, il se peut que vous deviez recycler le processus de traitement ASP.NET, car l'assembly, installé dans le GAC, est placé en mémoire cache par le processus ASP.NET. Pour recycler le processus de traitement ASP.NET (Aspnet_wp.exe), vous pouvez exécuter l'utilitaire iisreset.exe.

    7. Protégez le code qui appelle la méthode Assert. L'appel de Assert signifie que tout code qui appelle le wrapper du journal des événements est capable d'interagir avec ce journal. Pour empêcher que du code nuisible utilise le wrapper du journal des événements pour remplir le journal de même nom, vous pouvez émettre une demande d'autorisation personnalisée avant d'appeler Assert et mettre à jour le fichier de stratégie de confiance moyenne afin d'accorder l'autorisation personnalisée à l'application Web. Cette solution requiert un effort de développement raisonnable.

      Pour plus d'informations sur le développement d'une autorisation personnalisée, consultez « Procédure : création d'une autorisation de cryptage personnalisée » dans la section « Procédure » de ce guide.

Services Web

Par défaut, la stratégie de confiance moyenne accorde aux applications Web ASP.NET une autorisation WebPermission restreinte. Pour pouvoir appeler des services Web à partir d'une application Web, vous devez configurer l'attribut originUrl sur l'élément <trust> de votre application.

  • Pour appeler un service Web à partir d'une application Web de confiance moyenne

    1. Configurez l'application pour qu'elle s'exécute au niveau de confiance moyenne.

    2. Faites pointer originUrl vers le service Web à appeler, comme suit :

      <trust level="Medium" originUrl="http://servername/.*"/>
      

La valeur de originUrl est employée dans le constructeur d'une classe d'expressions rationnelles System.Text.RegEx, ce qui permet d'effectuer une correspondance avec les URL accessibles par le service Web. Cette classe RegEx est utilisée conjointement avec une classe WebPermission. Le motif « .* » correspond à toute URL commençant par « http://servername/ ».

L'attribut originUrl est employé lors de l'évaluation de la stratégie ASP.NET. Il fournit une valeur pour le paramètre de substitution $OriginHost$. Voici la définition de l'autorisation WebPermission extraite du fichier de stratégie Web_mediumtrust.config :

<IPermission
   class="WebPermission"
   version="1">
   <ConnectAccess>
     <URI uri="$OriginHost$"/>
   </ConnectAccess>
</Ipermission>

Si vous n'indiquez pas les serveurs Web accessibles par votre application, les demandes de service Web échoueront avec une exception SecurityException. Pour appeler un service Web sur le serveur Web local, utilisez la configuration suivante :

<trust level="Medium" originUrl="http://localhost/.*" />

Si l'application doit accéder à plusieurs services Web sur des serveurs différents, vous devez personnaliser la stratégie ASP.NET car un seul originUrl peut être défini sur l'élément <trust> dans Web.config ou dans Machine.config.

  • Pour appeler plusieurs services Web à partir d'une application de confiance moyenne

    1. Copiez le fichier Web_mediumtrust.config, qui réside dans le répertoire suivant, dans un fichier appelé Web_mediumtrust_WebService.config, au même emplacement.

      %windir%\Microsoft.NET\Framework\{version}\CONFIG
      
    2. Localisez l'autorisation WebPermission et ajoutez un élément <URI> pour chaque serveur auquel vous souhaitez accéder :

      <IPermission class="WebPermission" version="1">
        <ConnectAccess>
          <URI uri="$OriginHost$"/>
          <URI uri="http://server1/.*"/>
          <URI uri="http://server2/.*"/>
          <URI uri="http://server3/.*"/>
        </ConnectAccess>
      </Ipermission>
      

      Si vous appelez le service Web à l'aide de son nom NetBIOS, de son nom DNS et/ou de son adresse IP, vous devez définir un élément <URI> pour chaque URI, comme indiqué dans l'exemple suivant.

      <IPermission class="WebPermission" version="1">
        <ConnectAccess>
          <URI uri="$OriginHost$"/>
          <URI uri="http://nomserveur.votreDomaine.com/.*"/>
          <URI uri="http:// nomserveur/.*"/>
          <URI uri="http://127.0.0.1/.*"/>
        </ConnectAccess>
      </Ipermission>
      
    3. Enregistrez le fichier.

    4. Mettez à jour le fichier Web.config de votre application de sorte qu'il pointe vers le fichier de stratégie nouvellement créé. Ceci nécessite de créer un niveau de confiance et de l'associer au nouveau fichier de stratégie. Configurez ensuite l'élément <trust> pour que l'application emploie le nouveau niveau.

      Le fragment de code suivant montre les ajouts nécessaires apportés à Web.config :

      <system.web>
        <securityPolicy>
          <trustLevel name="MediumPlusWebPermission" 
                      policyFile="web_mediumtrust_WebService.config"/>
        </securityPolicy>
        <trust level=" MediumPlusWebPermission" originUrl=""/>
      </system.web>
Utilisation d'informations d'authentification par défaut

Il se peut que vous deviez appeler un service Web utilisant l'authentification Windows et employer des informations d'authentification via le cache des informations d'authentification du proxy. Par exemple :

proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;

Dans ce cas, l'application ASP.NET nécessite l'autorisation EnvironmentPermission avec un accès en lecture à la variable d'environnement USERNAME. La stratégie de confiance moyenne accorde cette autorisation aux applications Web.

Dans un scénario serveur ASP.NET, les informations d'authentification sont obtenues auprès d'un jeu de threads ou d'un jeton de niveau processus de l'application ASP.NET. L'utilisation de DefaultCredentials à partir d'une application de bureau signifie l'utilisation du jeton de l'utilisateur interactif. La demande de l'autorisation EnvironmentPermission est une stratégie de réduction des risques conçue pour garantir que le code n'emploie pas les informations d'authentification de l'utilisateur local et les expose sur le réseau.

Registre

Par défaut, les applications Web de confiance moyenne ne reçoivent pas l'autorisation RegistryPermission. Pour que votre application puisse accéder au Registre, vous devez modifier la stratégie ASP.NET afin d'accorder cette permission à l'application ou développer un assembly du wrapper dans le sandbox disposant de l'autorisation nécessaire.

L'approche du sandbox est similaire à celle décrite précédemment pour les sources de données OLE DB et le journal des événements.

Personnalisation de la stratégie

Le moyen le plus aisé de personnaliser la stratégie est de créer un fichier de stratégie personnalisé basé sur le fichier de stratégie de niveau de confiance moyenne et de configurer votre application pour qu'elle utilise la stratégie personnalisée. Cette dernière accorde l'autorisation RegistryPermission à l'application.

  • Pour créer une stratégie personnalisée autorisant les accès au Registre

    1. Copiez le fichier Web_mediumtrust.config, qui réside dans le répertoire suivant, dans un fichier appelé Web_mediumtrust_Registry.config, au même emplacement.

      %windir%\Microsoft.NET\Framework\{version}\CONFIG
      

      La duplication du fichier Web_mediumtrust.config en vue de la création d'un fichier de stratégie personnalisé évite d'intervenir directement dans le fichier de stratégie de niveau de confiance moyenne d'origine, ce qui aurait pour effet d'affecter toutes les applications de l'ordinateur configurées pour ce niveau de confiance.

    2. Localisez l'élément <SecurityClasses> et ajoutez ce qui suit afin d'enregistrer la classe RegistryPermission :

      <SecurityClass Name="RegistryPermission" 
                     Description="System.Security.Permissions.RegistryPermission, 
                     mscorlib, Version=1.0.5000.0, Culture=neutral, 
                     PublicKeyToken=b77a5c561934e089"/>
      
    3. Localisez le jeu d'autorisations ASP.NET et ajoutez-lui l'autorisation RegistryPermission illimitée comme suit :

      <IPermission class="RegistryPermission" version="1" Unrestricted="true" />
      
    4. Enregistrez le fichier.

    5. Mettez à jour Machine.config afin de créer un nouveau niveau de confiance associé au nouveau fichier de stratégie.

      <system.web>
        <securityPolicy>
          <trustLevel name="MediumPlusRegistry" 
                      policyFile="web_mediumtrust_Registry.config "/>
        </securityPolicy>
      
    6. Mettez à jour le fichier Web.config de votre application afin de configurer le niveau <trust> de celle-ci.

      <system.web>
        <trust level="MediumPlusRegistry" originUrl=""/>
      </system.web>

Résumé

La sécurité d'accès au code est un modèle de sécurité de contraintes de ressources favorisant l'isolement des applications. Celles-ci peuvent être configurées pour s'exécuter à différents niveaux de confiance partielle. Le niveau de confiance détermine les autorisations accordées à l'application Web ou au service Web ASP.NET. Il détermine les types de ressources accessibles et les autres types d'opérations privilégiées réalisables. Dans tous les cas, les accès aux ressources obéissent à la sécurité du système d'exploitation.

Le modèle d'isolement recommandé emploie les pools d'applications IIS 6.0 sous Windows Server 2003 et fournit à la fois une sécurité d'accès du code et un isolement de niveau processus. Sur Windows 2000, l'isolement n'est possible qu'en utilisant la sécurité d'accès au code et des identités de threads séparées.

La migration d'une application en vue de son exécution avec un niveau de confiance partielle nécessite généralement de remanier notablement le code. Ce réagencement peut être nécessaire si l'application accède à des ressources qui ne sont pas autorisées par le niveau de confiance partielle ou si elle appelle des assemblys à nom fort dépourvus de l'attribut APTCA. Vous pouvez alors placer en sandbox l'accès privilégié aux ressources dans des assemblys de wrapper distincts. Certains scénarios vous autorisent à créer et à utiliser des fichiers de stratégie personnalisés, qui s'appuient néanmoins sur la stratégie de sécurité de votre serveur Web.

Il est conseillé de placer le code d'accès aux ressources dans des assemblys séparés, et non pas dans des fichiers .aspx et dans des fichiers de code. L'emploi d'un assembly séparé permet l'application de la stratégie d'accès du code à celui-ci indépendamment de l'application Web et vous autorise à développer du code fiable en sandbox afin d'accéder à des ressources.

Ressources supplémentaires

Pour plus d'informations, consultez les ressources suivantes :

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft. Tous droits réservés.