Vue d'ensemble du codage sécurisé
Cette section fournit une vue d'ensemble des différents procédés utilisés pour concevoir du code afin qu'il fonctionne avec le système de sécurité.
Code indépendant de la sécurité
Le code indépendant de la sécurité ne fait rien d'explicite avec le système de sécurité. Il s'exécute quelles que soient les autorisations qu'il reçoit. Bien que des applications qui ne parviennent pas à intercepter les exceptions de sécurité associées à des opérations protégées (comme l'utilisation de fichiers, la mise en réseau etc.) puissent engendrer une exception non gérée, le code indépendant de la sécurité tire néanmoins parti des technologies de la sécurité du .NET Framework.
Une bibliothèque indépendante de la sécurité possède des caractéristiques particulières que vous devez connaître. Supposons que votre bibliothèque fournisse des éléments d'API qui utilisent des fichiers ou appellent du code non managé ; si votre code ne possède pas l'autorisation correspondante, il ne s'exécutera pas comme décrit. Cependant, même si le code possède l'autorisation, n'importe quel code d'application qui l'appelle doit avoir la même autorisation afin de fonctionner. Si le code appelant ne possède pas la bonne autorisation, une exception SecurityException apparaît suite au parcours de pile de la sécurité d'accès du code.
Code d'application ne correspondant pas à un composant réutilisable
Si votre code fait partie d'une application qui ne sera pas appelée par un autre code, la sécurité est simple et un codage spécial n'est sans doute pas nécessaire. Cependant, n'oubliez pas que du code nuisible peut appeler votre code. Si la sécurité d'accès du code peut empêcher le code nuisible d'accéder à des ressources, ce type de code est toutefois capable de lire les valeurs de vos champs ou propriétés susceptibles de contenir des informations confidentielles.
De plus, si votre code accepte des entrées de l'utilisateur à partir d'Internet ou d'autres sources peu fiables, vous devez vous méfier des entrées malveillantes.
Implémentation de wrapper managé vers du code natif
Dans ce scénario, certaines fonctionnalités utiles sont généralement implémentées dans du code natif que vous voulez mettre à disposition du code managé. Les wrappers managés sont faciles à écrire à l'aide soit de l'appel de plate-forme, soit de COM Interop. Toutefois, si vous le faites, les appelants de vos wrappers doivent avoir des droits de code non managé pour que l'opération réussisse. Dans le cadre de la stratégie par défaut, cela signifie que le code téléchargé depuis un intranet ou Internet ne fonctionnera pas avec les wrappers.
Au lieu d'accorder des droits de code non managé à toutes les applications qui utilisent ces wrappers, il est préférable d'accorder ces droits uniquement au code wrapper. Si les fonctionnalités sous-jacentes n'exposent aucune ressource et que l'implémentation est également « sécurisée », le wrapper doit simplement déclarer ses droits, ce qui permet à n'importe quel code d'effectuer un appel via celui-ci. Lorsque des ressources sont concernées, le codage de sécurité doit être le même que le cas de code de bibliothèque décrit dans la section suivante. Comme le wrapper expose potentiellement les appelants à ces ressources, une vérification minutieuse de la sécurité du code natif est nécessaire, ce qui relève de la responsabilité du wrapper.
Code de bibliothèque exposant des ressources protégées
Il s'agit de l'approche la plus puissante et donc potentiellement risquée (si elle n'est pas exécutée correctement) pour le codage de sécurité : votre bibliothèque sert d'interface permettant à un autre code d'accéder à certaines ressources qui ne sont pas autrement disponibles, tout comme les classes du .NET Framework appliquent des autorisations pour les ressources qu'elles utilisent. Quel que soit l'emplacement où vous exposez une ressource, votre code doit en premier lieu demander l'autorisation appropriée à la ressource (c'est-à-dire effectuer une vérification de sécurité), puis généralement déclarer ses droits lui permettant d'effectuer l'opération proprement dite.