Sécurisation de l'accès à la méthode
Mise à jour : novembre 2007
Il est possible que certaines méthodes ne conviennent pas à l'appel par du code arbitraire non fiable. Ces méthodes présentent plusieurs risques : la méthode peut fournir des informations restreintes ; elle peut croire aux informations qui lui sont passées ; elle peut ne pas faire de vérification d'erreurs sur les paramètres ; ou dans le cas de paramètres erronés, la méthode peut dysfonctionner ou avoir des effets préjudiciables. Vous devez connaître ces cas et adopter la bonne marche à suivre afin de sécuriser la méthode.
Dans certains cas, il vous faudra peut-être limiter les méthodes qui ne sont pas destinées à une utilisation publique, mais qui doivent cependant être publiques. Par exemple, dans le cas d'une interface qui doit être appelée sur vos DLL, d'où la nécessité qu'elle soit publique, celle-ci ne doit pas toutefois être exposée de manière publique afin d'empêcher son utilisation par des clients ou d'empêcher l'exploitation par du code nuisible du point d'entrée dans votre composant. Une autre raison courante de limiter une méthode qui n'est pas destinée à une utilisation publique (mais qui doit être publique) est d'éviter d'avoir à documenter et prendre en charge une interface qui peut se révéler très interne.
Le code managé propose plusieurs façons de limiter l'accès à la méthode :
Limitez l'étendue de l'accessibilité à la classe, à l'assembly ou aux classes dérivées, s'ils sont de confiance. C'est la méthode la plus simple permettant de limiter l'accès à la méthode. Notez que, en général, les classes dérivées peuvent être moins fiables que la classe dont elles dérivent, même si dans certains cas elles partagent l'identité de la classe parente. En particulier, ne déduisez pas un niveau de confiance de la part du mot clé protected qui ne s'utilise pas nécessairement dans le contexte de sécurité.
Limitez l'accès à la méthode aux appelants d'une identité spécifiée -- essentiellement, n'importe quelle preuve particulière (nom fort, éditeur, zone, etc.) que vous choisissez.
Limitez l'accès à la méthode aux appelants dont les autorisations correspondent à celles que vous choisissez.
De même, la sécurité déclarative vous permet de contrôler l'héritage de classes. Vous pouvez utiliser InheritanceDemand pour effectuer les opérations suivantes :
Obliger des classes dérivées à posséder une identité ou une autorisation spécifiée.
Obliger des classes dérivées qui substituent des méthodes spécifiques à posséder une identité ou une autorisation spécifiée.
L'exemple suivant montre comment sécuriser une classe public pour un accès limité en exigeant que les appelants soient signés avec un nom fort particulier. Cet exemple utilise la StrongNameIdentityPermissionAttribute avec Demand comme nom fort. Pour des informations basées sur des tâches sur la manière de signer un assembly avec un nom fort, consultez Création et utilisation d'assemblys avec nom fort.
<StrongNameIdentityPermissionAttribute(SecurityAction.Demand, PublicKey := "…hex…", Name := "App1", Version := "0.0.0.0")> _
Public Class Class1
End Class
[StrongNameIdentityPermissionAttribute(SecurityAction.Demand, PublicKey="…hex…", Name="App1", Version="0.0.0.0")]
public class Class1
{
}