CA2107: Przejrzyj użycie akcji Deny i Permit Only

Artykuł
02/10/2024

Pozycja	Wartość
Ruleid	CA2107
Kategoria	Microsoft.Security
Zmiana powodująca niezgodność	Kluczowa

Przyczyna

Metoda zawiera sprawdzanie zabezpieczeń, które określa akcję zabezpieczeń PermitOnly lub Deny.

Uwaga

Ta reguła została przestarzała. Aby uzyskać więcej informacji, zobacz Przestarzałe reguły.

Opis reguły

Akcja System.Security.CodeAccessPermission.Deny zabezpieczeń powinna być używana tylko przez osoby, które mają zaawansowaną wiedzę na temat zabezpieczeń platformy .NET. Kod, który używa tych akcji zabezpieczeń, należy poddać przeglądowi zabezpieczeń.

Odmowa powoduje zmianę domyślnego zachowania przewodnika stosu, który występuje w odpowiedzi na zapotrzebowanie na zabezpieczenia. Umożliwia określenie uprawnień, które nie mogą być przyznawane przez czas trwania metody odmowy, niezależnie od rzeczywistych uprawnień obiektu wywołującego w stosie wywołań. Jeśli przewodnik stosu wykryje metodę, która jest zabezpieczona przez odmowę, a wymagane uprawnienie zostanie uwzględnione w uprawnieniach odmowy, przewodnik stosu zakończy się niepowodzeniem. PermitOnly zmienia również domyślne zachowanie przewodnika stosu. Umożliwia kodowi określenie tylko tych uprawnień, które mogą być przyznane, niezależnie od uprawnień osób wywołujących. Jeśli przewodnik stosu wykryje metodę zabezpieczoną przez permitOnly, a jeśli żądane uprawnienie nie zostanie uwzględnione w uprawnieniach określonych przez element PermitOnly, przewodnik stosu zakończy się niepowodzeniem.

Kod, który opiera się na tych akcjach, powinien być starannie oceniany pod kątem luk w zabezpieczeniach ze względu na ich ograniczoną użyteczność i subtelne zachowanie. Zaleca się uwzględnić następujące elementy:

Wymagania dotyczące linków nie mają wpływu na odmowę lub zezwolenieOnly.
Jeśli ustawienie Deny lub PermitOnly występuje w tej samej ramce stosu co żądanie, które powoduje przejście stosu, akcje zabezpieczeń nie mają wpływu.
Wartości używane do konstruowania uprawnień opartych na ścieżkach mogą być zwykle określane na wiele sposobów. Odmowa dostępu do jednej formy ścieżki nie odmawia dostępu do wszystkich formularzy. Jeśli na przykład udział plików \\Server\Share jest mapowany na dysk sieciowy X:, aby odmówić dostępu do pliku w udziale, musisz odmówić \\Server\Share\File, X:\File i każdej innej ścieżki, która uzyskuje dostęp do pliku.
Krok System.Security.CodeAccessPermission.Assert stosu może zakończyć się przed osiągnięciem instrukcji Deny lub PermitOnly.
Jeśli odmowa ma jakikolwiek wpływ, a mianowicie, gdy obiekt wywołujący ma uprawnienie, które jest blokowane przez odmowę, obiekt wywołujący może uzyskać bezpośredni dostęp do chronionego zasobu, pomijając odmów. Podobnie, jeśli obiekt wywołujący nie ma uprawnienia odmowy, przewodnik stosu zakończy się niepowodzeniem bez odmowy.

Jak naprawić naruszenia

Każde użycie tych akcji zabezpieczeń spowoduje naruszenie. Aby naprawić naruszenie, nie używaj tych akcji zabezpieczeń.

Kiedy pomijać ostrzeżenia

Po ukończeniu przeglądu zabezpieczeń pomiń ostrzeżenie z tej reguły.

Przykład 1

W poniższym przykładzie pokazano pewne ograniczenia odmowy. Biblioteka zawiera klasę, która ma dwie metody identyczne, z wyjątkiem wymagań dotyczących zabezpieczeń, które je chronią.

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: ");
      }
   }
}

Przykład 2

Poniższa aplikacja demonstruje wpływ odmowy na zabezpieczone metody z biblioteki.

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);
         }
      }
   }
}

Ten przykład generuje następujące wyniki:

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.

Udostępnij za pośrednictwem