Partager via

Recommandations en matière de codage sécurisé

La plupart du code d’application peut simplement utiliser l’infrastructure implémentée par .NET. Dans certains cas, une sécurité spécifique à l’application supplémentaire est requise, générée en étendant le système de sécurité ou en utilisant de nouvelles méthodes ad hoc.

À l’aide des autorisations appliquées par .NET et d’autres mesures de mise en œuvre dans votre code, vous devez ériger des barrières pour empêcher le code malveillant d’accéder aux informations que vous ne souhaitez pas qu’elles aient ou effectuent d’autres actions indésirables. En outre, vous devez trouver un équilibre entre la sécurité et la facilité d’utilisation dans tous les scénarios attendus à l’aide du code approuvé.

Cette vue d’ensemble décrit les différentes façons dont le code peut être conçu pour fonctionner avec le système de sécurité.

Sécurisation de l’accès aux ressources

Lors de la conception et de l’écriture de votre code, vous devez protéger et limiter l’accès dont le code a besoin pour les ressources, en particulier lors de l’utilisation ou de l’appel du code d’origine inconnue. Gardez donc à l’esprit les techniques suivantes pour vous assurer que votre code est sécurisé :

  • N’utilisez pas la sécurité d’accès au code (CAS).

  • N’utilisez pas de code approuvé partiel.

  • N’utilisez pas l’attribut AllowPartiallyTrustedCaller (APTCA).

  • N’utilisez pas la communication à distance .NET.

  • N’utilisez pas le modèle objet de composant distribué (DCOM).

  • N’utilisez pas de formateur binaire.

La sécurité d’accès au code et le code Security-Transparent ne sont pas pris en charge en tant que limite de sécurité avec du code partiellement approuvé. Nous vous conseillons de charger et d’exécuter du code d’origine inconnue sans mettre en place d’autres mesures de sécurité. Les autres mesures de sécurité sont les suivantes :

  • Virtualisation

  • AppContainers

  • Utilisateurs et autorisations du système d’exploitation

  • conteneurs Hyper-V

Code neutre pour la sécurité

Le code neutre de la sécurité ne fait rien d’explicite avec le système de sécurité. Il s’exécute avec les autorisations qu’il reçoit. Bien que les applications qui ne parviennent pas à intercepter les exceptions de sécurité associées aux opérations protégées (telles que l’utilisation de fichiers, de mise en réseau, etc.) peuvent entraîner une exception non gérée, le code neutre en matière de sécurité tire toujours parti des technologies de sécurité dans .NET.

Une bibliothèque neutre en matière de sécurité présente des caractéristiques spéciales que vous devez comprendre. Supposons que votre bibliothèque fournit des éléments d’API qui utilisent des fichiers ou appellent du code non managé. Si votre code n’a pas l’autorisation correspondante, il ne s’exécute pas comme décrit. Toutefois, même si le code dispose de l’autorisation, tout code d’application qui l’appelle doit avoir la même autorisation pour fonctionner. Si le code appelant ne dispose pas de l’autorisation appropriée, une SecurityException valeur apparaît à la suite de la procédure pas à pas de la pile de sécurité d’accès au code.

Code d’application qui n’est pas un composant réutilisable

Si votre code fait partie d’une application qui ne sera pas appelée par d’autres codes, la sécurité est simple et un codage spécial peut ne pas être nécessaire. Toutefois, n’oubliez pas que le code malveillant peut appeler votre code. Même si la sécurité de l’accès au code peut empêcher le code malveillant d’accéder aux ressources, ce code peut toujours lire les valeurs de vos champs ou propriétés susceptibles de contenir des informations sensibles.

En outre, si votre code accepte l’entrée utilisateur à partir d’Internet ou d’autres sources non fiables, vous devez être prudent sur les entrées malveillantes.

Wrapper managé vers l’implémentation de code natif

En règle générale, dans ce scénario, certaines fonctionnalités utiles sont implémentées dans le code natif que vous souhaitez mettre à la disposition du code managé. Les wrappers managés sont faciles à écrire à l’aide de l’appel de plateforme ou de l’interopérabilité COM. Toutefois, si vous procédez ainsi, les appelants de vos wrappers doivent disposer de droits de code non managés pour réussir. Dans la stratégie par défaut, cela signifie que le code téléchargé à partir d’un intranet ou internet ne fonctionne pas avec les wrappers.

Au lieu de donner des droits de code non managés à toutes les applications qui utilisent ces wrappers, il est préférable de ne donner ces droits qu’au code wrapper. Si la fonctionnalité sous-jacente n’expose aucune ressource et que l’implémentation est également sécurisée, le wrapper doit uniquement affirmer ses droits, ce qui permet à tout code de l’appeler. Lorsque des ressources sont impliquées, le codage de sécurité doit être identique au cas de code de la bibliothèque décrit dans la section suivante. Étant donné que le wrapper expose potentiellement des appelants à ces ressources, une vérification minutieuse de la sécurité du code natif est nécessaire et est la responsabilité du wrapper.

Code de bibliothèque qui expose les ressources protégées

L’approche suivante est la plus puissante et donc potentiellement dangereuse (si elle est effectuée incorrectement) pour le codage de sécurité : votre bibliothèque sert d’interface pour d’autres codes pour accéder à certaines ressources qui ne sont pas autrement disponibles, tout comme les classes .NET appliquent des autorisations pour les ressources qu’elles utilisent. Chaque fois que vous exposez une ressource, votre code doit d’abord demander l’autorisation appropriée à la ressource (autrement dit, elle doit effectuer une vérification de sécurité), puis affirmer ses droits pour effectuer l’opération réelle.

Voir aussi