Considérations sur la sécurité de la réflexion

Article
08/21/2008

Mise à jour : novembre 2007

La réflexion permet d'obtenir des informations sur les types et les membres, et d'accéder aux membres. L'accès à des membres non publics pourrait créer un risque au niveau de la sécurité. Par conséquent, le code qui accède à des membres non publics requiert ReflectionPermission avec les indicateurs appropriés. De plus, SecurityPermission est requis pour certaines tâches, telles que l'apport de preuve, l'exécution de code non managé et la sérialisation d'objets.

Tout code peut utiliser la réflexion pour effectuer les tâches suivantes sans autorisation :

Énumérer les types et les membres, et examiner leurs métadonnées.
Énumérer et examiner les assemblys et les modules.
Accéder aux membres publics.
Accéder aux membres protected des classes de base du code appelant. (Dans la réflexion, il s'agit de l'accès au niveau de la famille.)
Accéder aux membres internal (membresFriend dans Visual Basic) dans l'assembly du code appelant. (Dans la réflexion, il s'agit de l'accès au niveau de l'assembly.)

Accès aux membres non publics

Pour utiliser la réflexion pour appeler des membres inaccessibles d'après les règles d'accessibilité du Common Language Runtime, l'une des deux autorisations suivantes doit être accordée à votre code :

Pour permettre au code d'appeler un membre non public : ReflectionPermission avec l'indicateur ReflectionPermissionFlag.MemberAccess.

Remarque :
Par défaut, la stratégie de sécurité refuse cette autorisation au code provenant d'Internet. Cette autorisation ne doit jamais être accordée au code provenant d'Internet.

Pour permettre au code d'appeler un membre non public, sous réserve que le jeu d'autorisations de l'assembly qui contient le membre appelé soit un sous-ensemble ou soit identique au jeu d'autorisations de l'assembly qui contient le code appelant : ReflectionPermission avec l'indicateur ReflectionPermissionFlag.RestrictedMemberAccess.

Par exemple, supposons que vous accordez des autorisations Internet à un domaine d'application plus ReflectionPermission avec l'indicateur ReflectionPermissionFlag.RestrictedMemberAccess, et que vous exécutez une application Internet avec deux assemblys, A et B.

L'assembly A peut utiliser la réflexion pour accéder aux membres privés de l'assembly B, car le jeu d'autorisations de l'assembly B n'inclut aucune autorisation qui n'ait pas été accordée à A.
L'assembly A ne peut pas utiliser la réflexion pour accéder aux membres privés des assemblys du .NET Framework tels que mscorlib.dll, car mscorlib.dll est d'un niveau de confiance suffisant et dispose par conséquent d'autorisations qui n'ont pas été accordées à l'assembly A. Une MemberAccessException est levée lorsque la sécurité d'accès du code parcourt la pile au moment de l'exécution.

Pour obtenir un exemple de domaine d'application en bac à sable (sandbox) qui accorde ReflectionPermission avec l'indicateur ReflectionPermissionFlag.RestrictedMemberAccess, consultez Procédure pas à pas : émission de code dans des scénarios de confiance partielle.

Sérialisation

Pour la sérialisation, SecurityPermission avec l'indicateur SecurityPermissionAttribute.SerializationFormatter offre la possibilité d'obtenir et de définir les membres de types sérialisables, indépendamment de l'accessibilité. Cette autorisation permet au code de découvrir et de modifier l'état privé d'une instance. Outre le fait de disposer des autorisations appropriées, le type doit être marqué comme Serializable dans les métadonnées.

Vérifications des demandes de liens

Si une méthode ou un délégué possède LinkDemand pour l'autorisation P, le runtime effectue une vérification de demande de lien par rapport à l'appelant de la méthode ou du délégué, afin de vérifier qu'il dispose de l'autorisation P. Cette vérification est effectuée aussi bien pour la découverte des informations de type que pour les appels.

Éviter de créer des paramètres de type MethodInfo

Il est déconseillé d'écrire des API publiques qui utilisent les paramètres MethodInfo, en particulier pour du code d'un niveau de confiance élevé. Ces API peuvent être plus vulnérables au code malveillant. Par exemple, imaginons qu'une API publique dans du code d'un niveau de confiance élevé utilise un paramètre MethodInfo. Supposons que cette API publique appelle indirectement la méthode Invoke sur le paramètre fourni. Si l'API publique n'effectue pas les vérifications d'autorisations nécessaires, l'appel à la méthode Invoke n'échoue jamais, car le système de sécurité détermine que le niveau de confiance de l'appelant est élevé. Même si un code nuisible n'a pas l'autorisation d'appeler directement la méthode, il peut toujours le faire indirectement, en appelant l'API publique.

Informations de version

L'indicateur ReflectionPermissionFlag.RestrictedMemberAccess est présenté dans .NET Framework version 2.0 Service Pack 1. Les versions antérieures du .NET Framework requièrent l'indicateur ReflectionPermissionFlag.MemberAccess pour le code qui utilise la réflexion pour accéder aux membres non publics. Il s'agit d'une autorisation qui ne doit jamais être accordée à un code d'un niveau de confiance partiel.

Remarque :
Pour utiliser l'indicateur ReflectionPermissionFlag.RestrictedMemberAccess, votre application doit cibler le .NET Framework version 3.5. Pour plus d'informations, consultez Architecture de .NET Framework 3.5.

À compter de .NET Framework 2.0, l'utilisation de la réflexion pour obtenir des informations sur les types et les membres non publics ne requiert aucune autorisation. Dans les versions antérieures, ReflectionPermission avec l'indicateur ReflectionPermissionFlag.TypeInformation est requis.