CA2107 : Passez en revue l'utilisation des méthodes Deny et PermitOnly

  • Article
Élément Valeur
ID de la règle CA2107
Category Microsoft.Security
Modification avec rupture Rupture

Cause

Une méthode contient une vérification de sécurité qui spécifie l’action de sécurité PermitOnly ou Deny.

Notes

Cette règle est déconseillée. Pour plus d’informations, consultez Règles dépréciées.

Description de la règle

L’action de sécurité System.Security.CodeAccessPermission.Deny doit être utilisée uniquement par des personnes ayant une connaissance avancée de la sécurité .NET. Le code qui utilise ces actions de sécurité doit subir une révision de sécurité.

L’action Deny modifie le comportement par défaut du parcours de pile qui se produit en réponse à une demande de sécurité. Elle vous permet de spécifier des autorisations qui ne doivent pas être accordées durant l’application de la méthode de refus, quelles que soient les autorisations réelles des appelants dans la pile des appels. Si le parcours de pile détecte une méthode sécurisée par Deny et si l’autorisation demandée est incluse dans les autorisations refusées, le parcours de pile échoue. L’action PermitOnly modifie également le comportement par défaut du parcours de pile. Elle permet au code de spécifier uniquement les autorisations qui peuvent être accordées, quelles que soient les autorisations des appelants. Si le parcours de pile détecte une méthode sécurisée par PermitOnly et si l’autorisation demandée n’est pas incluse dans les autorisations spécifiées par PermitOnly, le parcours de pile échoue.

Les failles de sécurité potentielles dans le code qui s’appuie sur ces actions doivent être rigoureusement évaluées. En effet, leur comportement est subtil et leur utilité limitée. Tenez compte des éléments suivants :

  • Les demandes de liaison ne sont pas affectées par les actions Deny et PermitOnly.

  • Si une action Deny ou PermitOnly se produit dans le même frame de pile que la demande qui entraîne le parcours de pile, les actions de sécurité n’ont aucun effet.

  • Les valeurs utilisées pour construire des autorisations basées sur des chemins peuvent généralement être spécifiées de plusieurs façons. Un refus d’accès à une forme du chemin ne signifie pas que l’accès à toutes les formes sera refusé. Par exemple, si un partage de fichiers \\Serveur\Partage est mappé à un lecteur réseau X:, pour refuser l’accès à un fichier sur le partage, vous devez refuser \\Serveur\Partage\Fichier, X:\Fichier et tous les autres chemins d’accès au fichier.

  • Un System.Security.CodeAccessPermission.Assert peut mettre fin à un parcours de pile avant que l’action Deny ou PermitOnly soit atteinte.

  • Si une action Deny a un effet (c’est-à-dire quand un appelant a une autorisation bloquée par l’action Deny), l’appelant peut accéder directement à la ressource protégée en contournant l’action Deny. De même, si l’autorisation de l’appelant n’est pas refusée, le parcours de pile échoue sans l’action Deny.

Comment corriger les violations

Toute utilisation de ces actions de sécurité entraîne une violation. Pour corriger une violation, n’utilisez pas ces actions de sécurité.

Quand supprimer les avertissements

Supprimez un avertissement de cette règle uniquement après une revue de sécurité minutieuse.

Exemple 1

L’exemple suivant illustre certaines limitations de l’action Deny. La bibliothèque contient une classe qui a deux méthodes qui ne diffèrent que par les demandes de sécurité qui les protègent.

using System.Security;
using System.Security.Permissions;
using System;

namespace SecurityRulesLibrary
{
   public  class SomeSecuredMethods
   {
    
      // Demand immediate caller has suitable permission
      // before revealing sensitive data.
      [EnvironmentPermissionAttribute(SecurityAction.LinkDemand,
          Read="COMPUTERNAME;USERNAME;USERDOMAIN")]

      public static void MethodProtectedByLinkDemand()
      {
         Console.Write("LinkDemand: ");
      }

      [EnvironmentPermissionAttribute(SecurityAction.Demand,
          Read="COMPUTERNAME;USERNAME;USERDOMAIN")]

      public static void MethodProtectedByDemand()
      {
         Console.Write("Demand: ");
      }
   }
}

Exemple 2

L’application suivante illustre les effets de l’action Deny sur les méthodes sécurisées de la bibliothèque.

using System.Security;
using System.Security.Permissions;
using System;
using SecurityRulesLibrary;

namespace TestSecurityLibrary
{
    // Violates rule: ReviewDenyAndPermitOnlyUsage.
   public class TestPermitAndDeny
   {
      public static void TestAssertAndDeny()
      {
         EnvironmentPermission envPermission = new EnvironmentPermission(
               EnvironmentPermissionAccess.Read,
               "COMPUTERNAME;USERNAME;USERDOMAIN");
         envPermission.Assert();
         try
         {
            SomeSecuredMethods.MethodProtectedByDemand();
            Console.WriteLine(
               "Caller's Deny has no effect on Demand " + 
               "with the asserted permission.");

            SomeSecuredMethods.MethodProtectedByLinkDemand();
            Console.WriteLine(
               "Caller's Deny has no effect on LinkDemand " + 
               "with the asserted permission.");
         }
         catch (SecurityException e)
         {
            Console.WriteLine(
               "Caller's Deny protected the library.{0}", e);
         }
      }

      public static void TestDenyAndLinkDemand()
      {
         try
         {
            SomeSecuredMethods.MethodProtectedByLinkDemand();
            Console.WriteLine(
               "Caller's Deny has no effect with " +
               "LinkDemand-protected code.");
         }
         catch (SecurityException e)
         {
            Console.WriteLine(
               "Caller's Deny protected the library.{0}",e);
         }
      }
         
      public static void Main()
      {
         EnvironmentPermission envPermission = new EnvironmentPermission(
            EnvironmentPermissionAccess.Read,
            "COMPUTERNAME;USERNAME;USERDOMAIN");
         envPermission.Deny();

         //Test Deny and Assert interaction for LinkDemands and Demands.
         TestAssertAndDeny();

         //Test Deny's effects on code in different stack frame. 
         TestDenyAndLinkDemand();

         //Test Deny's effect on code in same frame as deny.
         try
         {
            SomeSecuredMethods.MethodProtectedByLinkDemand();
            Console.WriteLine(
               "This Deny has no effect with LinkDemand-protected code.");
         }
         catch (SecurityException e)
         {
            Console.WriteLine("This Deny protected the library.{0}",e);
         }
      }
   }
}

Cet exemple produit la sortie suivante :

Demand: Caller's Deny has no effect on Demand with the asserted permission.
LinkDemand: Caller's Deny has no effect on LinkDemand with the asserted permission.
LinkDemand: Caller's Deny has no effect with LinkDemand-protected code.
LinkDemand: This Deny has no effect with LinkDemand-protected code.

Voir aussi