Bonnes pratiques en matière 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 du DataContractSerializer dans une application partiellement approuvée.

Tous les types sérialisables doivent être explicitement marqués avec l’attribut [DataContract] . Les techniques suivantes ne sont pas prises en charge dans un environnement d’approbation partielle :

• Marquer les classes à sérialiser avec le SerializableAttribute.
• 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 contexte 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 les événements de sérialisation (tels que OnSerializing, OnSerialized, OnDeserializing, et OnDeserialized) doivent être déclarées comme publiques. Toutefois, les implémentations explicites et implicites de OnDeserialization(Object) sont prises en charge.

• [DataContract] Les types implémentés dans des assemblies marqués avec AllowPartiallyTrustedCallersAttribute ne doivent pas effectuer des actions liées à la sécurité dans le constructeur de type, car DataContractSerializer n'appelle pas le constructeur de l'objet nouvellement instancié lors de la désérialisation. Plus précisément, 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.

• En supposant que, ayant réussi l'instanciation de l'objet, toutes les vérifications de validation imposées par le constructeur ont été réussies.

Utilisation d’IXmlSerializable

Les meilleures pratiques suivantes s’appliquent aux types qui implémentent IXmlSerializable et sont sérialisés à l’aide de DataContractSerializer.

• Les GetSchema implémentations de méthode statique 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 entièrement approuvé qui autorise les appels provenant d’appelants partiellement approuvés

Le modèle de sécurité de confiance partielle WCF suppose que tout appelant d'une méthode publique ou d'une propriété WCF fonctionne dans le contexte de sécurité d'accès au code (CAS) de l'application d'hébergement. WCF suppose également qu’un seul contexte de sécurité d’application existe pour chacun AppDomainet que ce contexte est établi au AppDomain moment de la création par un hôte approuvé (par exemple, par un appel à CreateDomain ou par le gestionnaire d’applications ASP.NET).

Ce modèle de sécurité s’applique aux applications écrites par l’utilisateur qui ne peuvent pas déclarer d’autorisations CAS supplémentaires, telles que le code utilisateur s’exécutant dans une application de confiance moyenne ASP.NET. Toutefois, le code de plateforme entièrement approuvé (par exemple, un assembly tiers installé dans le Global Assembly Cache et accepte les appels provenant de code partiellement approuvé) doit prendre des précautions explicites lors de l’appel à WCF pour le compte d’une application partiellement approuvée afin d’éviter d’introduire des vulnérabilités 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 Assert, PermitOnlyou Deny) avant d’appeler des API WCF pour le compte du code partiellement approuvé. L’assertion, le refus ou la création d’un contexte d’autorisation spécifique à un thread indépendant du contexte de sécurité au niveau de l’application peut entraîner un comportement inattendu. Selon l’application, ce comportement peut entraîner des vulnérabilités de sécurité au niveau de l’application.

Le code qui appelle WCF à l’aide d’un contexte d’autorisation spécifique au thread doit être préparé pour gérer les situations suivantes qui peuvent survenir :

• Le contexte de sécurité spécifique au thread peut ne pas être conservé pendant la durée de l’opération, ce qui entraîne 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 sous lequel l’appel a été lancé à l’origine. Ces contextes sont les suivants :

  • Contexte d’autorisation de l’application.

  • Tout contexte d’autorisation spécifique à un thread précédemment créé par d’autres threads utilisateur employés pour appeler dans WCF pendant la durée de vie de la AppDomain en cours d’exécution.

WCF garantit que le code partiellement approuvé ne peut pas obtenir d’autorisations de confiance totale, sauf si ces autorisations sont déclarées par un composant entièrement approuvé avant d’appeler des API publiques WCF. Toutefois, elle ne garantit pas que les effets de l’assertion d’une confiance totale sont isolés à un thread, une opération ou une action utilisateur particulière.

En guise de meilleure pratique, évitez de créer un contexte d’autorisation spécifique au thread en appelant Assert, PermitOnlyou Deny. Au lieu de cela, accordez ou refusez le privilège à l’application elle-même, de sorte qu’aucun Assert, Denyou PermitOnly n’est requis.

Voir aussi

• DataContractSerializer
• IXmlSerializable