Sécurité d'accès du code ASP.NET
Mise à jour : novembre 2007
L'un des avantages de l'utilisation d'ASP.NET pour héberger plusieurs sites Web est la prise en charge dans le Common Language Runtime (CLR) de la sécurité d'accès du code pour protéger les applications serveur. Le code est assigné à une classification des zones de sécurité basée sur la preuve concernant l'origine du code (comme par exemple un assembly avec nom fort ou l'URL d'origine).
Les applications qui s'exécutent en confiance totale peuvent encore être contraintes par les autorisations de fichiers NTFS, les autorisations de bases de données, etc., à l'aide du compte Windows (identité du processus ASP.NET) sous lequel elles exécutent. Pour plus d'informations, consultez Configuration de l'identité de processus ASP.NET.
En général, vous pouvez configurer la sécurité d'accès du code d'un assembly donné en lui attribuant un nom fort et en ajoutant la stratégie de sécurité de cet assembly. Cependant, comme nombre d'assemblys ASP.NET sont générés dynamiquement pendant la compilation de page et, par conséquent, ne reçoivent pas un nom fort, vous devez configurer la stratégie de sécurité de ces assemblys indirectement. En outre, puisqu'ASP.NET prend en charge des applications sans compilation, la preuve basée sur les assemblys n'est pas prise en charge. Étant donné que les applications ASP.NET incluent le concept de structures de répertoire, il est beaucoup plus facile de configurer la sécurité d'accès du code en fonction des catégories d'applications ASP.NET que de configurer manuellement .NET Framework pour qu'il fonctionne séparément avec chaque application ASP.NET sur un ordinateur.
Pour chaque application, ASP.NET vous laisse assigner un niveau de confiance configurable qui correspond à un jeu prédéfini d'autorisations. Par défaut, le niveau de confiance est assigné aux applications en fonction de la preuve qu'elles présentent. Si vous souhaitez exécuter une application Web avec un jeu d'autorisations plus limité que Full, vous devez utiliser l'un des niveaux de confiance prédéfinis dans les Fichiers de stratégie et niveaux de confiance ASP.NET pour appliquer une stratégie de confiance partielle.
Vous pouvez utiliser les paramètres de configuration suivants du fichier Web.config de l'application pour substituer le comportement par défaut et associer une application à une stratégie de sécurité donnée.
<location path="SampleApp" allowOverride="false">
<trust level="High"
originUrl="https://www.contoso.com"/>
</location>
L'élément de configuration trust peut s'appliquer au niveau de l'ordinateur (auquel cas chaque application ASP.NET s'exécute à ce niveau de confiance) ou à n'importe quel répertoire racine de l'application dans la hiérarchie (auquel cas le niveau de confiance s'applique à l'application ASP.NET spécifique). Si vous souhaitez définir la stratégie pour la totalité d'un site, vous pouvez le faire en modifiant le fichier Web.config de l'application racine du site et en spécifiant la racine du site comme emplacement du chemin d'accès (voir l'exemple ci-après).
<location path="ContosoSite" allowOverride="false">
<trust level="High"
originUrl="https://www.contoso.com"/>
</location>
Pour les sites approuvés, il est recommandé d'affecter la valeur High à l'attribut level de l'élément de configuration trust. Pour les sites qui ne le sont pas, par exemple un serveur Web qui héberge des sites qui exécutent le code à partir d'un client externe, il est recommandé d'affecter la valeur Medium à l'attribut level de l'élément de configuration trust. Pour une description détaillée de l'exécution d'applications ASP.NET en confiance moyenne, consultez « How To: Use Medium Trust in ASP.NET 2.0 » dans Patterns and Practices (PAG): Security Guidance for Applications.
Si vous configurez les paramètres de confiance au niveau ordinateur ou site, vous affectez généralement l'attribut allowOverride à la valeur false dans l'élément location afin que les applications ne puissent pas spécifier leur propre niveau de confiance. Tel est généralement le cas dans les installations serveur partagées.
Le tableau suivant répertorie les attributs pris en charge par défaut pour l'élément de configuration trust :
Attribut |
Description |
Valeurs acceptées |
|---|---|---|
level |
Spécifie la zone de sécurité dans laquelle l'application sera exécutée. |
Full, High, Medium, Low et Minimal. |
originUrl |
Spécifie une URL ou un modèle d'URL autorisé pour l'accès de connexion à l'aide des classes de l'espace de noms System.Net. S'il est présent, cet attribut peut être utilisé pour vérifier les autorisations de certains objets, tels qu'une instance WebRequest, qui autorise la connectivité à plusieurs emplacements réseau. Par exemple, vous pouvez configurer cet attribut avec le nom d'hôte de serveurs dans une batterie de serveurs Web afin que les pages ASP.NET puissent appeler les services Web déployés dans la même batterie de serveurs Web que l'application Web. |
URL HTTP de forme correcte ou syntaxe regex prise en charge par WebPermissionAttribute. |
Le tableau suivant répertorie les types d'autorisation pris en charge par le CLR et la stratégie par défaut de chaque autorisation sous différents niveaux de confiance.
Autorisation |
Full |
High |
Medium |
Low |
Minimal |
|---|---|---|---|---|---|
Full |
High |
Medium |
Low |
Minimal |
|
Intégral |
Intégral |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
|
Intégral |
Intégral |
Intégral |
Aucune autorisation |
Aucune autorisation |
|
Intégral |
Intégral |
Read : TEMP, TMP, OS, USERNAME, COMPUTERNAME |
Aucune autorisation |
Aucune autorisation |
|
Intégral |
Intégral |
Read, Write, Append, PathDiscovery : Répertoire de l'application |
Read, PathDiscovery: Répertoire de l'application |
Aucune autorisation |
|
Intégral |
Intégral |
AssemblyIsolationByUser, Intégral UserQuota |
1 Mo UserQuota (valeur modifiable en fonction des sites), AssemblyIsolationByUser |
Aucune autorisation |
|
Intégral |
Aucune autorisation |
Aucune autorisation |
|||
Intégral |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
||
Intégral |
Intégral |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
|
Intégral |
Execution, Assertion, ControlPrincipal, ControlThread, RemotingConfiguration |
Execution, Assertion, ControlPrincipal, ControlThread, RemotingConfiguration |
|||
Intégral |
Aucune autorisation |
Aucune autorisation |
|||
Intégral |
Intégral |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
|
Intégral |
Intégral |
Connect à l'hôte d'origine (si configuré) |
Aucune autorisation |
Aucune autorisation |
|
Intégral |
Intégral |
Intégral |
Aucune autorisation |
Aucune autorisation |
|
Journal des événements |
Intégral |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
File d'attente de messages |
Intégral |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
Contrôleur de services |
Intégral |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
Compteurs de performance |
Intégral |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
Service d'annuaire |
Intégral |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
Aucune autorisation |
Lorsqu'un niveau d'autorisation est disponible, mais qu'il n'est pas mentionné explicitement dans la stratégie de sécurité, les applications exécutées avec les autorisations Full peuvent toujours l'utiliser. Les applications qui s'exécutent avec des niveaux de confiance inférieurs ne pourront pas utiliser les ressources à moins que vous ne leur accordiez des autorisations explicites en modifiant la stratégie de sécurité.
Comme l'illustre le tableau, une application avec des autorisations High définit des autorisations en lecture/écriture pour les fichiers des répertoires d'application, et une application ayant une confiance Low possède une autorisation en lecture seule pour les fichiers des répertoires d'application. Comme le type FileIOPermission repose sur un chemin d'accès physique (par exemple, c:\SampleAppPath), ASP.NET utilise une instruction sous forme de jeton dans les fichiers de stratégie, remplacée au moment de l'exécution par les informations sur le chemin d'accès pertinent pour l'application.
Le type WebPermission permet à l'application de se connecter à l'emplacement réseau défini par l'attribut d'hôte d'origine à l'aide des classes comme System.Net.WebRequest. Dans ASP.NET, vous pouvez configurer cette autorisation en fournissant un attribut originUrl facultatif sur la section trust d'une application donnée. L'attribut originUrl remplace la variable $OriginHost$ dans les fichiers de stratégie, comme illustré dans la section suivante du fichier Web_hightrust.config :
<IPermission class="WebPermission" version="1">
<ConnectAccess>
<URI uri="$OriginHost$"/>
</ConnectAccess>
</IPermission>