Partager via

Considérations relatives à la sécurité pour la réflexion

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 restreinte. Tout le code peut utiliser la réflexion pour effectuer les tâches suivantes :

  • Énumérez les types et les membres, puis examinez leurs métadonnées.
  • Énumérez et examinez les assemblages et les modules.

En revanche, l'utilisation de la réflexion pour accéder aux membres est soumise à des restrictions. À compter du .NET Framework 4, seul le code approuvé peut utiliser la réflexion pour accéder aux membres cruciaux pour la sécurité. En outre, seul le code approuvé peut utiliser la réflexion pour accéder aux membres non publics qui ne seraient pas directement accessibles au code compilé. Enfin, le code qui utilise la réflexion pour accéder à un membre critique sécurisé doit disposer des autorisations requises par le membre critique sécurisé, tout comme avec le code compilé.

Sous réserve des autorisations nécessaires, le code peut utiliser la réflexion pour effectuer les types d’accès suivants :

  • Accédez aux membres publics qui ne représentent pas un risque critique pour la sécurité.

  • Accédez aux membres non publics qui seraient accessibles au code compilé, si ces membres ne sont pas critiques pour la sécurité. Voici quelques exemples de ces membres non publics :

    • Membres protégés des classes de base du code appelant. (En réflexion, il s’agit d’un accès au niveau de la famille.)

    • membres internal ( membres Friend dans Visual Basic) dans l’assembly du code d’appel. (Dans la réflexion, ceci s'appelle 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 en bac à sable est limité à l’accès décrit dans cette liste, sauf si le domaine d’application accorde des autorisations supplémentaires.

À compter de .NET Framework 2.0 Service Pack 1, le fait de tenter d’accéder à des membres normalement inaccessibles génère une demande du 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, du code dans une application lancée à partir de la ligne de commande) peut toujours satisfaire ces autorisations. (Ceci est soumis à des limitations d’accès aux membres critiques de sécurité, comme décrit plus loin dans cet article.)

Si vous le souhaitez, un domaine d’application en bac à sable peut accorder ReflectionPermission avec l’indicateur ReflectionPermissionFlag.MemberAccess , comme décrit dans la section Accès aux membres normalement inaccessibles, plus loin dans cet article.

Accès aux membres critiques de sécurité

Un membre est critique du point de vue de la sécurité s'il a l'attribut SecurityCriticalAttribute, s'il appartient à un type qui a l'attribut SecurityCriticalAttribute ou s'il est dans un assembly critique du point de vue de la sécurité. À compter du .NET Framework 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 est d'un niveau de confiance total. Une exception MethodAccessException, FieldAccessException ou TypeAccessException est levée.

  • Le code qui s’exécute avec une approbation partielle est traité comme transparent.

Ces règles sont les mêmes si l'accès à un membre critique du point de vue de la sécurité se fait directement par du code compilé ou en utilisant 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 approbation partielle (par exemple, dans un domaine d’application en bac à sable) le niveau d’approbation de l’assembly détermine s’il peut accéder au code critique de sécurité : si l’assembly a un nom fort et est installé dans le Global Assembly Cache, il s’agit d’un assembly approuvé et peut appeler des membres critiques de sécurité. Si elle n'est pas de confiance, il devient transparent même s'il n'était pas marqué comme tel, et il ne peut pas accéder aux membres critiques de sécurité.

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 d’approbation de l’assembly et le niveau d’approbation du domaine d’application. La réflexion fournit les propriétés IsSecurityCritical, IsSecuritySafeCritical et IsSecurityTransparent pour vous permettre de découvrir le niveau de transparence d’un type. Le tableau suivant présente les combinaisons valides de ces propriétés.

Niveau de sécurité IsSecurityCritical IsSecuritySafeCritical IsSecurityTransparent
Essentiel true false false
Critique sécurisé true true false
Transparent false false true

L’utilisation de ces propriétés est beaucoup plus simple que d’examiner les annotations de sécurité d’un assembly et de ses types, de vérifier le niveau d’approbation actuel et de tenter de dupliquer les règles du runtime. Par exemple, le même type peut être critique pour la sécurité lorsqu’il est exécuté à partir de la ligne de commande ou transparent en matière de sécurité lorsqu’il est exécuté dans un domaine d’application en bac à sable (sandbox).

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

Accès aux membres qui sont normalement inaccessibles

Pour utiliser la réflexion pour appeler des membres inaccessibles en fonction des règles d’accessibilité du Common Language Runtime, votre code doit disposer de l’une des deux autorisations suivantes :

  • 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 autoriser le code à appeler n'importe quel membre non public, tant que l'ensemble d'autorisations de l'assembly contenant le membre appelé est identique à ou est un sous-ensemble de l'ensemble d'autorisations de l'assembly contenant le code appelant : votre code doit recevoir ReflectionPermission avec le drapeau ReflectionPermissionFlag.RestrictedMemberAccess.

Par exemple, supposons que vous accordiez des autorisations Internet à un domaine d'application plus ReflectionPermission avec l'indicateur ReflectionPermissionFlag.RestrictedMemberAccess, puis exécutez une application Internet avec deux assemblies, 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 pas d'autorisations qui n'ont pas été accordées à A.

  • L’assembly A ne peut pas utiliser la réflexion pour accéder aux membres privés des assemblies .NET Framework tels que mscorlib.dll, car mscorlib.dll est entièrement approuvé et dispose donc des autorisations qui n’ont pas été accordées à l’assembly A. Une exception MemberAccessException est levée lorsque la sécurité de l'accès au code analyse 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 des 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. (En plus d’accorder les autorisations appropriées, le type doit être marqué comme sérialisable dans les métadonnées.)

Paramètres de Type MethodInfo

Évitez d'écrire des membres publics qui prennent des paramètres MethodInfo, en particulier pour du code de confiance. Ces membres peuvent être plus vulnérables au code malveillant. Par exemple, considérez un membre public dans du code hautement fiable qui prend le paramètre MethodInfo. Supposons que le membre public appelle indirectement la Invoke méthode sur le paramètre fourni. Si le membre public n’effectue pas les vérifications d’autorisation nécessaires, l’appel à la Invoke méthode réussit toujours, car le système de sécurité détermine que l’appelant est hautement approuvé. Même si le code malveillant n’a pas l’autorisation d’appeler directement la méthode, il peut toujours le faire indirectement en appelant le membre public.

Informations sur la version

  • À compter de .NET Framework 4, le code transparent ne peut pas utiliser la réflexion pour accéder aux membres critiques de sécurité.

  • L’indicateur ReflectionPermissionFlag.RestrictedMemberAccess est introduit dans .NET Framework 2.0 Service Pack 1. Les versions antérieures du .NET Framework exigent 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 au code partiellement approuvé.

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

Voir aussi

  • Last updated on