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

Article
08/10/2011

La réflexion permet d'obtenir des informations sur les types et les membres, et d'accéder aux membres (autrement dit, d'appeler des méthodes et des constructeurs, d'obtenir et de définir des valeurs de propriété, d'ajouter et de supprimer des gestionnaires d'événements, etc.). L'utilisation de la réflexion pour obtenir des informations sur les types et les membres n'est pas limitée. Tout code peut utiliser la réflexion pour effectuer les tâches suivantes :

Énumérer les types et les membres, et examiner leurs métadonnées.
Énumérer et examiner les assemblys et les modules.

Par opposition, l'utilisation de la réflexion pour accéder aux membres est soumise à des restrictions. En commençant par le .NET Framework version 4, seul du code de confiance peut utiliser la réflexion pour accéder aux membres critiques de sécurité. En outre, seul du code de confiance peut utiliser la réflexion pour accéder aux membres non publics qui ne seraient pas directement accessibles à du code compilé. Enfin, le code qui utilise la réflexion pour accéder à un membre critique sécurisé doit avoir les autorisations que le membre critique sécurisé exige, tout comme avec le code compilé.

Soumis aux autorisations nécessaires, le code peut utiliser la réflexion pour effectuer les genres d'accès suivants :

Accès aux membres publics qui ne sont pas critiques de sécurité.
Accès aux membres non publics qui seraient accessibles à du code compilé, si ces membres ne sont pas critiques de sécurité. Voici des exemples de ces membres non publics :
- Membres protégés des classes de base du code appelant. (Dans la réflexion, il s'agit de l'accès au niveau de la famille.)
- Membres internal (membres Friend 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.)
- Membres privés d'autres instances de la classe qui contient le code appelant.

Par exemple, le code exécuté dans un domaine d'application sandbox est limité aux accès décrits dans la liste, sauf si le domaine d'application accorde d'autres autorisations.

À compter du .NET Framework version 2.0 Service Pack 1, toute tentative d'accès à des membres normalement inaccessibles génère une demande pour le jeu d'autorisations de l'objet cible plus ReflectionPermission avec l'indicateur ReflectionPermissionFlag.MemberAccess. Le code qui s'exécute avec une confiance totale (par exemple, le code d'une application lancée à partir de la ligne de commande) peut toujours satisfaire à ces autorisations. (Ceci est soumis aux limitations d'accès aux membres critiques de sécurité, comme décrit ultérieurement dans cet article.)

À titre facultatif, un domaine d'application sandbox peut accorder ReflectionPermission avec l'indicateur ReflectionPermissionFlag.MemberAccess, comme décrit dans la section Accès aux membres normalement inaccessibles, ultérieurement dans cet article.

Accès aux membres critiques de sécurité

Un membre est critique de sécurité s'il possède le SecurityCriticalAttribute, s'il appartient à un type qui possède le SecurityCriticalAttribute ou s'il figure dans un assembly critique de sécurité. À partir du .NET Framework version 4, les règles d'accès aux membres critiques de sécurité sont les suivantes :

Le code transparent ne peut pas utiliser la réflexion pour accéder aux membres critiques de sécurité, même si le code possède un niveau de confiance totale. Une exception MethodAccessException, FieldAccessException ou TypeAccessException est levée.
Du code qui s'exécute avec une confiance partielle est considéré comme étant transparent.

Ces règles sont les mêmes si un membre critique de sécurité fait l'objet d'accès direct par du code compilé ou par le biais de la réflexion.

Le code d'application exécuté à partir de la ligne de commande s'exécute avec une confiance totale. Tant qu'il n'est pas marqué comme transparent, il peut utiliser la réflexion pour accéder aux membres critiques de sécurité. Lorsque le même code est exécuté avec une confiance partielle (par exemple, dans un domaine d'application sandbox), le niveau de confiance de l'assembly détermine s'il peut accéder à du code critique de sécurité. Si l'assembly possède un nom fort et est installé dans le Global Assembly Cache, il s'agit d'un assembly fiable qui peut appeler des membres critiques de sécurité. S'il n'est pas fiable, il devient transparent même s'il n'a pas été marqué comme transparent, et il ne peut pas accéder aux membres critiques de sécurité.

Pour plus d'informations sur le modèle de sécurité du .NET Framework 4, consultez Modifications de sécurité dans le .NET Framework 4.

Réflexion et transparence

À compter du .NET Framework 4, le Common Language Runtime détermine le niveau de transparence d'un type ou d'un membre à partir de plusieurs facteurs, notamment le niveau de confiance de l'assembly et le niveau de confiance du domaine d'application. La réflexion fournit les propriétés IsSecurityCritical, IsSecuritySafeCritical et IsSecurityTransparent pour vous permettre de connaître le niveau de transparence d'un type. Les combinaisons valides pour ces propriétés sont répertoriées dans le tableau suivant.

Niveau de Sécurité	IsSecurityCritical	IsSecuritySafeCritical	IsSecurityTransparent
Critical	true	false	false
Critique de sécurité	true	true	false
Transparent	false	false	true

Il est beaucoup plus simple d'utiliser ces propriétés que d'examiner les annotations de sécurité d'un assembly et de ses types, de vérifier le niveau de confiance actuel ou de tenter de dupliquer les règles de runtime. Par exemple, le même type peut être critique de sécurité lorsqu'il est exécuté à partir de la ligne de commande, et transparent de sécurité lorsqu'il est exécuté dans un domaine d'application sandbox.

Il existe des propriétés similaires pour les classes MethodBase, FieldInfo, TypeBuilder, MethodBuilder et DynamicMethod. (Pour les autres abstractions de réflexion et d'émission de réflexion, les attributs de sécurité sont appliqués aux méthodes associées. Par exemple, dans le cas de propriétés, ils sont appliqués aux accesseurs de propriété.)

Accès aux membres normalement inaccessibles

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, votre code doit disposer de l'autorisation 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, votre code doit disposer de l'autorisation ReflectionPermission avec l'indicateur ReflectionPermissionFlag.RestrictedMemberAccess.

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.

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 exception MemberAccessException est levée lorsque la sécurité d'accès du code parcourt la pile au moment de l'exécution.

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.

Paramètres de type MethodInfo

Il est déconseillé d'écrire des membres publics qui utilisent les paramètres MethodInfo en particulier pour du code d'un niveau de confiance élevé. Ces membres peuvent être plus vulnérables au code malveillant. Par exemple, imaginons qu'un membre public dans du code d'un niveau de confiance élevé utilise un paramètre MethodInfo. Supposons que ce membre public appelle indirectement la méthode Invoke sur le paramètre fourni. Si le membre public 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 le membre public.

Informations de version

À partir du .NET Framework version 4, le code transparent ne peut pas utiliser la réflexion pour accéder à des membres critiques de sécurité.
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.
À 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.