Code non managé
Mise à jour : novembre 2007
Du code de bibliothèque doit appeler dans du code non managé (par exemple, des API de code natif comme Win32). Comme cela signifie pour le code managé sortir du périmètre de sécurité, la prudence est de règle. S'il ne dépend pas de la sécurité, votre code ainsi que n'importe quel code qui l'appelle doit disposer de l'autorisation de code non managé (SecurityPermission avec l'indicateur UnmanagedCode spécifié).
Cependant, il n'est pas recommandé le plus souvent que votre appelant possède des autorisations aussi puissantes. Dans ces cas-là, votre code fiable peut servir d'intermédiaire de la même manière que le wrapper managé ou le code de bibliothèque décrit dans Sécurisation du code wrapper. Si les fonctionnalités de code non managé sous-jacentes sont totalement sécurisées, elles risquent d'être exposées directement ; si cela n'est pas le cas, une vérification d'autorisation appropriée (demande) est nécessaire dans un premier temps.
Lorsque votre code appelle dans du code non managé mais que vous ne souhaitez pas que vos appelants soient obligés d'avoir l'autorisation d'accéder à du code non managé, vous devez déclarer ce droit. Une assertion bloque le parcours de la pile à votre frame. Vous devez faire attention à ne pas créer de faille de sécurité lors de ce processus. Habituellement, cela signifie que vous devez exiger une autorisation appropriée de vos appelants puis vous servir du code non managé pour effectuer uniquement ce que cette autorisation permet et rien de plus. Dans certains cas (par exemple, une fonction définissant l'heure du jour), du code non managé peut être directement exposé aux appelants sans vérification de la sécurité. Dans tous les cas, tout code qui déclare doit être responsable de la sécurité.
Comme tout code managé qui fournit un chemin de code dans le code natif est une cible potentielle pour du code nuisible, déterminer le type de code non managé qui peut s'utiliser sans risque et la manière de l'utiliser nécessite beaucoup de précautions. Généralement, il ne faut jamais exposer du code non managé directement à des appelants d'un niveau de confiance partiel. Deux considérations principales gouvernent l'évaluation de la sécurité du code non managé utilisé dans des bibliothèques pouvant être appelées par du code d'un niveau de confiance partiel :
Fonctionnalité. Est-ce que l'API non managée fournit des fonctionnalités qui ne permettent pas aux appelants d'effectuer des opérations potentiellement risquées ? La sécurité d'accès du code utilise des autorisations pour faire appliquer l'accès aux ressources, il vous faut donc envisager si l'API utilise des fichiers, une interface utilisateur ou des technologies de threads ou si elle expose des informations protégées. Si tel est le cas, le code managé qui l'englobe doit exiger les autorisations nécessaires avant d'autoriser son entrée. De plus, même s'il ne fait pas l'objet d'une protection par autorisation, l'accès à la mémoire doit se limiter à la sécurité stricte des types.
Vérification des paramètres. Une attaque courante passe des paramètres inattendus à des méthodes API de code non managé exposées dans le but de les faire fonctionner hors spécification. Le dépassement de la mémoire tampon utilisant des index non valides ou des valeurs offset constitue un exemple courant de ce type d'attaque de même que tous les paramètres qui risquent d'exploiter une bogue dans le code sous-jacent. Ainsi, même si l'API du code non managé est sécurisée du point de vue fonctionnel (après des demandes nécessaires) pour des appelants d'un niveau de confiance partiel, le code managé doit également vérifier la validité des paramètres de manière exhaustive pour garantir qu'aucun appel involontaire n'est possible par du code nuisible utilisant la couche wrapper du code managé.