Meilleures pratiques dans un environnement de confiance partielle
Cet article décrit les meilleures pratiques lors de l’exécution de Windows Communication Foundation (WCF) dans un environnement d’approbation partielle.
Sérialisation
Appliquez ces pratiques lors de l’utilisation de DataContractSerializer dans une application partiellement approuvée.
Tous les types sérialisables doivent être marqués explicitement avec l'attribut [DataContract]. Les techniques suivantes ne sont pas prises en charge dans un environnement de confiance partielle :
- Marquage des classes à sérialiser avec le SerializableAttribute.
- L'implémentation de l'interface ISerializable pour permettre à une classe de contrôler son processus de sérialisation.
Utilisation de DataContractSerializer
Tous les types marqués avec l'attribut
[DataContract]doivent être publics. Les types non publics ne peuvent pas être sérialisés dans un environnement de confiance partielle.Tous les membres
[DataContract]dans un type[DataContract]sérialisable doivent être publics. Un type avec un[DataMember]non public ne peut pas être sérialisé dans un environnement de confiance partielle.Les méthodes qui gèrent des événements de sérialisation (telles que
OnSerializing,OnSerialized,OnDeserializingetOnDeserialized) doivent être déclarées comme publiques. Toutefois, les implémentations explicites et implicites de OnDeserialization(Object) sont prises en charge.Les types
[DataContract]implémentés dans les assemblys marqués avec AllowPartiallyTrustedCallersAttribute ne doivent pas effectuer d’actions relatives à la sécurité dans le constructeur de type, étant donné que DataContractSerializer n’appelle pas le constructeur de l’objet instancié récemment pendant la désérialisation. En particulier, les techniques de sécurité courantes suivantes doivent être évitées pour les types[DataContract]:Tenter de restreindre l'accès de confiance partielle en rendant le constructeur du type interne ou privé.
Restreindre l'accès au type en ajoutant un
[LinkDemand]au constructeur du type.Supposer que du fait de l'instanciation correcte de l'objet, les contrôles de validation appliqués par le constructeur ont réussi.
Utilisation de IXmlSerializable
Les meilleures pratiques suivantes s'appliquent aux types qui implémentent IXmlSerializable et sont sérialisés à l'aide du DataContractSerializer :
Les implémentations de méthode statique GetSchema doivent être
public.Les méthodes d'instance qui implémentent l'interface IXmlSerializable doivent être
public.
Utilisation de WCF à partir d’un code de plateforme d’un niveau de confiance suffisant qui autorise les appels d’appelants d’un niveau de confiance partiel
Le modèle de sécurité de confiance partielle WCF suppose que tout appelant d’une méthode ou propriété publique WCF s’exécute dans le contexte de sécurité d’accès du code (CAS) de l’application d’hébergement. WCF suppose également qu’un seul contexte de sécurité des applications existe pour chaque AppDomain, et que ce contexte est établi à l’heure de création AppDomain par un hôte approuvé (par exemple, par un appel à CreateDomain ou par le Gestionnaire d’applications ASP.NET).
Notes
La sécurité d’accès du code (CAS) a été déconseillée dans toutes les versions du .NET Framework et de .NET. Les versions récentes de .NET ne respectent pas les annotations CAS et produisent des erreurs si les API liées à CAS sont utilisées. Les développeurs doivent chercher d’autres moyens pour accomplir les tâches liées à la sécurité.
Ce modèle de sécurité s’applique aux applications écrites par l’utilisateur qui ne peuvent pas déclarer des autorisations CAS supplémentaires, telles que l’exécution du code utilisateur dans une application ASP.NET de confiance moyenne. Toutefois, le code de plateforme d’un niveau de confiance total (par exemple, un assembly tiers installé dans le cache d’assembly global et qui accepte des appels de code de niveau de confiance partiel) doit faire preuve de prudence lors de l’appel dans WCF au nom d’une application de confiance partielle pour éviter d’introduire des failles de sécurité au niveau de l’application.
Le code de confiance totale doit éviter de modifier le jeu d’autorisations CAS du thread actuel (en appelant la méthode Assert, PermitOnly ou Deny) avant d’appeler les API de WCF de la part du code d’un niveau de confiance partiel. La déclaration ou le refus, ou toute création d'un contexte d'autorisation spécifique au thread qui est indépendant du contexte de sécurité au niveau de l'application, peut entraîner un comportement imprévu. Selon l'application, ce comportement peut provoquer des failles de sécurité au niveau de l'application.
Le code qui appelle dans WCF à l’aide d’un contexte d’autorisation spécifique au thread doit être prêt à gérer les situations suivantes susceptibles de se produire :
Le contexte de sécurité spécifique au thread ne peut pas être maintenu pour la durée de l'opération, ce qui provoque des exceptions de sécurité potentielles.
Le code WCF interne et tous les rappels fournis par l’utilisateur, peuvent s’exécuter dans un contexte de sécurité différent de celui dans lequel l’appel a été initialisé à l’origine. Ces contextes sont les suivants :
Le contexte d'autorisation d'application.
Tout contexte d’autorisation spécifique au thread créé précédemment par d’autres threads utilisateur utilisés pour appeler dans WCF pendant la durée de vie du AppDomain en cours d’exécution.
WCF garantit que le code d’un niveau de confiance partiel ne peut pas obtenir des autorisations de confiance totale sauf si ces autorisations sont déclarées par un composant d’un niveau de confiance total avant d’appeler dans les API publiques de WCF. Toutefois, cela ne garantit pas que les effets de la déclaration de la confiance totale sont isolés d’un thread, d’une opération ou d’une action utilisateur en particulier.
La meilleure pratique consiste à éviter de créer le contexte d'autorisation spécifique au thread en appelant Assert, PermitOnly ou Deny. Au lieu de cela, accordez ou refusez le privilège à l'application, afin qu'aucune méthode Assert, Deny ou PermitOnly ne soit requise.